PolarDB articula una arquitectura que separa explícitamente las capas de cómputo y almacenamiento con el objetivo de reducir la latencia, acelerar la escalabilidad de lecturas y acortar los tiempos de recuperación. El sistema combina un dispositivo de bloque distribuido compartido llamado PolarStore, construido sobre el sistema de archivos PolarFS, con motores de cómputo compatibles con MySQL y PostgreSQL — incluida una variante de PostgreSQL con compatibilidad Oracle — responsables del análisis, planificación y ejecución de consultas y de la gestión del buffer pool.
La capa de almacenamiento expone un volumen de bloque compartido al que se conectan todos los nodos de cómputo del clúster. La topología soportada incluye un nodo primario de lectura‑escritura y hasta 15 nodos de solo lectura que comparten el mismo almacenamiento físico, de modo que las réplicas de lectura no mantienen copias independientes de los datos: leen las mismas páginas físicas que escribe el primario. Gracias a esta separación, la incorporación de nodos de solo lectura no desencadena una replicación completa de datos entre instancias.
Para romper la suposición habitual de cómputo y almacenamiento co‑localizados, PolarDB implementa un protocolo de bloque personalizado sobre RDMA sobre Converged Ethernet (RoCE v2). Al evitar la pila TCP/IP del kernel se reducen saltos en la ruta de E/S y se acortan los tiempos de ida y vuelta: el informe técnico sitúa esas latencias en el rango de decenas de microsegundos, comparables a la latencia de NVMe local para la mayoría de patrones de consulta y suficientes para sostener rendimiento en cargas transaccionales y de lectura intensiva.
PolarFS organiza los volúmenes en fragmentos (chunks) de 10 GB que se replican tres veces y se colocan en diferentes dominios de fallo para preservar durabilidad frente a fallos de hardware. La consistencia entre réplicas la gestiona ParallelRaft, una variación de Raft que permite comprometer entradas de log de forma asincrónica cuando el sistema puede recuperar el orden correcto mediante buffers de retroceso (rollback buffers). Esa optimización reduce latencias por cola en escenarios de I/O concurrente sin sacrificar durabilidad.
Para minimizar overheads en la ruta de E/S, PolarFS proporciona bibliotecas de espacio de usuario que permiten al cliente emitir solicitudes evitando el cache de página del kernel y la capa de bloques estándar. Al reducir cambios de contexto entre espacio de usuario y kernel se mantiene baja la latencia de acceso y se mejora el rendimiento en cargas intensivas en I/O, ya que se evita parte del coste que implican las llamadas al sistema y la gestión de la cache global.
En lugar de recurrir a la replicación lógica tradicional — la reaplicación de binlogs en réplicas que depende de volver a ejecutar sentencias SQL-PolarDB sincroniza las réplicas de lectura mediante el envío físico de registros de redo y modificaciones a nivel de bloque desde el primario. Los nodos de solo lectura aplican esos registros para invalidar o actualizar páginas en memoria sin reejecutar las sentencias SQL, con una latencia de replicación que en régimen estable suele ser sub‑segundo, reduciendo el retraso ligado al volumen de escrituras del primario.
La plataforma también contempla mecanismos de enrutamiento de tráfico para aislar cargas y garantizar consistencia cuando es necesaria: un endpoint de clúster gestionado por PolarProxy separa lecturas y escrituras para balanceo; existe un endpoint primario que garantiza lectura‑después‑de‑escritura en la misma sesión; y se admiten endpoints personalizados para segmentar cargas. El documento subraya que las transacciones que requieren lectura inmediata de sus propias escrituras deben usar el endpoint primario para evitar lecturas obsoletas.
El informe contrapone este diseño con limitaciones habituales en despliegues relacionales en la nube: instancias únicas sujetas a límites de almacenamiento, replicación lógica cuya latencia crece con el volumen de escritura y procesos de recuperación que dependen de la reproducción de binlogs. Al desacoplar cómputo y almacenamiento y al emplear replicación física basada en redo, PolarDB pretende mitigar esas restricciones operativas y facilitar el escalado horizontal de lectura sin duplicación inmediata de datos.
En conjunto, las decisiones de diseño expuestas — un protocolo de bloque sobre RDMA, un sistema de ficheros distribuido optimizado para bases de datos y un flujo de replicación basado en redo físico combinado con ParallelRaft — buscan reducir la latencia de E/S, mejorar la concurrencia en acceso a páginas y acortar los tiempos de recuperación y de escalado. El análisis técnico detalla cómo esas piezas encajan para ofrecer una alternativa a los enfoques tradicionales de replicación y recuperación en bases de datos relacionales en la nube.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
