Les magasins de données clé-valeur (KVS) sont un segment à croissance rapide du monde des bases de données NoSQL qui est de plus en plus populaire ces derniers temps. Parce qu'ils ont le modèle de données le plus simple - arbitraire
des chaînes d'octets pour les clés, associées à une chaîne d'octets pour la valeur correspondante, elles peuvent être rapidement intégrées dans des applications qui ont des besoins de stockage très simplistes. Leurs API ont tendance à être tout aussi simples, ne fournissant que des opérations très primitives et les délivrant avec très peu de surcharge.
Bien qu'il existe actuellement un certain nombre de KVS orientés client-serveur, tels que Memcache et Redis, ce test n'utilise que des KVS intégrés, c'est-à-dire des KVS qui s'exécutent entièrement dans le processus d'application, au lieu de nécessiter une communication avec un processus de serveur de base de données. Notez que les KVS de ce type ne sont pas nouveaux, ils font partie de la plus ancienne famille de logiciels de stockage. Par exemple, BerkeleyDB est issu d'une bibliothèque de stockage utilisée sous Unix depuis les années 1980. Ces KVS ne sont pas non plus limités à une utilisation locale (hors réseau) - BerkeleyDB, LMDB et TokuDB sont entièrement transactionnels et ont été utilisés comme moteurs de stockage sous-jacents pour des serveurs comme MySQL et OpenLDAP pendant de nombreuses années. En effet, dans tous les autres magasins de données de niveau supérieur, SQL, NoSQL ou autre, vous trouverez un KVS intégré effectuant le travail réel.
De nombreuses applications de haut niveau utilisent désormais les KVS ; par exemple, les crypto-monnaies comme BitCoin utilisent un KVS pour stocker leur blockchain, qui est un journal complet de toutes leurs transactions. Les exigences du projet conduisant à l'utilisation d'un KVS peuvent inclure des taux de transaction très élevés (comme pour un grand site de commerce électronique), une latence très faible (par exemple, des commerçants à haute fréquence), une très petite empreinte (par exemple, des téléphones mobiles et d'autres environnements contraints) ou des combinaisons de tous trois.
Les tests exécutés ici sont dérivés d'un code de référence initialement écrit chez Google par les auteurs de LevelDB, puis porté sur plusieurs autres moteurs de bases de données par Symas Corp [ 2 ] . Le scénario de test est basé sur des benchmarks réalisés par l'équipe RocksDB de Facebook [ 3 ] et sur une version étendue de ces tests, couvrant davantage de moteurs de bases de données et de cas d'utilisation, réalisée par Symas Corp.
Un test comporte deux phases : une phase de chargement en masse où les enregistrements sont chargés dans un ordre séquentiel, puis une phase de lecture-écriture accédant aux enregistrements dans un ordre aléatoire.
Tous les moteurs de base de données testés ici sont des magasins clés/valeurs intégrés qui stockent les clés dans un ordre trié, prenant ainsi en charge le parcours ordonné des clés. En tant que tels, ils utilisent tous des variantes d'une structure de données d'arborescence de recherche. L'ensemble de données de test est choisi pour être environ 5 fois plus grand que la RAM sur les serveurs de test, pour montrer l'espace et l'efficacité d'E/S de chaque moteur de base de données.
Bien que les concepts sous-jacents soient liés, les moteurs de base de données adoptent tous des approches très différentes pour leurs implémentations. La plupart d'entre eux tentent de gérer leurs propres caches de données, dans le but de minimiser le nombre d'opérations d'E/S physiques nécessaires pour une charge de travail donnée. Chaque approche implique un compromis entre l'espace et le temps : l'utilisation d'une certaine quantité d'espace peut faire gagner un certain temps dans une circonstance donnée, mais cette économie sera inévitablement remboursée dans un autre aspect :
RocksDB fait le compromis entre simplicité et performances - il nécessite le réglage le plus complexe, avec plus de 40 paramètres devant être définis de manière optimale afin d'offrir les meilleures performances. TokuDB et BerkeleyDB suivent en termes de complexité de configuration. LevelDB et LMDB visent la simplicité de configuration, LMDB ne nécessitant aucun réglage.
RocksDB, LevelDB et TokuDB se concentrent sur les performances d'écriture ; leurs conceptions Log Structured Merge (LSM) Tree et Fractal Tree (FT), respectivement, reposent fortement sur des tampons d'écriture configurés par l'utilisateur pour agréger les écritures en mémoire avant de les valider sur le disque, permettant aux écritures finales d'être écrites séquentiellement et donc au plus haut vitesse du média sous-jacent. Le compromis est que l'ordre idéal pour les écritures n'est pas idéal pour les lectures, et leurs performances de lecture sont nettement inférieures. BerkeleyDB et LMDB sont des conceptions B+tree plus traditionnelles, se concentrant davantage sur les performances de lecture que sur les performances d'écriture.
WiredTiger essaie de couvrir toutes les bases, offrant à la fois des moteurs LSM et B+tree dans leur bibliothèque. Cette flexibilité nécessite également un niveau modéré de complexité de configuration.
RocksDB et LevelDB suppriment les fonctionnalités tout en visant des performances d'écriture maximales. BerkeleyDB, LMDB, TokuDB et WiredTiger se concentrent sur la fiabilité, offrant des transactions ACID complètes. En tant que tels, les quatre derniers moteurs sont facilement adaptés pour être utilisés dans les serveurs SQL, les serveurs LDAP et d'autres applications orientées transaction, tandis que les deux premiers sont moins adaptés à une telle utilisation.
Tous les moteurs, à l'exception de LMDB, utilisent leurs propres tampons d'écriture et caches de données gérés explicitement. LMDB utilise uniquement le cache de page du système d'exploitation. En tant que tels, tous les moteurs en plus de LMDB ont une surcharge CPU importante en raison de la gestion de ces tampons et de la copie de données plusieurs fois entre ces tampons. Par exemple, lors de la récupération d'un enregistrement sur un disque qui n'était pas précédemment mis en cache, BerkeleyDB effectue au moins une copie de mémoire à mémoire - d'abord les données sont lues par le système d'exploitation dans son cache de page, puis elles sont copiées dans le cache de page de BerkeleyDB. Enfin, les données sont copiées du cache BerkeleyDB vers le tampon fourni par l'utilisateur. LMDB est sans copie ; les données vont directement du périphérique de stockage au cache de la page du système d'exploitation, et ces données sont directement restituées à l'utilisateur. Des moteurs comme TokuDB effectuent encore plus de copies, car les données sur disque subissent plusieurs transformations de format avant d'être renvoyées à l'utilisateur. Ces multiples étapes consomment chacune de la mémoire, de sorte que l'architecture de copie de mémoire a une incidence directe sur le nombre d'enregistrements pouvant tenir simultanément dans la RAM, et donc sur la taille d'un ensemble de travail pouvant être utilisé à pleine vitesse. Étant donné que LMDB ne fait aucune copie de lui-même, il peut gérer le plus grand ensemble de données pour une taille de RAM donnée.
Certains des moteurs de base de données sont conçus pour être plus optimaux pour les opérations d'écriture, et certains sont davantage optimisés pour les lectures. La phase de chargement en bloc montre leur meilleure vitesse d'écriture. La phase de lecture-écriture aléatoire montre leur vitesse d'écriture dans le pire des cas, où un seul thread effectue des écritures sur des enregistrements sélectionnés de manière aléatoire, tandis que XX threads effectuent des lectures simultanées sur d'autres enregistrements sélectionnés de manière aléatoire. Il montre également comment chaque moteur gère les lectures dans un environnement fortement chargé.
Comme l'ont montré les tests Symas, les performances relatives de chaque moteur de base de données dépendent fortement de la taille des enregistrements utilisés. La taille d'enregistrement choisie ici est un compromis approximatif entre les enregistrements plus grands (pour lesquels les moteurs traditionnels basés sur Btree excellent) et les enregistrements plus petits (pour lesquels les conceptions basées sur LSM excellent).
Amazon