PolarDB-X V2.3: Lanzamiento de Código Abierto con Arquitectura Híbrida Centralizada y Distribuida

En la conferencia Yunqi 2023, PolarDB-X lanzó oficialmente la versión 2.3.0, introduciendo la edición estándar de PolarDB-X (forma centralizada). Esta versión ofrece los nodos DN del sistema distribuido como un servicio independiente, soporta el modo de réplica múltiple con protocolo Paxos, el motor de transacciones distribuido Lizard, y es 100% compatible con MySQL. En escenarios de rendimiento, utilizando implementaciones de producción y parámetros (doble 1 habilitado + sincronización fuerte de réplica múltiple Paxos), PolarDB-X muestra una mejora de rendimiento del 30~40% en escenarios de lectura-escritura mixta en comparación con MySQL 8.0.34 de código abierto, posicionándose como la mejor alternativa al código abierto de MySQL.

Introducción a la Arquitectura

PolarDB-X utiliza una arquitectura Shared-nothing con separación de almacenamiento y cálculo, compuesta por 5 componentes principales:

Nodo de Cómputo (CN, Compute Node): Es el punto de entrada del sistema, diseñado sin estado, incluye módulos como analizador SQL, optimizador y ejecutor. Se encarga del enrutamiento distribuido de datos, cómputo y programación dinámica, coordinación de transacciones distribuidas 2PC, mantenimiento de índices secundarios globales, y proporciona características empresariales como limitación de SQL y separación de tres poderes.
Nodo de Almacenamiento (DN, Data Node): Se encarga de la persistencia de datos, basado en el protocolo de consenso de mayoría Paxos, ofrece alta confiabilidad y consistencia fuerte de datos. Mantiene la visibilidad de transacciones distribuidas a través de MVCC.
Servicio de Metadatos (GMS, Global Meta Service): Mantiene información de sistema globalmente consistente como Tabla/Esquema, Estadísticas, etc. Gestiona información de seguridad como cuentas y permisos, y proporciona servicio de sincronización de tiempo global (TSO).
Nodo de Registro (CDC, Change Data Capture): Ofrece capacidad de suscripción incremental totalmente compatible con formato y protocolo MySQL Binlog, y capacidad de replicación maestro-esclavo compatible con protocolo MySQL Replication.
Nodo de Almacenamiento Columnar (Columnar): Se encarga de proporcionar almacenamiento de datos en columnas, construyendo una arquitectura HTAP basada en almacenamiento mixto fila-columna y nodos de cómputo distribuido. Se espera su lanzamiento de código abierto en abril de 2024.

