Stabilizing Couchbase Server 2.0

[This blog was syndicated from https://damienkatz.net/]

Me alegra informaros de que ya estamos en pleno modo de estabilización y optimización de recursos para Couchbase Server 2.0. Nos ha llevado mucho más tiempo del que habíamos planeado. Crear una base de datos de documentos distribuida de alto rendimiento, eficiente, fiable y con todas las funciones es un asunto no trivial ;)

Además de la misma tecnología "simple, rápida y elástica" de memcached y clustering que tenemos en versiones anteriores de Couchbase, hemos añadido 3 grandes nuevas características para ampliar drásticamente sus capacidades y casos de uso, así como su rendimiento y fiabilidad.

Couchstore: Almacenamiento de alto rendimiento orientado a la recuperación

Uno de los mayores obstáculos para la versión 2.0 era que el motor de almacenamiento basado en Erlang consumía demasiados recursos en comparación con nuestra versión 1.8.x, que utiliza SQLite. Hicimos un montón de trabajo de optimización y modificaciones, eliminando todo lo que podíamos para hacerlo lo más rápido y eficiente posible, y en el proceso haciendo que nuestro código de almacenamiento basado en Erlang fuera varias veces más rápido que cuando empezamos, pero el uso de la CPU y los recursos seguía siendo demasiado alto, y sin muchos núcleos de CPU, no podíamos conseguir un rendimiento total del sistema donde nuestros clientes existentes lo necesitaban.

Al final, la respuesta fue reescribir el núcleo del motor de almacenamiento y el compactador en C, utilizando un formato bit a bit compatible con nuestro motor de almacenamiento Erlang, de modo que las actualizaciones escritas en un proceso pudieran ser leídas, indexadas, replicadas e incluso compactadas desde Erlang. Se trata del mismo diseño MVCC básico orientado a la recuperación, por lo que es sencillo escribir en él desde un proceso del SO y leerlo desde otro proceso. El formato de almacenamiento es inmune a la corrupción causada por caídas del servidor, OOM killers o incluso pérdidas de energía.

Reescribirlo en C nos permitió superar muchas barreras de optimización. Obtenemos fácilmente el doble de rendimiento de escritura que con el motor optimizado de Erlang y los motores de SQLite, con menos CPU y una fracción de la sobrecarga de memoria.

No todo se debe a que C sea más rápido que Erlang. Una buena parte del aumento de rendimiento se debe a la posibilidad de integrar el motor de persistencia en el proceso. Eso por sí solo reduce mucho la CPU y la sobrecarga al evitar la transmisión de datos entre procesos y la conversión a estructuras en memoria de Erlang. Pero también es C, que proporciona un buen control de bajo nivel y podemos optimizar mucho más fácilmente. El coste es más esfuerzo de ingeniería y código de bajo nivel, pero las ganancias de rendimiento han demostrado merecer mucho la pena.

Y ahora tenemos los mismos motores de almacenamiento con actualización optimista, capaces de MVCC, orientados a la recuperación y resistentes a la fragmentación, tanto en Erlang como en C. Las lecturas no bloquean las escrituras y las escrituras no bloquean las lecturas. Las escrituras también ocurren simultáneamente con la compactación. Obtener todos los cambios o cambios incrementales a través de snapshot MVCC y el índice by_sequence hace que nuestro io de disco sea principalmente lineal para un rápido calentamiento, indexación y reequilibrios de clúster. Permite la indexación asíncrona y también XDCR.

B-Superstar: Map/Reduce incremental con conciencia de clúster

Otro punto importante era trasladar todas las características importantes de las vistas incrementales map/reduce de CouchDB a Couchbase, y combinarlas con la agrupación en clústeres manteniendo la coherencia durante el reequilibrio y la conmutación por error.

Empezamos utilizando un índice por partición virtual (vbucket), fusionando los resultados de todos los índices en el momento de la consulta, pero rápidamente desechamos ese diseño, ya que simplemente no nos aportaría el rendimiento ni la escalabilidad que necesitábamos. Necesitábamos un sistema que soportara escaneos de rangos MVCC, con reducciones rápidas basadas en claves multinivel (_sum, _count, _stats y reducciones definidas por el usuario) y que requiriera el menor número posible de lecturas de índices.

Lo que se nos ocurrió utiliza el probado modelo de vista basado en CouchDB, el mismo map/reduce incremental javascript, las mismas reducciones preindexadas y memoizadas almacenadas en nodos btree internos para consultas de rango de bajo coste, pero puede excluir instantáneamente resultados de particiones inválidas cuando las particiones se reequilibran fuera de un nodo, o se indexan parcialmente en un nuevo nodo.

Incrustamos un índice de partición de mapa de bits en cada nodo del btree que es el OR recursivo de todas las reducciones de los hijos. Debido a las actualizaciones del índice tail append, es una escritura lineal actualizar los nodos hoja modificados hasta la raíz mientras se actualizan todos los mapas de bits. Ahora podemos saber al instante qué subárboles tienen valores emitidos desde un vbucket concreto.