Compactaciones remotas en RocksDB-Cloud

(Hieu Pham) (10 de junio , 2020)

Introducción

RocksDB es un motor de almacenamiento LSM cuyo crecimiento ha proliferado enormemente en los últimos años . RocksDB-Cloud es de código abierto y es totalmente compatible con RocksDB, con la característica adicional de que todos los datos se vuelven duraderos al almacenarlos automáticamente en el almacenamiento en la nube (por ejemplo, Amazon S3).

Nosotros, en Rockset, usamos RocksDB-Cloud como uno de los componentes básicos del índice convergente distribuido de Rockset. Rockset está diseñado con principios nativos de la nube, y uno de los principios de diseño principales de una base de datos nativa de la nube es separar la computación del almacenamiento. Discutiremos cómo ampliamos RocksDB-Cloud para tener una separación clara de sus necesidades de almacenamiento y sus necesidades de cómputo.

Un compactador, operado por US Navy Seabees, que realiza la compactación del suelo

Motor LSM de RocksDB

RocksDB-Cloud almacena datos en SSD conectados localmente o discos giratorios. El SSD o el disco giratorio proporciona el almacenamiento necesario para almacenar los datos que sirve. Las nuevas escrituras en RocksDB-Cloud se escriben en una tabla de memoria en memoria, y luego, cuando la tabla de memoria está llena, se descarga a un nuevo archivo SST en el almacenamiento.

Al ser un motor de almacenamiento LSM, un conjunto de subprocesos de fondo se utilizan para la compactación, y la compactación es un proceso de combinar un conjunto de archivos SST y generar nuevos archivos SST con claves sobrescritas y claves eliminadas purgadas de los archivos de salida. La compactación necesita muchos recursos informáticos. Cuanto mayor sea la tasa de escritura en la base de datos, más recursos de cómputo se necesitan para la compactación, porque el sistema es estable solo si la compactación es capaz de mantenerse al día con las nuevas escrituras en su base de datos.

El problema cuando la computación y el almacenamiento no están desagregados

En una Sistema basado en RocksDB, la compactación ocurre en las CPU que son locales en el servidor que aloja el almacenamiento también. En este caso, la computación y el almacenamiento no se desagregan. Y esto significa que si su tasa de escritura aumenta pero el tamaño total de su base de datos sigue siendo el mismo, tendrá que aprovisionar dinámicamente más servidores, distribuir sus datos en todos esos servidores y luego aprovechar el cómputo adicional en estos servidores para mantenerse al día con el carga de compactación.

Esto tiene dos problemas:

  • Distribuir sus datos en más servidores no es instantáneo porque tiene que copiar una gran cantidad de datos para hacerlo. Esto significa que no puede reaccionar rápidamente a una carga de trabajo que cambia rápidamente.
  • La utilización de la capacidad de almacenamiento en cada uno de sus servidores es muy baja porque está distribuyendo sus datos a más servidores. Pierde la relación precio-rendimiento debido a todo el almacenamiento no utilizado en sus servidores.

Nuestra solución

La razón principal por la que RocksDB-Cloud es adecuado para separar el cálculo de compactación y el almacenamiento se debe a que es un motor de almacenamiento LSM. A diferencia de una base de datos B-Tree, RocksDB-Cloud nunca actualiza un archivo SST una vez que se crea. Esto significa que todos los archivos SST en todo el sistema son de solo lectura, excepto la porción minúscula de datos en su memoria activa. RocksDB-Cloud conserva todos los archivos SST en un almacén de objetos de almacenamiento en la nube como S3, y estos objetos en la nube son accesibles de manera segura desde todos sus servidores porque son de solo lectura.

Entonces, nuestra idea es que si un RocksDB -El servidor en la nube A puede encapsular un trabajo de compactación con su conjunto de objetos en la nube y luego enviar la solicitud a un servidor remoto sin estado B, y ese servidor B puede buscar los objetos relevantes del almacén en la nube, hacer la compactación y producir un conjunto de resultados. Archivos SST que se vuelven a escribir en el almacén de objetos en la nube y luego comunican esa información al servidor A: básicamente, hemos separado el almacenamiento (que reside en el servidor A) del cálculo de compactación (que reside en el servidor B). El servidor A tiene el almacenamiento y, mientras que el servidor B no tiene almacenamiento permanente, solo el cálculo necesario para la compactación. ¡Voila!

API de compactación conectable RocksDB

Ampliamos la API base de RocksDB con dos nuevos métodos que hacen que el motor de compactación en RocksDB sea conectable externamente. En db.h , presentamos una nueva API para registrar un servicio de compactación.

Status RegisterPluggableCompactionService(std::unique_ptr);

Esta API registra el complemento que se utiliza para ejecutar el trabajo de compactación por RocksDB. La compactación remota se realiza en dos pasos: Run y InstallFiles. Por lo tanto, el complemento, PluggableCompactionService , tendría 2 API:

Status Run(const PluggableCompactionParam& job, PluggableCompactionResult* result) std::vector InstallFiles(
const std::vector& remote_paths,
const std::vector& local_paths,
const EnvOptions& env_options, Env* local_env)

Run es donde ocurre la ejecución de la compactación.En nuestra arquitectura de compactación remota, Run enviaría un RPC a un nivel de compactación remoto y recibiría un resultado de compactación que tiene, entre otras cosas, la lista de archivos SST recientemente compactados.

InstallFiles es donde RocksDB instala los archivos SST recién compactados desde la nube (remote_paths) en su base de datos local (local_paths).

Nivel de compactación de Rockset

Ahora mostraremos cómo usamos el servicio de compactación conectable descrito anteriormente en el servicio de compactación de Rockset. Como se mencionó anteriormente, el primer paso, Run, envía un RPC a un nivel de compactación remoto con información de compactación, como nombres de archivos SST de entrada e información de compresión. Llamamos al host que ejecuta este trabajo de compactación un compactor.

El compactador , al recibir la solicitud de compactación, abriría una instancia de RocksDB-Cloud en Modo fantasma . Lo que esto significa es que RocksDB-Cloud abre la base de datos local con solo los metadatos necesarios sin obtener todos los archivos SST del almacenamiento en la nube. Una vez que abre la instancia de RocksDB en modo fantasma , ejecuta el trabajo de compactación, incluida la obtención de los archivos SST necesarios, los compacta y carga los archivos SST recién compactados en un almacenamiento temporal en la nube.

Estas son las opciones para abrir RocksDB-Cloud en el compactador :

rocksdb::CloudOptions cloud_options; cloud_options.ephemeral_resync_on_open = false; cloud_options.constant_sst_file_size_in_sst_file_manager = 1024; cloud_options.skip_cloud_files_in_getchildren = true;rocksdb::Options rocksdb_options;
rocksdb_options.max_open_files = 0; rocksdb_options.disable_auto_compactions = true; rocksdb_options.skip_stats_update_on_db_open = true; rocksdb_options.paranoid_checks = false; rocksdb_options.compaction_readahead_size = 10 * 1024 * 1024;

Hay múltiples desafíos que enfrentamos durante el desarrollo del nivel de compactación, y nuestras soluciones:

Mejorar la velocidad de apertura de RocksDB-Cloud en ghost mode

Durante la apertura de una instancia de RocksDB, además de obtener todos los archivos SST de la nube (que hemos desactivado con ghost modo), hay muchas otras operaciones que podrían ralentizar el proceso de apertura, en particular, obtener la lista de archivos SST y obtener el tamaño de cada archivo SST. Normalmente, si todos los archivos SST residen en el almacenamiento local, la latencia de estas operaciones de obtención de tamaño de archivo sería pequeña. Sin embargo, cuando el compactador abre RocksDB-Cloud, cada una de estas operaciones daría como resultado una solicitud remota al almacenamiento en la nube, y la latencia combinada total se vuelve prohibitivamente cara. En nuestra experiencia, para una instancia de RocksDB-Cloud con miles de archivos SST, abrirla tomaría hasta un minuto debido a miles de solicitudes de obtención de tamaño de archivo a S3. Para evitar esta limitación, presentamos varias opciones en las opciones de RocksDB-Cloud para deshabilitar estos RPC durante la apertura. Como resultado, el tiempo medio de apertura va de 7 segundos a 700 milisegundos.

Deshabilitar la compactación L0 -> L0

La compactación remota es una compensación entre la velocidad de una sola compactación y la capacidad de ejecutar más trabajos de compactación en paralelo. Es porque, naturalmente, cada trabajo de compactación remota sería más lento que la misma compactación ejecutada localmente debido al costo de transferencia de datos en la nube. Por lo tanto, nos gustaría minimizar el cuello de botella del proceso de compactación, donde RocksDB-Cloud no puede paralelizar, tanto como sea posible.

En la arquitectura LSM, la compactación L0-> L1 generalmente no es paralelizable porque Los archivos L0 tienen rangos superpuestos. Por lo tanto, cuando se produce una compactación L0-> L1, RocksDB-Cloud tiene la capacidad de ejecutar también la compactación L0-> L0, con el objetivo de reducir la cantidad de archivos L0 y evitar paradas de escritura debido a que RocksDB-Cloud golpea el archivo L0 límite. Sin embargo, la compensación es que cada archivo L0 aumentaría de tamaño después de cada compactación L0-> L0.

En nuestra experiencia, esta opción causa más problemas que los beneficios que trae, porque tener archivos L0 más grandes da como resultado una compactación L0-> L1 mucho más larga, lo que agrava el cuello de botella de RocksDB-Cloud. Por lo tanto, deshabilitamos la compactación L0-> L0 y, en su lugar, vivimos con el raro problema de la pérdida de escritura. De nuestro experimento, la compactación de RocksDB-Cloud se pone al día con las escrituras entrantes mucho mejor.

Puede usarlo ahora

RocksDB-Cloud es un proyecto de código abierto, por lo que nuestro trabajo puede ser aprovechado por cualquier otro desarrollador de RocksDB que desee obtener beneficios separando su cálculo de compactación de sus necesidades de almacenamiento. Ahora estamos ejecutando el servicio de compactación remota en producción. Está disponible con la versión 6.7.3 de RocksDB-Cloud. Discutimos todas las cosas sobre RocksDB-Cloud en el canal público de Slack en http://bit.ly/rockset-community-channel .

Autores:

Hieu Pham – Ingeniero de software, Rockset
Dhruba Borthakur – CTO, Rockset

Publicado originalmente en https: // rockset.com el 4 de junio de 2020.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *