Compactions à distance dans RocksDB-Cloud

(Hieu Pham) (10 juin , 2020)

Introduction

RocksDB est un moteur de stockage LSM dont la croissance a proliféré énormément ces dernières années . RocksDB-Cloud est open-source et est entièrement compatible avec RocksDB, avec la fonctionnalité supplémentaire que toutes les données sont rendues durables en les stockant automatiquement dans le stockage cloud (par exemple Amazon S3).

Chez Rockset, nous utilisons RocksDB-Cloud comme lun des éléments constitutifs de l index convergé distribué de Rockset. Rockset est conçu avec des principes natifs du cloud, et lun des principaux principes de conception dune base de données native du cloud est de séparer le calcul du stockage. Nous allons discuter de la façon dont nous avons étendu RocksDB-Cloud pour avoir une séparation nette de ses besoins de stockage et de ses besoins de calcul.

Un compacteur, exploité par US Navy Seabees, effectuant le compactage du sol

Moteur LSM de RocksDB

RocksDB-Cloud stocke les données sur des disques SSD ou des disques rotatifs connectés localement. Le SSD ou le disque rotatif fournit le stockage nécessaire pour stocker les données quil sert. Les nouvelles écritures dans RocksDB-Cloud sont écrites dans une table mémoire en mémoire, puis lorsque la table mémoire est pleine, elle est vidée dans un nouveau fichier SST dans le stockage.

Étant un moteur de stockage LSM, un ensemble des threads darrière-plan sont utilisés pour le compactage, et le compactage est un processus de combinaison dun ensemble de fichiers SST et de génération de nouveaux fichiers SST avec des clés écrasées et des clés supprimées purgées des fichiers de sortie. Le compactage a besoin de beaucoup de ressources de calcul. Plus le taux décriture dans la base de données est élevé, plus les ressources de calcul sont nécessaires pour le compactage, car le système nest stable que si le compactage est capable de suivre les nouvelles écritures dans votre base de données.

Le problème lorsque le calcul et le stockage ne sont pas désagrégés

Dans un cas typique Système basé sur RocksDB, le compactage se produit sur des processeurs locaux sur le serveur qui héberge également le stockage. Dans ce cas, le calcul et le stockage ne sont pas désagrégés. Et cela signifie que si votre taux décriture augmente mais que la taille totale de votre base de données reste la même, vous devrez provisionner dynamiquement plus de serveurs, répartir vos données sur tous ces serveurs, puis exploiter le calcul supplémentaire sur ces serveurs pour suivre le rythme. charge de compactage.

Cela pose deux problèmes:

  • La diffusion de vos données sur plusieurs serveurs nest pas instantanée car vous devez copier beaucoup de données pour ce faire. Cela signifie que vous ne pouvez pas réagir rapidement à une charge de travail en évolution rapide.
  • Lutilisation de la capacité de stockage sur chacun de vos serveurs devient très faible car vous étalez vos données sur davantage de serveurs. Vous perdez sur le rapport qualité-prix à cause de tout le stockage inutilisé sur vos serveurs.

Notre solution

La principale raison pour laquelle RocksDB-Cloud est adapté pour séparer le calcul de compactage et le stockage, cest parce quil sagit dun moteur de stockage LSM. Contrairement à une base de données B-Tree, RocksDB-Cloud ne met jamais à jour un fichier SST une fois quil est créé. Cela signifie que tous les fichiers SST de lensemble du système sont en lecture seule, à lexception de la partie minuscule des données de votre table mémoire active. RocksDB-Cloud persiste tous les fichiers SST dans un magasin dobjets de stockage cloud comme S3, et ces objets cloud sont accessibles en toute sécurité depuis tous vos serveurs car ils sont en lecture seule.

Donc, notre idée est que si un RocksDB -Le serveur cloud A peut encapsuler un travail de compactage avec son ensemble dobjets cloud, puis envoyer la requête à un serveur sans état distant B-et ce serveur B peut récupérer les objets pertinents du magasin cloud, effectuer le compactage, produire un ensemble de sortie Fichiers SST qui sont réécrits dans le magasin dobjets cloud, puis communiquent ces informations au serveur A – nous avons essentiellement séparé le stockage (qui réside sur le serveur A) du calcul de compactage (qui réside sur le serveur B). Le serveur A a le stockage et tandis que le serveur B na pas de stockage permanent, mais seulement le calcul nécessaire pour le compactage. Voila!

API de compactage enfichable RocksDB

Nous avons étendu lAPI RocksDB de base avec deux nouvelles méthodes qui rendent le moteur de compactage de RocksDB enfichable en externe. Dans db.h , nous introduisons une nouvelle API pour enregistrer un service de compactage.

Status RegisterPluggableCompactionService(std::unique_ptr);

Cette API enregistre le plugin qui est utilisé pour exécuter le travail de compactage par RocksDB. Le compactage à distance seffectue en deux étapes: Run et InstallFiles. Par conséquent, le plugin, PluggableCompactionService , aurait 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 est lendroit où lexécution du compactage a lieu.Dans notre architecture de compactage à distance, Run enverrait un RPC à un niveau de compactage distant et recevrait un résultat de compactage contenant, entre autres, la liste des fichiers SST nouvellement compactés.

InstallFiles est lendroit où RocksDB installe les fichiers SST récemment compactés depuis le cloud (remote_paths) dans sa base de données locale (local_paths).

Niveau de compactage de Rockset

Nous allons maintenant montrer comment nous avons utilisé le service de compactage enfichable décrit ci-dessus dans le service de compactage de Rockset. Comme mentionné ci-dessus, la première étape, Run, envoie un RPC à un niveau de compactage distant avec des informations de compactage telles que les noms de fichiers SST dentrée et les informations de compression. Nous appelons lhôte qui exécute ce travail de compactage un compactor.

Le compacteur , à la réception de la demande de compactage, ouvrirait une instance RocksDB-Cloud dans Mode fantôme . Cela signifie que RocksDB-Cloud ouvre la base de données locale avec uniquement les métadonnées nécessaires sans récupérer tous les fichiers SST du stockage cloud. Une fois quil ouvre linstance RocksDB en mode fantôme , il exécute alors le travail de compactage, y compris la récupération des fichiers SST requis, les compacte et télécharge les fichiers SST nouvellement compactés vers un stockage temporaire dans le cloud.

Voici les options pour ouvrir RocksDB-Cloud dans le compacteur :

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;

Les défis sont multiples nous avons été confrontés lors du développement du niveau de compactage, et de nos solutions:

Améliorer la vitesse douverture de RocksDB-Cloud dans ghost mode

Lors de louverture dune instance RocksDB, en plus de récupérer tous les fichiers SST depuis le cloud (que nous avons désactivés avec ghost mode), il existe plusieurs autres opérations qui pourraient ralentir le processus douverture, notamment lobtention de la liste des fichiers SST et lobtention de la taille de chaque fichier SST. Normalement, si tous les fichiers SST résident dans le stockage local, la latence de ces opérations get-file-size serait faible. Cependant, lorsque le compacteur ouvre RocksDB-Cloud, chacune de ces opérations se traduirait par une requête à distance au stockage cloud, et la latence totale combinée devient prohibitive. Daprès notre expérience, pour une instance RocksDB-Cloud avec des milliers de fichiers SST, son ouverture prendrait jusquà une minute en raison de milliers de requêtes get-file-size adressées à S3. Afin de contourner cette limitation, nous avons introduit diverses options dans les options RocksDB-Cloud pour désactiver ces RPC lors de louverture. En conséquence, le temps douverture moyen passe de 7 secondes à 700 millisecondes.

Désactiver le compactage L0 -> L0

Le compactage à distance est un compromis entre la vitesse dun seul compactage et la possibilité dexécuter plus de travaux de compactage en parallèle. Cest parce que, naturellement, chaque travail de compactage à distance serait plus lent que le même compactage exécuté localement en raison du coût du transfert de données dans le cloud. Par conséquent, nous souhaitons minimiser le goulot détranglement du processus de compactage, où RocksDB-Cloud ne peut pas paralléliser autant que possible.

Dans larchitecture LSM, le compactage L0-> L1 nest généralement pas parallélisable car Les fichiers L0 ont des plages qui se chevauchent. Par conséquent, lorsquun compactage L0-> L1 se produit, RocksDB-Cloud a la capacité dexécuter également le compactage L0-> L0, dans le but de réduire le nombre de fichiers L0 et déviter les blocages décriture dus à RocksDB-Cloud frappant le fichier L0 limite. Cependant, le compromis est que chaque fichier L0 augmenterait en taille après chaque compactage L0-> L0.

Daprès notre expérience, cette option cause plus de problèmes que les avantages quelle apporte, car avoir des fichiers L0 plus volumineux se traduit par un compactage L0-> L1 beaucoup plus long, aggravant le goulot détranglement de RocksDB-Cloud. Par conséquent, nous désactivons le compactage L0-> L0 et vivons avec le rare problème de blocage décriture à la place. Daprès notre expérience, le compactage RocksDB-Cloud rattrape beaucoup mieux les écritures entrantes.

Vous pouvez lutiliser maintenant

RocksDB-Cloud est un projet open-source, donc notre travail peut être exploité par tout autre développeur RocksDB qui souhaite tirer des avantages en séparant son calcul de compactage de ses besoins de stockage. Nous exécutons actuellement le service de compactage à distance en production. Il est disponible avec la version 6.7.3 de RocksDB-Cloud. Nous discutons de tout ce qui concerne RocksDB-Cloud dans la chaîne publique Slack à http://bit.ly/rockset-community-channel .

Auteurs:

Hieu Pham – Ingénieur logiciel, Rockset
Dhruba Borthakur – CTO, Rockset

Publié à lorigine à https: // rockset.com le 4 juin 2020.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *