Bigtable pour les utilisateurs d'Aerospike

Ce document aide les développeurs de logiciels et les administrateurs de bases de données à migrer des applications Aerospike existantes avec Bigtable en tant que base de données. Il s'appuie sur vos connaissances d'Aerospike pour décrire les concepts que vous devez comprendre avant de migrer vers Bigtable.

Pour vous aider à commencer à utiliser Bigtable et Aerospike, ce document effectue les opérations suivantes :

  • Compare la terminologie entre Aerospike et Bigtable.
  • Présente les opérations Bigtable et décrit la mise en page des données dans Bigtable.
  • Explique la modélisation des données et les principales considérations de conception.
  • Clarifie la façon dont la réplication est effectuée et son impact.

Pour en savoir plus sur le processus de migration et les outils Open Source que vous pouvez utiliser pour effectuer votre migration, consultez Migrer d'Aerospike vers Bigtable.

Comparaison terminologique

Aerospike et Bigtable sont toutes deux des bases de données NoSQL distribuées, mais elles diffèrent considérablement en termes de conception, de fonctionnement et de terminologie.

Dans Aerospike, les données sont stockées dans des enregistrements. Chaque enregistrement contient un ou plusieurs bins nommés, ainsi que des métadonnées telles que la taille de l'enregistrement (en octets), la valeur TTL (Time To Live) et la dernière heure de mise à jour (LUT).

Bigtable stocke les données dans des tables évolutives, chacune constituant un mappage de clés/valeurs triées. La table est composée de lignes indexées par des clés de ligne et de colonnes identifiées par un qualificatif de colonne. Si elles sont liées les unes aux autres, les colonnes peuvent former une famille de colonnes. Cette structure vous permet de stocker plusieurs versions d'une valeur sous la même clé. Chaque version est identifiée par un code temporel unique. Les versions antérieures peuvent être filtrées lors des opérations de lecture ou supprimées par le biais du garbage collection en fonction des règles configurées.

Pour en savoir plus, consultez Modèle de stockage Bigtable.

Le tableau suivant décrit les concepts partagés et la terminologie correspondante utilisée par chaque produit :

Aerospike Bigtable
Aucun élément ne correspond directement. Instance : groupe géré de clusters dans différentes zones ou régions Google Cloud entre lesquelles la réplication et le routage de connexion se produisent.
cluster : déploiement Aerospike composé d'un ensemble de nœuds. cluster : groupe de nœuds dans les mêmes zones géographiques Google Cloud .
Nœud : serveur fournissant des ressources de calcul et possédant son propre espace de stockage. node : serveur qui ne fournit que du calcul. Le stockage est géré par Colossus, un système de fichiers distribué distinct.
namespace : stocke des paramètres tels que la durée de vie (TTL) ou le type de stockage. Dans un espace de noms, les données sont subdivisées en ensembles et en enregistrements. table : l'équivalent le plus proche d'un espace de noms Aerospike. Certains paramètres sont définis pour toutes les tables au niveau du cluster. Il est possible d'exercer un contrôle plus précis au niveau de la table ou de la famille de colonnes.
set : utilisé pour la division logique des enregistrements et des paramètres tels que la taille de la période de validité (TTL) et du capping. Les clés doivent être uniques dans un ensemble. Aucun élément ne correspond directement.
Aucun élément ne correspond directement. table : ressource au niveau de l'instance qui est automatiquement répliquée sur chaque cluster. Une table contient un ensemble de valeurs identifiées par des clés de ligne uniques. Les tables sont partiellement remplies, ce qui signifie qu'elles n'utilisent pas d'espace supplémentaire pour stocker les colonnes qui ne contiennent aucune valeur.
Aucun élément ne correspond directement. tablet : plage continue de lignes stockées ensemble. Bigtable utilise des tablets pour l'équilibrage de charge en les attribuant à des nœuds. Les limites des tablettes sont dynamiques. Elles peuvent être divisées ou fusionnées au fil du temps.
Enregistrement : ensemble de bins nommés utilisés pour stocker des données. Elle ne doit pas dépasser 8 Mo. Ligne : ensemble de valeurs identifiées par la famille de colonnes, le qualificatif de colonne et l'horodatage. Toutes les opérations sont atomiques au niveau des lignes.
Aucun élément ne correspond directement. Famille de colonnes : groupe de colonnes triées par ordre lexicographique. La récupération de mémoire est définie à ce niveau.
bin : paire clé-valeur où le nom du bin est l'identifiant d'une valeur dans un enregistrement. qualificatif de colonne : libellé d'une valeur stockée dans une table.
Aucun élément ne correspond directement. cellule : libellé d'une valeur horodatée stockée dans une table.
Digest(enregistrement) : hachage d'un triplet identifiant un enregistrement : espace de noms, ensemble et clé. Aucun élément ne correspond directement.
key : identifiant d'enregistrement unique dans un ensemble. Clé de ligne : identifiant de ligne unique dans une table.
AQL : outil de ligne de commande permettant de parcourir les données et de développer des fonctions définies par l'utilisateur pour la base de données Aerospike. GoogleSQL : langage de requête utilisé par plusieurs services Google Cloud , y compris Spanner, BigQuery et Bigtable.

Limites des types de données

Le tableau suivant compare les limites des types de données utilisés par Aerospike et Bigtable :

Aerospike Bigtable
namespace : le nombre maximal d'espaces de noms pour l' édition Enterprise est de 32. table : une instance peut comporter jusqu'à 1 000 tables. Le nom d'une table ne peut pas comporter plus de 50 caractères.
set : un cluster peut comporter jusqu'à 4 095 ensembles. Le nom d'un ensemble ne peut pas dépasser 63 octets. Aucun élément ne correspond directement.
record : la taille maximale de l'enregistrement est de 8 Mo. row : la taille maximale des lignes est de 256 Mo.
Aucun élément ne correspond directement. Famille de colonnes : le nombre de familles de colonnes est illimité, mais au-delà de 100, les performances peuvent se dégrader.
bin : le nombre de bins est illimité, mais chacun d'eux ne peut contenir plus de 1 Mo de données. Le nom du bin ne peut pas dépasser 15 octets. Qualificateur de colonne : la limite est de 100 Mo, mais il est recommandé de ne pas dépasser 10 Mo. Le nombre de colonnes est illimité.
key : la taille maximale de la clé est de 8 Ko. Clé de ligne : la taille maximale de la clé de ligne est de 4 Ko.

Pour en savoir plus sur les limites de Bigtable et d'Aerospike, consultez respectivement Quotas et limites et Limites et seuils du système Aerospike.

Architecture

Les sections suivantes présentent une vue d'ensemble de l'architecture de Bigtable et d'Aerospike.

Bigtable

Les nœuds Bigtable sont distincts de la couche de stockage, ce qui signifie qu'ils n'affectent pas la durabilité des données. Les clients de table Bigtable ne connaissent pas la distribution des données sous-jacentes. Une couche de routage supplémentaire distribue les requêtes au nœud approprié. Chaque nœud gère un sous-ensemble des requêtes adressées au cluster. Une table Bigtable est segmentée en blocs de lignes contiguës, appelés tablets, qui sont stockés sur Colossus, un système de fichiers distribué offrant une durabilité élevée. Chaque tablet est associé à un nœud Bigtable spécifique.

Les clients du cluster Bigtable communiquent avec les nœuds via la couche de routage qui distribue les données au nœud approprié.

L'architecture de Bigtable offre les avantages suivants :

  • Les clients Bigtable n'ont pas besoin de connaître la distribution des données ni l'équilibrage de charge. Ces complexités sont gérées par la couche de routage.
  • Le rééquilibrage s'effectue très rapidement et la récupération en cas d'échec est rapide, car les données réelles ne sont pas copiées entre les nœuds.
  • En cas d'échec d'un nœud Bigtable, aucune donnée n'est perdue.

Aerospike

Contrairement à Bigtable, le stockage d'Aerospike se trouve sur les nœuds qui le desservent. Chaque nœud (serveur) du cluster Aerospike est identique. Les données de chaque espace de noms sont divisées en exactement 4 096 partitions en hachant les noms des enregistrements. Ces partitions sont réparties de manière égale entre les nœuds.

Les nœuds se connaissent et rééquilibrent les partitions stockées lorsque le cluster change. Chaque fois qu'un changement de cluster se produit, les réplicas élisent un réplica principal qui coordonne le rééquilibrage. Les bibliothèques clientes sont censées suivre la réplique qui stocke la partition principale et envoyer les requêtes d'écriture aux bonnes répliques. Si un client envoie une requête au mauvais nœud (ce qui peut arriver lors du rééquilibrage), la requête est redirigée par les nœuds.

Les clients du cluster Aerospike communiquent avec les nœuds qui gèrent le rééquilibrage de la charge de travail.

Réplication

Cette section compare le processus de réplication pour Aerospike et Bigtable.

Bigtable

Une instance Bigtable peut être constituée d'un seul cluster ou de plusieurs clusters répliqués. Une table est toujours répliquée sur tous les clusters d'une instance. Vous pouvez ajouter ou supprimer des clusters d'une instance avec un impact minimal sur les autres clusters.

Bigtable offre une cohérence écriture-lecture au sein d'un même cluster. Les écritures sont effectuées sur un seul cluster et deviennent cohérentes à terme dans les autres clusters de l'instance. Contrairement à Aerospike, Bigtable ne perd pas les mises à jour intermédiaires, car les cellules individuelles sont versionnées en interne, ce qui garantit qu'aucune écriture n'est perdue. Chaque cluster diffuse les cellules comportant les horodatages les plus récents.

L'API Bigtable propose un jeton de cohérence au niveau de la table, qui peut être utilisé pour vérifier si toutes les modifications apportées avant la création du jeton ont été entièrement répliquées.

Aerospike

Aerospike gère la réplication au sein d'un cluster au niveau de la partition. Un espace de noms est divisé en partitions qui sont réparties de manière égale entre les nœuds. La cohérence forte est assurée au sein d'un cluster. Une opération d'écriture n'est confirmée qu'une fois que toutes les répliques du cluster l'ont accusée réception.

La réplication entre centres de données (XDR) peut être configurée pour synchroniser les données entre différents clusters. La convergence des bins d'Aerospike garantit que les données sont identiques dans tous les centres de données à la fin de la réplication. Toutefois, les mises à jour intermédiaires peuvent être perdues.

Pour la durabilité, l'algorithme de cohérence basé sur les listes d'Aerospike nécessite N+1 copies pour gérer N défaillances.

Modèle de données

Cette section compare les modèles de données utilisés par Bigtable et Aerospike.

Schéma flexible

Aerospike n'applique pas de contraintes de schéma, ce qui permet à chaque enregistrement d'avoir des bins différents avec des types de valeurs variables. De même, Bigtable est compatible avec les colonnes clairsemées. Ainsi, aucun espace de stockage n'est consommé pour les colonnes sans valeur. Bien qu'il n'existe aucune limite stricte concernant le nombre de colonnes ou de familles de colonnes, il est préférable de ne pas dépasser 100 familles de colonnes pour des raisons de performances.

Conception des clés de ligne

Bigtable identifie les lignes par des clés de ligne, qui doivent être uniques dans une table. Elles sont triées de manière lexicographique et regroupées dans des tablettes. Cela diffère d'Aerospike, où les enregistrements sont répartis sur les nœuds en fonction de leur hachage. Les clés de ligne doivent être conçues de manière à ce que les lignes fréquemment consultées ensemble soient également stockées ensemble.

Types de données

Aerospike est compatible avec les types de données avancés, y compris les scalaires, GeoJSON, HyperLogLogs, les listes et les objets imbriqués. Ces types peuvent être indexés et interrogés avec la prise en charge des index secondaires. De plus, Aerospike fournit des API côté serveur qui permettent d'effectuer des opérations complexes sur ces types de données, comme le filtrage par géolocalisation ou la manipulation du contenu des listes.

L'API Bigtable se concentre principalement sur la gestion des octets bruts, à quelques exceptions près. Il utilise également de manière native INT64 pour les codes temporels et les compteurs qui peuvent être incrémentés en tant qu'opération atomique. Le langage de requête est également compatible avec de nombreux types complexes tels que les scalaires, les objets JSON et les bins HLL. Les types avancés pourront être de plus en plus compatibles à l'avenir, mais au moment de la rédaction de ce document, il n'existe aucun moyen de les insérer dans Bigtable. Tout est sérialisé côté client. Vous pouvez utiliser la bibliothèque d'adaptateurs de aerospike-migration-tools pour sérialiser vos types de données.

Famille de colonnes

Dans Bigtable, les familles de colonnes définissent les colonnes d'une table qui sont stockées et récupérées ensemble. Au moins une famille de colonnes doit exister pour chaque table. Les colonnes associées doivent être regroupées dans la même famille. Les données ayant des exigences de conservation différentes doivent être séparées dans des familles de colonnes distinctes, car les règles de récupération de mémoire s'appliquent au niveau de la famille de colonnes.

Qualificatifs de colonne

Dans Bigtable, les qualificatifs de colonne sont utilisés au sein d'une famille de colonnes pour définir des colonnes individuelles. Les tables peuvent contenir des millions de colonnes. Toutefois, il est recommandé de limiter le nombre de colonnes dans une même ligne. Les qualificatifs de colonne peuvent également être traités comme des données, ce qui permet d'intégrer directement des valeurs dans le nom de la colonne pour gagner de l'espace.

Cellules

Dans Bigtable, une cellule est l'intersection de la clé de ligne et du nom de la colonne (une famille de colonnes combinée à un qualificatif de colonne). Chaque cellule contient une ou plusieurs valeurs horodatées pouvant être fournies par le client ou appliquées automatiquement par le service.

Index secondaires

Les vues matérialisées continues peuvent servir d'index secondaires asynchrones, ce qui permet d'interroger les tables à l'aide de différents attributs ou modèles de recherche. Pour en savoir plus, consultez Créer un index secondaire asynchrone.

Transactions

Bigtable et Aerospike ne sont pas compatibles avec les transactions multilignes, mais diffèrent en termes de fonctionnalités monolignes. Bigtable fournit des écritures à ligne unique et à cohérence totale au sein d'un cluster, et accepte les transactions à ligne unique via les requêtes mutate-row. Elles permettent d'effectuer plusieurs opérations sur une même ligne, toutes exécutées de manière atomique, et qui réussissent ou échouent toutes. Il existe également des opérations de lecture-modification-écriture et de vérification-mutation, mais elles ne sont pas disponibles avec les profils de routage multicluster. En revanche, Aerospike étend les transactions sur une seule ligne avec la manipulation des données côté serveur et l'exécution des fonctions définies par le client.

Équilibrage de charge et basculement

Aerospike utilise Smart Client pour gérer l'équilibrage de charge côté client. Processus s'exécutant côté client, qui connaît l'état du cluster et la distribution des données. Ce client est responsable du routage de la requête.

Si un nœud échoue ou qu'un nouveau nœud est ajouté, le cluster doit être rééquilibré. Un nœud principal temporaire est choisi pour orchestrer le rééquilibrage et la redistribution des partitions entre les nœuds. Pendant ce temps, le cluster reste opérationnel, mais le client doit suivre les modifications pour le routage des requêtes. Si une requête atteint le mauvais nœud, elle est acheminée en interne vers le bon.

Le client Bigtable est un client léger qui masque toutes les complexités telles que l'état du cluster et la distribution des données à l'utilisateur. Le routage de la requête est géré par la couche suivante, un client lourd au sein de l'infrastructure Bigtable Google Cloud.

Une autre différence réside dans la règle de routage, qui n'est pas disponible dans Aerospike. Bigtable utilise des profils d'application pour gérer le routage des requêtes, avec des priorités configurables pour contrôler l'ordre dans lequel les requêtes sont traitées. Il existe deux types de règles de routage : à cluster unique et multicluster. Un profil multicluster achemine les opérations vers le cluster disponible le plus proche. Les clusters d'une même région sont considérés comme étant équidistants du point de vue du routeur d'opérations. Si le nœud responsable de la plage de clés demandée est surchargé ou temporairement indisponible dans un cluster, ce profil assure le basculement automatique. En revanche, Aerospike ne fournit pas de basculement automatique en cas de défaillance complète du cluster.

Sauvegarde et restauration

Aerospike fournit des outils de sauvegarde et de restauration externes appelés asbackup et asrestore, qui créent des sauvegardes logiques côté client et sont analogues à l'exécution d'un scan. La gestion des sauvegardes peut également être effectuée via le service de sauvegarde Aerospike ou l'opérateur Kubernetes Aerospike, qui utilisent tous deux asbackup et asrestore en interne, et fournissent une planification et une coordination multiprocessus. Les sauvegardes ne sont pas atomiques, ce qui signifie que les opérations d'écriture effectuées pendant la sauvegarde peuvent ne pas être enregistrées.

Bigtable propose deux méthodes pour répondre aux besoins de sauvegarde courants : les sauvegardes Bigtable et les exportations de données gérées. Les sauvegardes créent des copies reproductibles d'une table, qui sont stockées en tant qu'objets membres d'un cluster. Vous pouvez restaurer des sauvegardes en tant que nouvelle table du cluster qui a déclenché la sauvegarde. Les sauvegardes sont conçues pour créer des points de restauration en cas de corruption au niveau de l'application. Les sauvegardes Bigtable ne sont pas non plus atomiques. Des modifications peuvent être apportées à une section de la table déjà copiée.

Principales différences dans la gestion des sauvegardes

  • Les sauvegardes Aerospike sont créées côté client. Ils ne nécessitent pas d'espace supplémentaire côté serveur, mais sont plus lents. Dans Bigtable, une sauvegarde partage l'espace de stockage physique avec la table source et les autres sauvegardes de la table.
  • L'utilisateur d'Aerospike doit gérer l'exportation, le stockage et la suppression des anciennes sauvegardes. Comme les sauvegardes dans Bigtable sont entièrement intégrées, toutes ces actions sont effectuées automatiquement par le service Bigtable.

Considérations sur les performances

Comme Aerospike et Bigtable traitent les opérations de lecture et d'écriture différemment, leurs performances varient. Il est important d'en tenir compte. Le tableau suivant inclut plusieurs exemples de différences de performances entre les deux bases de données. Pour en savoir plus, consultez les Consignes relatives aux performances de Bigtable.

Considération Bigtable Aerospike
Lignes chaudes Distribue les tablets et les opérations pour égaliser l'utilisation des ressources. Une ligne fréquemment consultée peut être isolée dans un tablet à une seule ligne sur un nœud, ce qui limite l'impact sur les autres lignes. Distribue les lignes en fonction des hachages sur tous les nœuds, quel que soit le trafic. Une ligne chaude peut affecter les performances d'une partition entière.
Scans over sorted keys (Analyses sur les clés triées) Stocke les données de manière lexicographique, ce qui le rend très efficace pour le streaming de données triées. Distribue les enregistrements en fonction des hachages. Par conséquent, l'analyse de nombreuses clés consécutives nécessite d'interroger plusieurs nœuds et d'agréger les résultats, ce qui peut être plus lent. Prend en charge les index secondaires, y compris les types avancés, ce qui peut réduire la nécessité d'effectuer des analyses.
Insertion de nombreuses clés consécutives Stocke les données de manière lexicographique, ce qui signifie qu'un seul nœud gère de nombreuses opérations d'écriture de clés consécutives. Par conséquent, un modèle de lecture ou d'écriture peut se retrouver sur le nœud contenant la tablette responsable de la fin de l'espace de clé de ligne, ce qui le surcharge effectivement. Distribue les clés en fonction du hachage, en répartissant la charge entre plusieurs nœuds lors de l'écriture de clés consécutives.
Lignes comportant un très grand nombre de colonnes Bien que Bigtable puisse accepter des lignes jusqu'à 256 Mo, le traitement de lignes volumineuses peut avoir un impact sur les performances. Bigtable est optimisé pour les lignes plus petites. C'est pourquoi l'organisation des cellules et l'accès aux données doivent être pris en compte lors de la conception du schéma pour éviter de répartir les données sur de nombreuses cellules si ce n'est pas nécessaire. Les performances sont sous-optimales lorsqu'une ligne ou un enregistrement comporte un très grand nombre de colonnes ou de bins.
Démarrages à froid Fonctionne mieux avec les tables volumineuses fréquemment consultées. Si vous commencez à envoyer des requêtes après une période d'inactivité (démarrage à froid), vous constaterez peut-être une latence élevée. Cela se produit parce que la répartition des tablettes et leur distribution entre les nœuds ne sont peut-être pas optimales, et parce que les caches sont froids. La distribution entre les nœuds peut ne pas être entièrement optimale pendant quelques minutes lors du démarrage à froid et du rééquilibrage. Les performances ne changent pas au fil du temps, car la distribution des données n'est pas basée sur la charge. Alors que les caches doivent être préchauffés, les index sont conservés en mémoire, ce qui minimise le temps de recherche sur le disque et réduit l'importance de la mise en cache.
Plusieurs petites tables Évitez de créer de nombreuses petites tables. Il est justifié d'utiliser des tables distinctes pour différents cas d'utilisation ou schémas, mais pas pour des données similaires, car cela n'améliore pas l'équilibrage de la charge et augmente la charge de gestion. La plupart des enregistrements résident dans un espace de noms, regroupés en ensembles. Les ensembles n'ont pas de schémas spécifiques, mais des index secondaires ou des opérations d'analyse peuvent être définis par ensemble. La division des données en ensembles n'a aucune incidence sur les performances.
Ensemble de données volumineux Capable de stocker des ensembles de données à l'échelle de l'exaoctet. Les performances ne sont pas affectées par la taille totale de l'ensemble de données en raison de son architecture et de la division dynamique des tables. Techniquement, les bases de données Aerospike n'ont pas de limite de taille. Toutefois, Aerospike stocke les index et les enregistrements séparément. Les deux types de données peuvent être stockés sur différents types de périphériques de stockage pour améliorer les performances. Le stockage des index dans la RAM est essentiel pour réduire la latence, mais il peut ne pas être possible pour les ensembles de données très volumineux. Par exemple, avec 4 milliards d'objets et un facteur de réplication de 2 (RF2), la mémoire consommée en association avec l'index principal dans le cluster All Flash est de 2,5 Gio. En utilisant le même exemple dans une configuration de mémoire hybride, où l'index principal est en mémoire, 476,8 Gio de mémoire seraient utilisés.
Scaling Le traitement et le stockage sont dissociés et peuvent être mis à l'échelle indépendamment. Un seul nœud peut gérer des blocs de données de plusieurs centaines de téraoctets, voire de pétaoctets. Il est essentiel de stocker les index dans la RAM pour obtenir une faible latence. Dans ce cas, les machines doivent être mises à l'échelle verticalement avec la capacité de stockage pour tenir compte de l'index principal.

Étapes suivantes