DewDB mete replicación, consenso y sharding dentro de la propia base de datos
La base de datos distribuida DewDB asume en sus propios nodos el almacenamiento, la elección de líder, el failover y el sharding, sin apoyarse en TiKV ni en un coordinador externo.
Una base de datos distribuida suele apoyarse en una capa de almacenamiento distribuido por debajo. DewDB no: los nodos de la base de datos se encargan ellos mismos del almacenamiento, la replicación, la elección de líder, el failover, el sharding y el movimiento de datos. No hay TiKV debajo ni un coordinador aparte.
El modelo es el habitual en estos sistemas. Un grupo replicado de DewDB tiene un líder y varias réplicas; si el líder se cae, una réplica toma el relevo. Para escalar horizontalmente se añade sharding, y cada grupo de shards mantiene su propio líder y sus réplicas, de modo que distintos shards aceptan escrituras de forma independiente.
Por qué no reutilizar TiKV
La decisión es deliberada. Si DewDB se montara sobre TiKV, el proyecto quedaría reducido a una capa de documentos y consultas encima de otra base de datos distribuida. El autor quería que lo que despliegas sea también lo que replica, conmuta y reparte los datos. La consecuencia es que DewDB tiene que cargar con las partes difíciles: la lógica de quórum, las elecciones, la recuperación desde el WAL, la reparación de réplicas, la propiedad de cada shard y la migración. Ese intercambio es, según el autor, el sentido del proyecto.
Qué hay hoy
En el apartado funcional ya hay documentos, consultas, índices secundarios, replicación, failover, sharding, flujos de cambios y migración de shards en caliente. La instalación en Windows se hace con un script de PowerShell de una línea y, después, con dewdb init seguido de dewdb. El código está en dewdb/dewdb.
Lo que no acompaña al anuncio son cifras. No hay benchmarks, ni comparación de latencia frente a TiKV, ni número de versión, ni licencia, ni notas de release: todo lo que se cuenta viene del propio autor. Quien esté pensando en probarlo debería tratarlo como lo que es, un proyecto joven que asume él mismo las partes difíciles. Antes de meterlo en producción conviene mirar cómo se comportan la lógica de quórum y la reparación de réplicas bajo carga real, y bajo qué licencia se distribuye.
