Cómo 768 servidores pueden comportarse como una sola base de datos

Un único servidor de base de datos acaba quedándose sin espacio. Para aplicaciones que atienden a millones de clientes y manejan millones de consultas por segundo, los puntos habituales de rotura son la CPU, la E/S y el hecho de que las escrituras siguen canalizándose a través de un único nodo primario.

En una nueva publicación, PlanetScale expone por qué el sharding sigue siendo la forma práctica de escalar Postgres y MySQL más allá de unos pocos terabytes. El ejemplo empieza pequeño: 2 terabytes de datos repartidos en cuatro shards, cada uno almacenando 500 gigabytes y atendiendo aproximadamente una cuarta parte del tráfico. En el extremo superior, 1 petabyte de datos puede significar 256 shards, cada uno con un primario y dos réplicas. Eso suma 768 servidores.

Las réplicas de lectura ayudan, pero solo hasta cierto punto. Pueden absorber más tráfico SELECT y mejorar la disponibilidad, pero no aumentan la capacidad de almacenamiento porque cada réplica sigue siendo una copia completa del primario. Las escrituras continúan limitadas por el registro de escritura adelantada (WAL) del primario, y las copias de seguridad grandes de una base de datos monolítica pueden llevar horas o incluso días.

Cómo la capa de proxy enruta las consultas

PlanetScale sostiene que la clave para que cientos de servidores parezcan una sola base de datos es la capa de proxy —más concretamente, un enrutador que se sitúa entre la aplicación y los nodos de la base de datos. En una configuración no shardeada, herramientas como PgBouncer se encargan principalmente del pooling de conexiones y del encolado de consultas. En un sistema shardeado, el enrutador también necesita entender dónde reside cada dato y enviar cada consulta SQL al lugar correcto.

Recomendado

El impulso europeo en chips no acabará con la dependencia de la nube estadounidense

Eso significa que el enrutador debe:

• conocer la estrategia de sharding
• mapear las filas al shard correcto en las escrituras
• dirigir lecturas simples a un único shard
• dividir y agregar consultas que abarcan varios shards
• gestionar el parseo y la planificación de consultas, el pooling de conexiones y el buffering

La publicación usa un ejemplo común: aplicar hash a una columna id. Una fila insertada en una tabla users se hashea por ID, y el enrutador la reenvía al shard responsable de ese valor. Una consulta como SELECT email from user where id = 4; puede enviarse a un solo shard, mientras que SELECT email FROM user WHERE id BETWEEN 3 AND 5; puede requerir que el enrutador consulte varios shards y combine los resultados.

VSchema, topología de datos y balanceo de carga

PlanetScale dice que tanto Vitess para MySQL como Neki para Postgres describen la disposición de los shards mediante metadatos JSON. En Vitess eso es VSchema; en Neki, es la definición de la topología de datos. Esto le indica al enrutador qué tabla está shardeada, por qué columna y usando qué método de indexación.

A esta escala, el tráfico tampoco puede pasar por un único enrutador. PlanetScale dice que un despliegue con 256 shards, 768 servidores y millones de consultas por segundo puede necesitar 10 o incluso 100 proxies, dependiendo de los patrones de tráfico. Un Network Load Balancer (NLB) puede presentar un único host o IP a la aplicación y distribuir cada conexión entre esos enrutadores, manteniendo además la conexión anclada al mismo proxy durante su vida útil.

El resultado es que una aplicación puede conectarse mediante una única cadena como mydb.pscale.com, mientras que las consultas realmente fluyen a través de un NLB opcional, hacia uno de los muchos proxies y luego a los shards correspondientes. La recomendación de PlanetScale es sencilla: para Postgres y MySQL, el sharding debería comenzar mucho antes de llegar a 1 petabyte —típicamente una vez que una base de datos supera unos pocos terabytes.