Se ha presentado el lanzamiento de la base de datos distribuida rqlite 6.0, que utiliza SQLite como motor de almacenamiento y permite organizar el trabajo de un clúster de almacenes sincronizados entre sí. Entre las características de rqlite se destaca la facilidad de instalación, despliegue y mantenimiento de un almacén distribuido y tolerante a fallos, parecido a etcd y Consul, pero que utiliza un modelo relacional para trabajar con datos en lugar de un formato clave/valor. El código del proyecto está escrito en Go y se distribuye bajo la licencia MIT.
Para mantener todos los nodos en un estado sincronizado se utiliza el algoritmo de consenso Raft. Rqlite utiliza la biblioteca SQLite original y el controlador estándar go-sqlite3, sobre los cuales se ejecuta una capa que procesa las solicitudes de clientes, realiza la replicación en otros nodos y rastrea el consenso para elegir un nodo líder.
Los cambios en la base de datos solo pueden ser realizados por el nodo elegido como líder, pero las conexiones con operaciones de escritura pueden dirigirse a otros nodos del clúster, los cuales devolverán la dirección del líder para repetir la solicitud (en la próxima versión se promete agregar una redirección automática a la solicitud del líder). El enfoque principal es la tolerancia a fallos, por lo que la base de datos se escala solo en operaciones de lectura, y las operaciones de escritura son el cuello de botella. Es posible iniciar un clúster rqlite desde un solo nodo y esta solución puede utilizarse para organizar el acceso a SQLite sobre HTTP sin proporcionar tolerancia a fallos.
Los datos de SQLite en cada nodo se almacenan no en un archivo, sino en memoria. A nivel de la capa que implementa el protocolo Raft se lleva un registro de todos los comandos de SQLite que conducen a cambios en la base de datos. Este registro se utiliza durante la replicación (replicación a nivel de reproducción de solicitudes en otros nodos), al iniciar un nuevo nodo o al restaurarse después de una pérdida de conectividad. Para reducir el tamaño del registro se aplica una empaquetado automático, que se inicia después de un número determinado de cambios y conduce a la grabación en disco de un snapshot, respecto al cual comienza a llevarse un nuevo registro (el estado de la base de datos en memoria es idéntico al snapshot + el registro de cambios acumulados).
Características de rqlite:
- Facilidad de implementación de un clúster sin necesidad de una instalación separada de SQLite.
- Posibilidad de obtener rápidamente un almacenamiento SQL replicado.
- Listo para su uso en proyectos de trabajo (de calidad de producción).
- Disponibilidad de una API HTTP(S) que permite actualizar datos en modo por lotes y determinar el nodo líder del clúster. También se proporciona una interfaz de línea de comandos y la posibilidad de utilizar diversas bibliotecas de clientes diseñadas para SQLite.
- Disponibilidad de un servicio para detectar otros nodos, lo que permite crear clústeres de manera dinámica.
- Soporte para la encriptación de datos entre nodos.
- Posibilidad de configurar el nivel de verificación de frescura y consistencia de los datos al leer.
- Opción de conectar nodos en modo de solo lectura, que no participan en la determinación del consenso y se utilizan para aumentar la escalabilidad del clúster en operaciones de lectura.
- Soporte para una forma propia de transacciones basada en la agrupación de comandos en una sola solicitud (no se admite las transacciones basadas en BEGIN, COMMIT, ROLLBACK, SAVEPOINT y RELEASE).
- Soporte para la creación de copias de seguridad en caliente.
La nueva versión incluye cambios arquitectónicos significativos dirigidos a mejorar la confiabilidad del clúster mediante la optimización del proceso de direccionamiento de solicitudes de lectura y escritura a los nodos correctos del clúster. Los nodos rqlite ahora pueden multiplexar múltiples conexiones lógicas entre ellos, utilizando conexiones TCP establecidas entre nodos mediante el protocolo Raft. Si una solicitud requiere los privilegios del nodo líder, pero se envía a un nodo secundario, el nodo secundario puede determinar la dirección del líder y transmitirla al cliente, sin necesidad de realizar el cálculo del consenso mediante el protocolo Raft.
El cambio también ha permitido eliminar un componente separado para la sincronización de metadatos y evitar un tratamiento separado para el estado de Raft y los metadatos. Los nodos secundarios ahora envían solicitudes al nodo líder solo cuando es necesario conocer la dirección del nodo líder. En la API se ha añadido la posibilidad de obtener información sobre el estado de otros nodos en el clúster. Se ha agregado el comando '.sysdump' a la interfaz de línea de comandos.
Fuente: opennet.ru
