¿Qué es RocksDB? El almacén clave-valor integrado

¿Qué es RocksDB?

RocksDB es un almacén clave-valor persistente e integrable, optimizado para el almacenamiento rápido. Acepta claves y valores como arreglos arbitrarios de bytes, los mantiene ordenados y los almacena de forma duradera en disco. 

Lo más importante que debes entender desde el principio es que RocksDB es una biblioteca, no un servidor. No hay ningún proceso al cual conectarse, ningún puerto que abrir ni ningún lenguaje de consultas que aprender.

RocksDB se integra con una aplicación y se ejecuta dentro de ese proceso, leyendo y escribiendo archivos en el disco local. Esto hace que RocksDB sea rápido: no hay ningún salto de red entre el código de la aplicación y los datos con los que opera. Es minimalista porque deja deliberadamente la replicación, la fragmentación y las consultas en manos de lo que se construya sobre él.

En pocas palabras, RocksDB es un motor de almacenamiento: el componente alrededor del cual se construyen bases de datos como TiDB y YugabyteDB.

¿RocksDB es lo mismo que LevelDB?

No, pero ambos se originan en la misma base de código. RocksDB comenzó en 2012 como una bifurcación de LevelDB, el almacén clave-valor ligero que Jeff Dean y Sanjay Ghemawat escribieron en Google. 

LevelDB se creó para entornos modestos (por ejemplo, el backend de IndexedDB de un navegador o un único dispositivo integrado) y adoptó varias decisiones de diseño acordes con ellos, como la compactación en un solo hilo, el uso conservador de memoria y pocas opciones de ajuste.

Los ingenieros de Facebook, ahora Meta, tomaron esa base y la reconstruyeron para cargas de trabajo de servidores. El objetivo era aprovechar al máximo el hardware moderno mientras se manejaban conjuntos de datos mucho mayores que la memoria bajo una presión de escritura constante. 

RocksDB se publicó como código abierto en 2013 y desde entonces se ha alejado considerablemente de LevelDB. Ahora ofrece compactación multihilo, familias de columnas, transacciones, copias de seguridad, operadores de fusión, estilos de compactación configurables y una lista célebremente larga de opciones de ajuste.

LevelDB y RocksDB guardan cierto parecido familiar, pero hace una década que dejó de ser razonable tratarlos como intercambiables.

¿Cómo funciona RocksDB?

RocksDB se basa en un árbol de fusión estructurado por registros (árbol LSM), una estructura de datos que sacrifica la simplicidad de lectura a cambio de un mayor rendimiento de escritura. 

En esencia, las escrituras entrantes se guardan en un búfer en memoria llamado memtable. Al mismo tiempo, se agregan a un registro de escritura anticipada en disco para garantizar su durabilidad. 

Cuando la memtable se llena, se inmoviliza y se vuelca al disco como un archivo inmutable y ordenado llamado Sorted String Table (SST). Los archivos SST se acumulan en una jerarquía por niveles, y un proceso en segundo plano llamado compactación los fusiona continuamente. Descarta los valores sobrescritos y las claves eliminadas para mantener una estructura ordenada, limpia y duradera.

Las lecturas revisan primero la memtable y luego recorren los distintos niveles de archivos SST. Los filtros de Bloom permiten que RocksDB omita los archivos que no pueden contener la clave, mientras que una caché de bloques mantiene en memoria los datos de acceso frecuente. Así, la mayoría de las lecturas nunca consultan más de uno o dos archivos.

¿Cuál es la diferencia entre los árboles LSM y los árboles B?

Los árboles B, que son la estructura utilizada por la mayoría de las bases de datos tradicionales, actualizan los datos en el mismo lugar, lo que distribuye las escrituras aleatorias por todo el disco. Los árboles LSM agregan y agrupan los datos, lo que produce grandes escrituras secuenciales, justo lo que necesitan los SSD y las cargas con un alto volumen de ingesta. La contrapartida es que el valor actual de una clave puede abarcar varios archivos, por lo que se requieren compactación, filtros de Bloom y almacenamiento en caché para mantener controlado este costo. 

Cada decisión de diseño en un árbol LSM busca, en última instancia, equilibrar tres presiones:

• Amplificación de escritura
• Amplificación de lectura
• Amplificación de espacio

Mejorar dos de ellas suele empeorar la tercera. 

Este triángulo es el modelo mental más importante para comprender el ajuste de RocksDB. 

¿Para qué se usa RocksDB?

RocksDB se usa cuando una aplicación necesita un almacenamiento clave-valor rápido, duradero y ordenado en el disco local, sin la sobrecarga de ejecutar un servidor de base de datos independiente. Los ejemplos concretos muestran este patrón con más claridad que las categorías.

Kafka Streams guarda el estado de cada tarea de procesamiento —agregaciones en curso, uniones y cálculos por ventanas— en un almacén local de RocksDB. Así, el estado puede superar el tamaño de la memoria y sobrevivir a los reinicios sin agregar un recorrido de red a cada consulta.

ZippyDB de Meta envuelve RocksDB con una capa de replicación, gestión de fragmentos y servicios de configuración para ofrecer un almacén clave-valor distribuido y completamente administrado. La división de responsabilidades es clara: RocksDB proporciona el almacenamiento y todo lo relacionado con el servidor se construye a su alrededor.

La capa de almacenamiento de TiDB ejecuta RocksDB en cada nodo como motor de una base de datos SQL distribuida. Codifica la estructura de las tablas en prefijos de claves para que escanear una tabla se convierta en una única lectura contigua sobre claves ordenadas.

Cada validador de Solana basado en Agave escribe el ledger en RocksDB y usa el slot como clave, de modo que los datos consecutivos del ledger queden adyacentes en el disco.

Los dos últimos ejemplos son interesantes porque las claves se almacenan ordenadas —por bytes de forma predeterminada o mediante un comparador personalizado—, lo que permite realizar eficientemente escaneos por rango y búsquedas por prefijo.

Una parte sorprendentemente grande del diseño de esquemas en sistemas reales respaldados por RocksDB consiste en aprovechar ese orden.

¿Quién usa RocksDB?

Además de los sistemas anteriores, RocksDB es fundamental para cualquier sistema que necesite un motor de almacenamiento integrado, probado en producción y optimizado para escritura. Los equipos lo eligen porque heredan una década de robustecimiento de Meta en producción, en lugar de tener que desarrollar un motor desde cero.

En particular,

• Kafka Streams lo utiliza como motor predeterminado para los almacenes de estado
• Apache Flink también ofrece un backend de estado basado en RocksDB para estados con puntos de control demasiado grandes para mantenerse en memoria
• MyRocks lo integra como motor de almacenamiento de MySQL. Fue desarrollado en Meta para reducir el espacio de almacenamiento de algunas de las flotas de MySQL más grandes que existen
• TiKV, la capa de almacenamiento de TiDB, utiliza RocksDB con instancias separadas para los registros de Raft y los datos clave-valor
• DocDB, el almacén de documentos de YugabyteDB, utiliza RocksDB
• BlueStore de Ceph utiliza RocksDB para los metadatos del almacenamiento de objetos
• ArangoDB incluye RocksDB como su motor de almacenamiento predeterminado desde la versión 3.4 y como su único motor desde la versión 3.7

RocksDB se usa principalmente para cargas con muchas escrituras, que superan el tamaño de la memoria y se ejecutan en SSD, un punto que retomaremos más adelante en este artículo.

¿Cómo usa Solana RocksDB?

Solana es una blockchain de alto rendimiento y baja latencia basada en prueba de participación, reconocida por su enfoque en la velocidad, la eficiencia y las aplicaciones para consumidores. El ledger de Solana reside en RocksDB. El cliente validador Agave almacena el ledger en Blockstore, un componente que contiene una base de datos RocksDB dividida en espacios de claves independientes y ajustables. 

Las familias de columnas independientes contienen datos de shreds y códigos de borrado de shreds (es decir, las unidades sin procesar de datos del ledger a medida que llegan por la red), estados de transacciones, índices de direcciones a firmas y diversos metadatos.

El patrón de escritura de un validador es extremo frente a la mayoría de las cargas de bases de datos. Un validador debe ingerir shreds continuamente, usando como claves números de slot que aumentan de manera casi monótona, a la velocidad máxima de la red, para siempre. Un archivo sin depurar del ledger supera ampliamente los cientos de terabytes y crece, como mínimo, decenas de terabytes al año.

Con la compactación por niveles, las familias de columnas de shreds generaban tanto trabajo de compactación en segundo plano que los validadores comenzaron a sufrir pausas de escritura, el mecanismo integrado de RocksDB para ralentizar la ingesta cuando la compactación se retrasa. 

Alrededor de 2021, las familias de columnas de shreds cambiaron a la compactación FIFO, un estilo mínimo que simplemente elimina el archivo más antiguo cuando se alcanza el límite de tamaño. FIFO suele ser inseguro para cargas de trabajo generales. Sin embargo, como las claves de los shreds llegan en un orden de slots casi monótono, los validadores podían eliminar el archivo más antiguo porque contenía los slots más antiguos. Esto adaptó casi a la perfección el estilo de compactación a la forma de la carga de trabajo.

Las optimizaciones posteriores de la compactación por niveles redujeron su amplificación de E/S hasta el punto en que FIFO dejó de ofrecer ventajas. Por eso, la ruta FIFO quedó obsoleta en junio de 2024 y se eliminó en noviembre de ese año.

Firedancer, el cliente validador de Solana de Jump Crypto escrito en C, prescinde por completo de RocksDB y utiliza una capa de almacenamiento interna creada específicamente para ese fin.

Determinar si un motor de almacenamiento creado desde cero puede superar una década de robustecimiento y ajuste de RocksDB sigue siendo una pregunta abierta e interesante en la ingeniería de validadores.

¿Cuándo no conviene usar RocksDB?

RocksDB resulta inadecuado con más frecuencia de lo que su ubicuidad sugiere. Las posibilidades de ajuste son enormes, con cientos de opciones cuyas interacciones no son evidentes. Por eso, una configuración deficiente es la norma y no la excepción. 

Además, los valores predeterminados de RocksDB son razonables, pero no óptimos. Los desarrolladores deben comprender las contrapartidas de amplificación descritas anteriormente para obtener mejoras reales de rendimiento. Una ingesta intensa y sostenida puede superar la compactación en segundo plano y provocar pausas de escritura que suelen ocurrir cuando el sistema está más ocupado.

Además, RocksDB es una biblioteca, no un servidor. Todo lo que normalmente ofrecería un servidor de base de datos (por ejemplo, replicación, fragmentación, copias de seguridad, control de acceso, una capa de consultas y herramientas operativas) debe construirse por separado.

La forma de la carga de trabajo también importa enormemente. 

RocksDB es un motor orientado a filas, búsquedas puntuales y escaneos por rango. Las cargas analíticas que recorren grandes segmentos de datos y realizan agregaciones entre columnas funcionan mejor en un almacén columnar como ClickHouse.

Nada de esto es motivo para evitar RocksDB. Es un motivo para elegirlo deliberadamente. En Helius evaluamos estos riesgos directamente cuando rediseñamos nuestra capa de archivo y, aun así, elegimos RocksDB, porque la carga tenía exactamente la forma para la que se creó RocksDB: búsquedas puntuales y escaneos de rangos estrechos sobre un conjunto de datos grande y con muchas operaciones de anexado. 

Conclusión

RocksDB es un almacén clave-valor persistente, ordenado e integrable que sacrifica las comodidades operativas a cambio de rendimiento puro en el disco local. Se originó a partir de LevelDB, Meta lo robusteció para SSD y equipos multinúcleo, y ahora forma parte de diversos sistemas en todo el mundo: desde procesadores de flujos y bases de datos SQL distribuidas hasta clústeres de almacenamiento y el ledger de Solana.

Si te entusiasma trabajar en configuraciones de RocksDB de alto rendimiento a gran escala, ven a construir con nosotros.

Solana avanza a toda velocidad para convertirse en la capa de liquidación de las finanzas globales, y la infraestructura que la sustenta utiliza exactamente los mecanismos que describe esta serie. Resuelve problemas complejos de sistemas con algunos de los mejores equipos que el dinero puede comprar y a escala planetaria.

Estamos contratando para todo nuestro equipo de ingeniería. Consulta todos nuestros puestos disponibles en helius.dev/careers.