El problema fundamental que Neki aborda es la limitación inherente de escalabilidad vertical de las bases de datos relacionales monolíticas, específicamente PostgreSQL. A medida que las aplicaciones crecen, una única instancia de PostgreSQL alcanza límites de CPU, memoria, I/O y conexiones, lo que lleva a problemas de rendimiento y operacionales como ventanas de mantenimiento prolongadas para DDL o backups. Las soluciones tradicionales, como el escalado a nivel de aplicación o las bases de datos distribuidas con compatibilidad limitada, introducen complejidad, latencia o sacrifican la fidelidad a PostgreSQL.
Neki se posiciona como una alternativa que permite el escalado horizontal de PostgreSQL sin comprometer la experiencia del desarrollador ni la compatibilidad con el ecosistema de PostgreSQL. Esto se logra mediante un enfoque de sharding transparente a nivel de protocolo, manteniendo instancias de PostgreSQL "puras" en cada shard. La necesidad de esta solución es acuciante en entornos de alto crecimiento donde la migración a sistemas NoSQL no es viable o deseable, y donde la gestión de sharding a nivel de aplicación se vuelve una carga operativa significativa.
Arquitectura del Sistema
La arquitectura de Neki se compone de cuatro elementos principales: Routers, Shards y Shard Groups, Connection Pooling (vía Sidecars) y un Control Plane. Los Routers son el punto de entrada para las aplicaciones, implementando el protocolo de cable de PostgreSQL. Contienen un parser de consultas completo, un planificador de consultas distribuidas y un buffer de consultas. Su función es analizar las consultas entrantes, determinar qué shards deben ejecutarlas basándose en una topología de datos JSON configurable, distribuir el trabajo y consolidar los resultados.
Cada Shard es una instancia de PostgreSQL estándar, con una configuración de alta disponibilidad (un primario y al menos dos réplicas en diferentes zonas de disponibilidad). No se utiliza un motor de almacenamiento modificado, lo que garantiza la compatibilidad total con extensiones y el comportamiento nativo de PostgreSQL. Los Shard Groups permiten agrupar tablas o cargas de trabajo en diferentes conjuntos de shards, cada uno con su propio perfil de configuración (tamaño de instancia, réplicas, almacenamiento, parámetros de PostgreSQL). Los Sidecars se ejecutan junto a cada instancia de PostgreSQL y gestionan el pooling de conexiones de manera más eficiente que soluciones externas como PgBouncer, al tener visibilidad de ambos extremos de la conexión (router y PostgreSQL).
Finalmente, el Control Plane es responsable de la salud de los nodos, la coordinación de failovers (planificados y no planificados), y la ejecución de flujos de trabajo online para resharding, cambios de esquema (DDL), y actualizaciones de versión. La Data Topology, una configuración JSON, define cómo las tablas lógicas se mapean a shards físicos, incluyendo índices de sharding y funciones de hash. Los routers cachean esta topología para una planificación eficiente de consultas.
Flujo de Consulta Distribuida
- 1 Aplicación Cliente Envía consulta SQL vía protocolo de cable PostgreSQL.
- 2 Neki Router Recibe, parsea la consulta y consulta la Data Topology.
- 3 Neki Router Planifica la ejecución distribuida, identificando shards relevantes.
- 4 Neki Router Envía sub-consultas a los Shards de PostgreSQL a través de Sidecars.
- 5 PostgreSQL Shard (Primario) Ejecuta la sub-consulta y devuelve resultados al Sidecar.
- 6 Neki Router Combina los resultados de múltiples shards.
- 7 Neki Router Envía el resultado final a la aplicación cliente.
Flujo de Resharding Online
- 1 Control Plane Inicia el workflow de resharding.
- 2 Control Plane Provisiona nuevos nodos target para los shards.
- 3 Control Plane Configura replicación para que los nuevos nodos se pongan al día.
- 4 Control Plane Copia datos de los shards antiguos a los nuevos, manteniendo consistencia.
- 5 Neki Router Actualiza la Data Topology para dirigir el tráfico a los nuevos shards.
- 6 Control Plane Retira los nodos antiguos una vez que el tráfico ha sido conmutado.
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | PostgreSQL | Motor de base de datos relacional primario en cada shard, sin modificaciones en el motor de almacenamiento. vs MySQL, CockroachDB (con motor de almacenamiento modificado), YugabyteDB (con motor de almacenamiento modificado) |
| networking | PostgreSQL Wire Protocol | Protocolo de comunicación estándar entre la aplicación y el router Neki, asegurando compatibilidad con drivers y ORMs existentes. vs gRPC (requeriría cambios en la aplicación), REST/HTTP (no nativo para bases de datos) |
| orchestration | Neki Control Plane | Gestiona la salud de los nodos, failovers, y coordina workflows de operaciones online (resharding, DDL, upgrades). vs Kubernetes (para orquestación de contenedores, pero no específico para workflows de DB), Custom scripts/tooling (menos robusto y automatizado) |
| cache | Neki Router (Data Topology Cache) | Cacha la configuración de la topología de datos para una planificación de consultas eficiente, reduciendo la latencia de acceso a metadatos. vs Consulta directa al Control Plane (mayor latencia), Cache distribuida externa (mayor complejidad) |
Fundamentos Teóricos
El concepto de sharding y bases de datos distribuidas tiene profundas raíces en la investigación académica sobre sistemas distribuidos y bases de datos. La partición de datos para escalabilidad horizontal es un patrón bien establecido, explorado en trabajos como "A Case for Shared-Nothing" de Stonebraker (1986), que abogaba por arquitecturas donde los nodos no compartieran recursos para maximizar la escalabilidad. La gestión de transacciones distribuidas y la consistencia en sistemas sharded se relaciona con el teorema CAP (Brewer, 2000) y sus implicaciones en el diseño de sistemas distribuidos, donde se debe elegir entre consistencia, disponibilidad y tolerancia a particiones de red.
La implementación de operaciones online para DDL y resharding se basa en principios de replicación lógica y mecanismos de "shadowing" o "copy-on-write" para minimizar el tiempo de inactividad, conceptos que han sido objeto de estudio en la comunidad de bases de datos durante décadas. La transparencia del router para el cliente, manteniendo el protocolo de cable de PostgreSQL, es una aplicación práctica del principio de encapsulación y abstracción de la complejidad subyacente de un sistema distribuido, permitiendo a las aplicaciones interactuar con él como si fuera una única instancia monolítica.