Dirección de código abierto: [https://github.com/polardb/polardbx-sql]

Historial de Versiones

Recorrido de PolarDB-X de código abierto:

Octubre de 2021: En la conferencia Yunqi, Alibaba Cloud开源 (open-sourced) oficialmente la base de datos distribuida nativa en la nube PolarDB-X, adoptando un modelo de código abierto de kernel completo, que incluye motor de cómputo, motor de almacenamiento, motor de registro, Kube, etc.
Enero de 2022: PolarDB-X lanzó la versión 2.0.0, la primera actualización después del lanzamiento oficial en octubre de 2021. Las actualizaciones incluyen expansión y contracción de clúster, y compatibilidad con ecosistema binlog, compatible con Maxwell y Debezium para suscripción de registros incrementales, además de numerosas nuevas características y correcciones de problemas.
Marzo de 2022: PolarDB-X lanzó la versión 2.1.0, con cuatro características principales que mejoran significativamente la estabilidad y compatibilidad ecológica de PolarDB-X, incluyendo el protocolo de consenso de tres réplicas basado en Paxos.
Mayo de 2022: PolarDB-X lanzó la versión 2.1.1, introduciendo principalmente la nueva característica de datos fríos-calientes, que permite almacenar datos de tablas de negocio en diferentes medios de almacenamiento según sus características, como almacenar datos fríos en el almacenamiento de objetos Aliyun OSS.
Octubre de 2022: PolarDB-X lanzó la versión 2.2.0, un hito importante, introduciendo adaptación empresarial y ARM nacional que cumple con los estándares de bases de datos distribuidas para finanzas, incluyendo ocho características principales que mejoran significativamente la aplicabilidad de PolarDB-X en industrias como finanzas, comunicaciones y gobierno.
Marzo de 2023: PolarDB-X lanzó la versión 2.2.1, fortaleciendo principalmente capacidades críticas de producción sobre la base de los estándares de bases de datos distribuidas para finanzas, mejorando significativamente la facilidad de uso y seguridad de PolarDB-X para entornos de producción de bases de datos, como: importación rápida de datos, verificación de pruebas de rendimiento, recomendaciones de implementación de producción, etc.

En octubre de 2023, PolarDB-X lanzó oficialmente la versión 2.3.0, introduciendo principalmente la edición estándar de PolarDB-X (forma centralizada), ofreciendo el nodo DN del sistema distribuido como un servicio independiente, soportando el modo de réplica múltiple con protocolo Paxos y el motor de transacciones distribuido Lizard, al mismo tiempo que es 100% compatible con MySQL, correspondiente a la edición estándar de PolarDB-X en la nube pública: https://help.aliyun.com/zh/polardb/polardb-for-xscale/pricing-of-polardb-x

1. Arquitectura Centralizada y Distribuida

1.1 Formas de Arquitectura

PolarDB-X V2.3.0 ha agregado la edición estándar (forma centralizada), por lo que las formas futuras de PolarDB-X de código abierto主要包括:

Edición Estándar de PolarDB-X: Enfocada en arquitectura centralizada, compatible con la forma de MySQL monolítica (100% compatible con MySQL), basada en algoritmo de consenso distribuido de desarrollo propio (X-Paxos) que proporciona capacidades de base de datos con RPO=0.
Edición Empresarial de PolarDB-X: Enfocada en arquitectura distribuida, altamente compatible con el ecosistema MySQL, soporta transacciones distribuidas fuertemente consistentes y consultas paralelas distribuidas, soporta expansión horizontal distribuida, puede expandirse desde 1 nodo (centralizado) hasta 1024 nodos (distribuido), construyendo capacidades de arquitectura híbrida centralizada y distribuida. Las futuras versiones de código abierto lanzarán la arquitectura de almacenamiento mixto fila-columna HTAP, soportando la construcción de una réplica de almacenamiento columnar con un solo clic, acelerando significativamente las capacidades de análisis en línea a través de consultas mixtas fila-columna.

Características y recomendaciones de selección para formas de arquitectura:

Formato	Edición Estándar (Centralizada)	Edición Empresarial (Distribuida)
Ventajas y Desventajas	Ventajas: 1. Enfatiza 100% de compatibilidad con MySQL 2. En especificaciones pequeñas (por ejemplo, CPU<=32 núcleos), tiene ventajas de rendimiento en comparación con la versión distribuida, puede actualizarse suavemente a distribuida para mayores requisitos. Desventajas: 1. Problemas de concurrencia en tablas grandes B+Tree bajo MySQL monolítico, se recomienda controlar el número de registros de una sola tabla entre 5 millones y 50 millones. 2. Existe un límite superior para la escalabilidad en una sola máquina.	Ventajas: 1. Enfatiza la expansión lineal distribuida, soporta hasta 1024 nodos, escala de datos a nivel PB. 2. Resiliencia a nivel financiero, soporta formas de recuperación de desastres como 3 centros de datos en la misma ciudad, dos lugares tres centros. 3. Arquitectura de almacenamiento mixto fila-columna HTAP, con réplica de almacenamiento columnar incorporada para acelerar capacidades de análisis en línea.
Recomendación de Selección	1. Requiere MySQL, soporte de recuperación de desastres entre centros de datos, y cumple con RPO=0. 2. Requiere MySQL de bajo costo, cumple con código abierto, y el negocio puede ser escalado hacia arriba o hacia abajo.	1. Requiere expansión de concurrencia distribuida para resolver escenarios de alta concurrencia en transacciones de pedidos. 2. Reemplazo de particionamiento manual de código abierto para resolver problemas de operación y mantenimiento. 3. Resolver problemas de tablas grandes de MySQL, basado en particionamiento de datos distribuido. 4. Requiere actualización a arquitectura distribuida y cumple con código abierto.

1.2 Implementación Rápida y Experiencia

La Edición Estándar de PolarDB-X utiliza una arquitectura de tres nodos (un maestro, un esclavo y un registro), con alta relación costo-beneficio, a través de la replicación síncrona de múltiples réplicas, garantiza la consistencia fuerte de los datos. Dirigida a escenarios de negocio en línea con concurrencia ultra alta, consultas complejas y análisis ligero.

Ahora implementemos rápidamente un clúster de la Edición Estándar de PolarDB-X, que contiene solo 1 nodo DN compuesto por tres réplicas. Ejecute el siguiente comando para crear un clúster de este tipo:

1.2.1 Implementación basada en Kubernetes

echo "apiVersion: polardbx.aliyun.com/v1
kind: XStore
metadata:
  name: implementacion-rapida
spec:
  config:
    controller:
      RPCProtocolVersion: 1
  topology:
    nodeSets:
    - name: candidatos
      replicas: 2
      role: Candidate
      template:
        spec:
          image: polardbx/polardbx-engine-2.0:latest
          resources:
            limits:
              cpu: "2"
              memory: 4Gi
    - name: registro
      replicas: 1
      role: Voter
      template:
        spec:
          image: polardbx/polardbx-engine-2.0:latest
          resources:
            limits:
              cpu: "1"
              memory: 2Gi" | kubectl apply -f -

Verá la siguiente salida:

xstore.polardbx.aliyun.com/implementacion-rapida created

Use el siguiente comando para ver el estado de creación:

$ kubectl get xstore -w
NAME          LIDER                    LISTO   FASE      DISCO    VERSION   EDAD
implementacion-rapida   implementacion-rapida-4dbh-cand-0   3/3     En ejecución   3.6 GiB   8.0.18    11m

¡Cuando FASE muestre "En ejecución", el clúster de la Edición Estándar de PolarDB-X está implementado!

Nota: Para la implementación en entornos de producción, se recomienda memoria>=8GB, consulte: https://doc.polardbx.com/deployment/topics/environment-requirement.html

1.2.2 Implementación basada en PXD

version: v1
type: polardbx
cluster:
  name: prueba_clus
  dn:
    image: polardbx/polardbx-engine-2.0:latest
    replica: 1
    nodes:
      - host_group: [172.16.201.11,172.16.201.11,172.16.201.11]
    resources:
      mem_limit: 2G

Explicación: número de réplicas del nodo de datos, en la edición estándar se establece en 1 por defecto, en la forma distribuida se puede establecer en múltiples

Ejecute el siguiente comando para implementar PolarDB-X con un solo clic en el clúster:

pxd create -file polardbx.yaml

Una vez completada la implementación, pxd mostrará el método de conexión del clúster de PolarDB-X, y puede iniciar sesión en la base de datos de PolarDB-X a través del comando MySQL para realizar pruebas.

1.3 Pruebas de Rendimiento

La instancia centralizada de la Edición Estándar de PolarDB-X optimiza la capacidad de concurrencia de transacciones basada en el sistema de transacciones distribuidas Lizard. En comparación con MySQL 8.0.34 de código abierto, muestra una mejora de rendimiento del 30~40% en escenarios de lectura-escritura mixta.

Los detalles de las pruebas de rendimiento son los siguientes:

Uso de Máquina	Modelo	Especificación
Máquina de Prueba	ecs.hfg7.6xlarge	24c96g
Máquina de Base de Datos	ecs.i4.8xlarge * 3	32c256g + 7TB de almacenamiento, precio: 7452 yuanes/mes

Escenario 1: sysbench, 16 tablas, 10 millones de registros por tabla

Escenario	50	100	150	200	250	300
oltp_seleccion_puntual	317151.01	464316.53	485389.86	487124.91	489078.48	487684.83
oltp_solo_lectura	291317.42	401566.17	420416.04	388937.68	382861.20	413884.86
oltp_lectura_escritura	156294.12	199195.62	214608.23	228713.64	254317.93	265322.61
oltp_solo_escritura	38574.92	52876.25	59393.07	62235.96	65523.25	66866.19
oltp_actualizar_indice	38005.13	51803.68	58119.58	62263.46	63918.22	64203.57
oltp_actualizar_no_indice	39712.23	54418.94	64213.46	67319.67	69110.39	70028.34

Escenario 2: TPC-C, 1000 almacenes

Escenario	50	100	150	200	250	300
1000 Almacenes	173916.76	224736.03	241440.77	246228.18	247217.83	249902.01

Escenario 3: Comparación con MySQL de código abierto (implementación en el mismo hardware de host)

Escenario	Concurrencia	MySQL 8.0.34 Replicación asíncrona maestro-esclavo	PolarDB-X Edición Estándar Centralizada Paxos mayoría	Mejora de Rendimiento
sysbench oltp_lectura_escritura	300 concurrentes	200930.88	265322.61	↑32%
TPCC 1000 almacenes	300 concurrentes	170882.38	249902.01 tpmC	↑46%

2. Compatibilidad con MySQL

La versión V2.3 de PolarDB-X en su forma distribuida continúa mejorando la compatibilidad con MySQL, reduciendo el umbral de migración de usuarios desde MySQL.

2.1 Tablas Particionadas

La función de tablas particionadas de MySQL se refiere a dividir una gran tabla en unidades lógicas más pequeñas, cada una llamada partición, y almacenar estas particiones en diferentes medios de almacenamiento físico. Este mecanismo de partición se ajusta perfectamente al concepto de partición distribuida. Por lo tanto, las tablas particionadas de PolarDB-X son completamente compatibles y extienden la sintaxis de tablas particionadas de MySQL, expandiendo las múltiples particiones de MySQL a nodos distribuidos, mejorando aún más la capacidad de concurrencia basada en múltiples nodos distribuidos.

PolarDB-X soporta métodos de partición comunes:

Partición por Rango (Range, Range Columns): Particiona los datos de una tabla según el rango de columnas. Según el rango de valores de una columna (como fecha, precio, etc.), los datos se distribuyen en diferentes particiones.
Partición por Lista (List, List Columns): Particiona los datos de una tabla según una lista de valores de columna. Los valores de una columna específica se pueden coincidir con una lista de particiones predefinidas, cada partición puede contener múltiples valores.
Partición por Hash (Hash, Key): Particiona los datos de una tabla según el resultado del hash de los valores de columna. La partición por hash distribuye uniformemente los datos de la tabla en diferentes particiones según el algoritmo hash.

Además de la partición de primer nivel, PolarDB-X también puede realizar particiones de segundo nivel en las particiones. La partición de segundo nivel subdivide aún más los datos sobre la base de la partición de primer nivel, la relación entre la partición de primer nivel y la partición de segundo nivel es completamente ortogonal, soporta la combinación de cualquier dos estrategias de partición, con un número de particiones combinadas que alcanza hasta 36.

Al mismo tiempo, en PolarDB-X, las particiones de segundo nivel se pueden dividir en dos métodos: partición basada en plantilla y partición no basada en plantilla.

Partición basada en plantilla (Template-based Partitioning): La partición basada en plantilla se refiere a crear una partición de segundo nivel definiendo una plantilla. La plantilla contiene una serie de reglas de partición para especificar la cantidad y nombre de subparticiones de cada partición de primer nivel. Con la partición basada en plantilla, se pueden crear rápidamente particiones de segundo nivel con la misma estructura.

El siguiente ejemplo muestra la sintaxis para crear una partición de segundo nivel usando partición basada en plantilla:

CREATE TABLE tabla_particionada (
    ...
)
PARTITION BY RANGE COLUMNS(columna1)
SUBPARTITION BY HASH(columna2)
SUBPARTITIONS 4
SUBPARTITION TEMPLATE (
    SUBPARTITION s1,
    SUBPARTITION s2,
    SUBPARTITION s3,
    SUBPARTITION s4
) (
    PARTITION p1 VALUES LESS THAN (100),
    PARTITION p2 VALUES LESS THAN (200),
    ...
);

En el ejemplo anterior, se define una plantilla de partición de segundo nivel a través de la palabra clave SUBPARTITION TEMPLATE, especificando los nombres de las cuatro subparticiones de cada partición de primer nivel. Luego, en cada partición de primer nivel, se especifica SUBPARTITION TEMPLATE para usar la misma plantilla de subpartición.

Partición no basada en plantilla (Non-template-based Partitioning): La partición no basada en plantilla se refiere a especificar manualmente la cantidad y nombre de subparticiones para cada partición de primer nivel. Con la partición no basada en plantilla, se pueden crear de manera más flexible subparticiones con diferentes cantidades y nombres para cada partición de primer nivel.

El siguiente ejemplo muestra la sintaxis para crear una partición de segundo nivel usando partición no basada en plantilla:

CREATE TABLE tabla_particionada (
    ...
)
PARTITION BY RANGE COLUMNS(columna1)
SUBPARTITION BY HASH(columna2)
SUBPARTITIONS (
    PARTITION p1 VALUES LESS THAN (100) (
        SUBPARTITION s1,
        SUBPARTITION s2,
        SUBPARTITION s3,
        SUBPARTITION s4
    ),
    PARTITION p2 VALUES LESS THAN (200) (
        SUBPARTITION s5,
        SUBPARTITION s6,
        SUBPARTITION s7,
        SUBPARTITION s8
    ),
    ...
);

En el ejemplo anterior, se especifica manualmente diferentes cantidades y nombres de subparticiones para cada partición de primer nivel, sin usar una plantilla para definirlas.

Tanto la partición basada en plantilla como la no basada en plantilla de PolarDB-X tienen sus ventajas y usos. La partición basada en plantilla es adecuada para crear tablas particionadas con la misma estructura, reduciendo el trabajo de creación de tablas. La partición no basada en plantilla es más flexible, permitiendo crear diferentes cantidades y nombres de subparticiones para cada partición de primer nivel según las necesidades específicas.

El método de definición tradicional de particionamiento manual es un caso especial de definición de partición de segundo nivel basada en plantilla (la misma cantidad de tablas particionadas bajo cada partición de base). La nueva versión de PolarDB-X soporta capacidades completas de tablas particionadas distribuidas, que pueden combinar particiones no basadas en plantilla para optimizar mejor los puntos calientes distribuidos.

Combinando un ejemplo práctico para experimentar los beneficios de la partición no basada en plantilla: sistema de gestión de pedidos de transacciones, toda la plataforma sirve a numerosos vendedores de diferentes marcas, la cantidad de pedidos entre diferentes vendedores varía considerablemente, lo que resulta en una situación obvia de vendedores grandes. Los vendedores grandes están dispuestos a convertirse en miembros VIP que pagan esperando compartir recursos exclusivos, mientras que los vendedores pequeños usan recursos compartidos gratuitos.

/* Combinación de partición de primer nivel LIST COLUMNS + partición de segundo nivel HASH no basada en plantilla */
CREATE TABLE t_pedido /* Tabla de pedidos */ (
 id bigint not null auto_increment, 
 id_vendedor bigint not null, 
 id_comprador bigint not null,
 primary key(id)
) 
PARTITION BY LIST(id_vendedor/* ID del vendedor */) /*  */
SUBPARTITION BY HASH(id_vendedor) 
(
  PARTITION pa VALUES IN (108，109) 
    SUBPARTITIONS 1 /* Bajo la partición de primer nivel pa, hay 1 partición hash, almacenando todos los datos de los vendedores de la marca a */,
  PARTITION pb VALUES IN (208，209) 
    SUBPARTITIONS 1 /* Bajo la partición de primer nivel pb, hay 1 partición hash, almacenando todos los datos de los vendedores de la marca b */,
  PARTITION pc VALUES IN (308，309，310)
    SUBPARTITIONS 2 /* Bajo la partición de primer nivel pc, hay 2 particiones hash, almacenando los datos de los vendedores de la marca c */,
  PARTITION pDefault VALUES IN (DEFAULT)
    SUBPARTITIONS 64 /* Bajo la partición de primer nivel pDefault, hay 64 particiones hash, almacenando los datos de numerosos vendedores de marcas pequeñas */
);

Basado en la partición de segundo nivel LIST+HASH no basada en plantilla anterior, los efectos directos que puede traer a la aplicación son:

Para los vendedores de marcas grandes (equivalentes a un inquilino), los datos se pueden enrutar a un grupo de particiones separado;
Para las marcas pequeñas y medianas, los datos se pueden distribuir automáticamente de manera equilibrada a diferentes particiones a través del algoritmo hash, evitando así puntos calientes de acceso. Por ejemplo, la asignación predeterminada tiene 64 particiones, soportando todos los usuarios gratuitos. Mientras que los usuarios de pago, combinados con la escala, pueden tener 1 o 2 particiones de segundo nivel, logrando una distribución de datos refinada basada en particiones no basadas en plantilla.

2.2 Columnas Generadas

La función de columnas generadas de MySQL se refiere a agregar una o más columnas a una tabla como columnas virtuales o calculadas al crear la tabla. Se puede usar la palabra clave GENERATED ALWAYS AS para definir. Mediante el uso de expresiones, se pueden usar varias funciones matemáticas, lógicas y de cadena para calcular el valor de la columna. Las columnas generadas pueden ser columnas virtuales (VIRTUAL) o columnas almacenadas (STORED).

La nueva versión de PolarDB-X soporta la sintaxis y función de columnas generadas de MySQL, consulte la documentación: Sintaxis de Columnas Generadas de PolarDB-X

nombre_columna tipo_de_dato [GENERATED ALWAYS] AS (expr)
  [VIRTUAL | STORED | LOGICAL] [NOT NULL | NULL]
  [UNIQUE [KEY]] [[PRIMARY] KEY]
  [COMMENT 'cadena']

Las columnas generadas tienen los siguientes tres tipos:

VIRTUAL: El valor de la columna generada no se almacena, se calcula por el nodo de almacenamiento DN cada vez que se lee la columna, no ocupa espacio de almacenamiento. Nota Si no se especifica la palabra clave, por defecto se crea una columna generada de tipo VIRTUAL.
STORED: El valor de la columna generada se calcula por el nodo de almacenamiento DN cuando se inserta o actualiza la fila de datos, y el resultado se almacena, ocupando espacio de almacenamiento.
LOGICAL: Similar al tipo STORED, el valor de la columna generada se calcula en el nodo de cómputo CN cuando se inserta o actualiza la fila de datos, la diferencia es que el valor de la columna generada se almacena en DN como una columna normal. Este tipo de columna generada se puede usar como clave de partición.

Ejemplo de columna generada:

CREATE TABLE `t1` (
  `a` int(11) NOT NULL,
  `b` int(11) GENERATED ALWAYS AS (`a` + 1),
  PRIMARY KEY (`a`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4  partition by hash(`a`)

Insertar datos:

# INSERT INTO t1(a) VALUES (1);
# SELECT * FROM t1;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
+---+---+

PolarDB-X es compatible con las características relacionadas de columnas generadas + índice de MySQL, soporta crear índices adicionales en columnas generadas para acelerar la capacidad de consulta, como consultas de clave interna para tipos JSON.

Ejemplo de creación de índice en columna generada:

> CREATE TABLE t4 (
    a BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    c JSON,
    g INT AS (c->"$.id") VIRTUAL
) DBPARTITION BY HASH(a);

> CREATE INDEX `i` ON `t4`(`g`);

> INSERT INTO t4 (c) VALUES
  ('{"id": "1", "name": "Fred"}'),
  ('{"id": "2", "name": "Wilma"}'),
  ('{"id": "3", "name": "Barney"}'),
  ('{"id": "4", "name": "Betty"}');

// Se puede usar el índice de la columna virtual g para la poda
> EXPLAIN EXECUTE SELECT c->>"$.name" AS name FROM t4 WHERE g > 2;
+------+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id   | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+------+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| 1    | SIMPLE      | t4    | NULL       | range | i             | i    | 5       | NULL | 1    | 100      | Using where |
+------+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+

A partir de la versión MySQL 8.0, se proporciona la función de índice de expresión, introduciendo el concepto de índice funcional (Functional Indexes), que permite usar expresiones en índices. Mediante la especificación de expresiones en la instrucción CREATE INDEX, se pueden crear índices para optimizar consultas específicas, la implementación interna original adoptaba columnas virtuales.

PolarDB-X en la versión v2.3 es compatible con el índice funcional de MySQL 8.0, soporta crear índices. Si PolarDB-X encuentra que un elemento de índice no es una columna en la tabla, sino una expresión, en este momento PolarDB-X convertirá automáticamente la expresión en una columna generada de tipo VIRTUAL y la agregará a la tabla. Después de procesar todos los elementos de índice, PolarDB-X continuará creando el índice según la definición del usuario, y los elementos de índice de expresión en la definición de índice se reemplazarán con la columna generada correspondiente.

Esta función de índice funcional es una función experimental y necesita activar el parámetro de laboratorio para usarla.

SET GLOBAL ENABLE_CREATE_EXPRESSION_INDEX=TRUE;

Ejemplo de uso:

1. Crear tabla t7
> CREATE TABLE t7 (
    a BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    c varchar(32)
) DBPARTITION BY HASH(a);

2. Crear índice de expresión i
> CREATE INDEX `i` ON `t7`(substr(`c`, 2));

3. Después de completar la creación del índice de expresión, la estructura de la tabla es la siguiente:
> SHOW FULL CREATE TABLE `t7`

# Resultado devuelto
CREATE TABLE `t7` (
  `a` bigint(20) NOT NULL AUTO_INCREMENT BY GROUP,
  `c` varchar(32) DEFAULT NULL,
  `i$0` varchar(32) GENERATED ALWAYS AS (substr(`c`, 2)) VIRTUAL,
  PRIMARY KEY (`a`),
  KEY `i` (`i$0`)
) ENGINE = InnoDB dbpartition by hash(`a`)

# Dado que el índice i es una expresión, se agrega una columna generada i$0 en la tabla, la expresión de esta columna generada es la expresión del elemento de índice. Finalmente se crea el índice i, donde el elemento de índice se reemplaza con la columna generada correspondiente.
# Después de crear el índice de expresión, las siguientes SQL pueden usar el índice de expresión para acelerar la velocidad de consulta:

> EXPLAIN EXECUTE SELECT * FROM t7 WHERE substr(`c`, 2) = '11';
+------+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id   | select_type | table | partitions | type | possible_keys | key  | key_len | ref   | rows | filtered | Extra |
+------+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+
| 1    | SIMPLE      | t7    | NULL       | ref  | i             | i    | 131     | const | 1    | 100      | NULL  |
+------+-------------+-------+------------+------+---------------+------+---------+-------+------+----------+-------+

2.3 Claves Foráneas

Las claves foráneas (Foreign Key) en MySQL son una característica de bases de datos relacionales, utilizadas para establecer relaciones de asociación entre tablas. Una clave foránea define una relación de referencia entre columnas en una tabla y columnas en otra tabla. A través de las claves foráneas, se pueden implementar restricciones de integridad y consistencia de datos, y relaciones de referencia entre datos.

En la versión v2.3, PolarDB-X es compatible con el uso común de claves foráneas de MySQL, permitiendo en bases de datos distribuidas establecer conexiones de datos entre tablas (bases) a través de claves foráneas, logrando una garantía de consistencia de datos equivalente a bases de datos monolíticas.

Al mismo tiempo, debido a que la implementación de verificación y mantenimiento de restricciones de clave foránea en tablas particionadas distribuidas es más compleja que en bases de datos monolíticas, un uso irrazonable de claves foráneas puede provocar una sobrecarga de rendimiento significativa, lo que resulta en una disminución significativa del throughput del sistema.

Por lo tanto, la función de clave foránea se presentará como una función experimental a largo plazo, se recomienda verificar los datos a fondo antes de usarla con precaución.

SET GLOBAL ENABLE_FOREIGN_KEY = TRUE;

Sintaxis relacionada con claves foráneas:

-- Crear clave foránea
[CONSTRAINT [símbolo]] FOREIGN KEY
    [nombre_índice] (nombre_columna, ...)
    REFERENCES nombre_tabla (nombre_columna,...)
    [ON DELETE referencia_opción]
    [ON UPDATE referencia_opción]

referencia_opción:
    RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT


-- Eliminar clave foránea
ALTER TABLE nombre_tabla DROP FOREIGN KEY CONSTRAINT_símbolo;

Ejemplo de clave foránea:

> CREATE TABLE a (
  id INT PRIMARY KEY
);
> INSERT INTO a VALUES (1);

> CREATE TABLE b (
  id INT PRIMARY KEY,
  a_id INT,
  FOREIGN KEY fk(`a_id`) REFERENCES a(`id`) ON DELETE CASCADE
);
> INSERT INTO b VALUES (1,1);

> CREATE TABLE c (
  b_id INT,
  FOREIGN KEY fk(`b_id`) REFERENCES b(`id`) ON DELETE RESTRICT
);
> INSERT INTO c VALUES (1);

# Eliminar registros de la Tabla A, verificará en cascada las restricciones de clave foránea de las Tablas A/B/C
> DELETE FROM a WHERE id = 1;
> ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`test`.`c`, CONSTRAINT `c_ibfk_1` FOREIGN KEY (`b_id`) REFERENCES `b` (`id`) ON DELETE RESTRICT)

3. Herramienta de Replicación de Tráfico Frodo

Frodo es una herramienta complementaria de PolarDB-X de código abierto desarrollada por el equipo de bases de datos de Alibaba Cloud, centrada en la replicación de tráfico de bases de datos, principalmente utilizada para resolver problemas de compatibilidad de negocio y evaluación de rendimiento en el proceso de entrega de bases de datos.

Dirección de código abierto: https://github.com/polardb/polardbx-tools/tree/frodo-v1.0.0/frodo

Principio de funcionamiento básico:

Contiene principalmente dos partes de funcionalidad:

Recopilación de registros SQL, actualmente soporta MySQL de código abierto, así como auditoría SQL de RDS de Alibaba Cloud, soporta analizar estos registros SQL en formato de datos interno de frodo y persistirlos.
Replicación de tráfico SQL, basada en SQL de negocio real en PolarDB-X para replicar el tráfico, mediante la introducción de tecnología de subprocesos múltiples, se puede lograr replicación de múltiplos para simular el tráfico de pico.

Ejemplo de operación:

Paso 1: Recopilar registros general de MySQL autoconstruido

java -jar mysqlsniffer.jar --capture-method=general_log --replay-to=file --port=3306 --username=root --password=xxx --concurrency=32 --time=60 --out=logs/out.json

Paso 2: Replicar el tráfico a PolarDB-X

java -Xms=2G -Xmx=4G -jar frodo.jar --file=/root/out.json --source-db=mysql --replay-to=polarx --port=3306 --host=172.25.132.163 --username=root --password=123456 --concurrency=64 --time=1000 --task=task1 --schema-map=test:test1,test2 --log-level=info --rate-factor=1 --database=test

Después de completar la replicación del tráfico, se generará un informe de datos, registrando el informe de ejecución SQL, como: plantilla SQL, tasa de éxito, RT, etc.

4. Mejora del Ecosistema de Código Abierto

4.1 Adaptación de Código Abierto de Canal

Canal es un middleware de código abierto del equipo de bases de datos de Alibaba Cloud, utilizado para la sincronización y suscripción de datos en tiempo real de MySQL binlog. Basado en la tecnología de análisis de registros de bases de datos, puede capturar los cambios incrementales de la base de datos y sincronizar los datos de cambio a otros sistemas, logrando la sincronización y suscripción de datos en tiempo real.

Canal lanzó recientemente la versión v1.1.7, soporta análisis de binlog de flujo único global y binlog de múltiples flujos de PolarDB-X #4657

Como se muestra en la figura anterior, PolarDB-X proporciona dos formas de capacidad de suscripción y consumo de registros binlog, y las dos formas pueden coexistir simultáneamente.

Forma de flujo único: Es decir, registros binlog de flujo único (también conocido como Global binlog), fusiona todos los DN binlog en la misma cola global, proporcionando un flujo de registros que garantiza la integridad y orden de las transacciones, puede proporcionar un nivel más alto de garantía de consistencia de datos. Por ejemplo, en escenarios de transferencia, basado en Global binlog para conectar MySQL descendente de PolarDB-X, en cualquier momento se puede consultar un saldo consistente.
Forma de múltiples flujos: Es decir, registros binlog de múltiples flujos (también conocido como Binlog-X), no fusiona todos los DN binlog en una cola global, sino que dispersa los datos mediante Hash y los distribuye a diferentes flujos de registros, en cierta medida sacrifica la integridad de las transacciones, pero mejora significativamente la escalabilidad, puede resolver el problema de cuello de botella de punto único existente en flujos binlog únicos en clústeres a gran escala.

Dirección de código abierto de canal: https://github.com/alibaba/canal

4.2 Adaptación de Código Abierto de KubeBlocks

KubeBlocks es un proyecto de código abierto basado en Kubernetes, que admite la unificación de múltiples motores y operación y mantenimiento, ayuda a los usuarios a construir servicios de base de datos relacionales, NoSQL, de flujo y vectorizadas de forma contenedorizada y declarativa mediante BYOC (Bring-your-own-cloud). KubeBlocks está diseñado específicamente para propósitos de producción, proporciona infraestructura de datos confiable, de alto rendimiento, observable y económica para la mayoría de los escenarios. El nombre KubeBlocks está inspirado en los bloques de LEGO, lo que implica que se puede construir felizmente su infraestructura de datos en Kubernetes como bloques de LEGO.

En la versión 0.7 próxima a lanzar, KubeBlocks admitirá nativamente a PolarDB-X:

Instalar rápidamente PolarDB-X basado en KubeBlocks, solo takes 3 pasos:

Crear plantilla de clúster ``` helm install polardbx ./deploy/polardbx

2. Crear instancia de PolarDB-X ```
Método uno:
kbcli cluster crear pxc --cluster-definition polardbx

Método dos:
helm install polardbx-cluster ./deploy/polardbx-cluster

Reenvío de puerto e inicio de sesión en la base de datos

kubectl port-forward svc/pxx-cn 3306:3306
mysql -h127.0.0.1 -upolardbx_root

4.3 Adaptación de Código Abierto de CloudCanal

CloudCanal es una herramienta de sincronización y migración de datos, que ayuda a las empresas a construir tuberías de datos de alta calidad, con características como sincronización en tiempo real eficiente y precisa, conexión precisa, estable y escalable, todo en uno, implementación híbrida, transformación de datos compleja, etc. A través de CloudCanal, los usuarios pueden lograr rápidamente y de manera confiable la sincronización y migración de datos de bases de datos en entornos nativos en la nube.

Al mismo tiempo, CloudCanal en comparación con Canal de código abierto soporta más fuentes de datos conectadas, así como capacidades de migración de estructura completa + datos, mejorando satisfacer las funciones de sincronización y migración de datos de un solo para los usuarios.

La versión reciente de CloudCanal, soporta completamente escenarios donde PolarDB-X es fuente y destino, consulte la documentación:

https://www.clougence.com/cc-doc/releaseNote/rn-cloudcanal-2-7-0-0

Etiquetas: base de datos distribuida MySQL PolarDB-X arquitectura de bases de datos código abierto

Publicado el 8-1 02:23

Friki Work