Différences entre HBase et Bigtable

Une façon d'accéder à Bigtable consiste à utiliser une version personnalisée du client Apache HBase pour Java. En général, le client personnalisé expose la même API qu'une installation HBase standard. Cette page décrit les différences entre le client Cloud Bigtable HBase pour Java et une installation HBase standard. Bon nombre de ces différences sont liées à des tâches de gestion que Bigtable gère automatiquement.

Le client Cloud Bigtable HBase pour Java est destiné aux clients qui migrent vers Bigtable depuis HBase et souhaitent continuer à utiliser l'API HBase. Dans tous les autres cas, les développeurs Java doivent utiliser le client Cloud Bigtable pour Java, qui appelle les API Bigtable.

Familles de colonnes

Lorsque vous créez une famille de colonnes, vous ne pouvez pas configurer la taille de bloc ou la méthode de compression, que ce soit par l'interface système HBase ou via l'API HBase. Bigtable gère ces deux éléments pour vous.

De plus, si vous utilisez l'interface système HBase pour obtenir des informations sur une table, celle-ci indiquera toujours que chaque famille de colonnes n'utilise pas la compression. En réalité, Bigtable utilise des méthodes de compression propriétaires pour l'ensemble de vos données.

Les paramètres de famille de colonnes suivants sont ignorés, car Bigtable gère le stockage sous-jacent pour vous :

• BLOCKCACHE
• BLOCKSIZE
• BLOOMFILTER
• CACHE_BLOOMS_ON_WRITE
• CACHE_DATA_IN_L1
• CACHE_DATA_ON_WRITE
• CACHE_INDEX_ON_WRITE
• COMPRESS_TAGS
• COMPRESSION
• COMPRESSION_COMPACT
• DATA_BLOCK_ENCODING
• EVICT_BLOCKS_ON_CLOSE
• IN_MEMORY
• KEEP_DELETED_CELLS
• PREFETCH_BLOCKS_ON_OPEN
• REPLICATION_SCOPE

Les paramètres VERSIONS, MIN_VERSIONS et TTL sont convertis en règles de récupération de mémoire Bigtable.

Bigtable exige que les noms de famille de colonnes suivent l'expression régulière [_a-zA-Z0-9][-_.a-zA-Z0-9]*. Si vous importez des données dans Bigtable à partir de HBase, vous devrez peut-être d'abord modifier les noms de famille pour qu'ils suivent ce modèle.

Lignes et cellules

• Vous ne pouvez pas définir une LCA pour une ligne individuelle. Les vues autorisées Bigtable vous permettent d'accorder l'accès à un sous-ensemble des données d'une table, mais elles ne sont pas exposées via l'API HBase.
• Vous ne pouvez pas définir la visibilité de cellules individuelles.
• Les tags ne sont pas acceptés. Vous ne pouvez pas utiliser la classe org.apache.hadoop.hbase.Tag pour ajouter des métadonnées à des cellules individuelles. Tous les tags que vous ajoutez à une cellule sont supprimés avant l'écriture de la cellule.

Mutations et suppressions

• Les opérations Append dans Bigtable sont totalement atomiques pour les lecteurs et les rédacteurs. Les lecteurs ne seront jamais en mesure de lire une opération Append partiellement appliquée.
• Les opérations Increment sont atomiques, mais la définition d'une période sur un Increment n'est pas possible.
• Un objet RowMutations que vous transmettez à Table#mutateRow() peut contenir des opérations Put et Delete ou des opérations Append et Increment, mais pas les deux. Les objets RowMutations contenant des opérations Append ou Increment ne sont pas compatibles avec batch(), checkAndMutate() ou BufferedMutator.

• La suppression d'une version spécifique d'une colonne spécifique en fonction de son code temporel est possible. Toutefois, les types de suppressions suivants ne sont pas acceptés :

  • Supprimer uniquement la dernière version d'une colonne
  • Supprimer toutes les valeurs d'une ligne ayant un code temporel spécifique
  • Supprimer toutes les valeurs d'une famille de colonnes à un code temporel spécifique ou avant celui-ci

  Par conséquent, les méthodes suivantes de la classe org.apache.hadoop.hbase.client.Delete ne sont pas acceptées : + new Delete(byte[] row, long timestamp) + addColumn(byte[] family, byte[] qualifier) + addFamily(byte[] family, long timestamp) + addFamilyVersion(byte[] family, long timestamp)

• Dans HBase, les suppressions masquent les insertions. En revanche, Bigtable ne masque pas les insertions après les suppressions si les requêtes d'insertion sont envoyées après les requêtes de suppression. Cela signifie que dans Bigtable, une requête d'écriture envoyée à une cellule n'est pas affectée par une requête de suppression envoyée précédemment à la même cellule.

Obtentions et analyses

• Les analyses inversées vous permettent de lire une plage de lignes dans l'ordre inverse. Pour en savoir plus, consultez Analyses inversées.
• Contrairement à HBase, lorsque vous envoyez une requête de lecture, Bigtable ne filtre pas automatiquement les données arrivées à expiration qui sont marquées pour suppression lors d'un prochain cycle de récupération de mémoire. Pour éviter de lire des données arrivées à expiration, utilisez un filtre dans la requête de lecture. Pour en savoir plus, consultez la présentation de la récupération de mémoire.
• Il n'est pas possible de limiter le nombre de valeurs par ligne et par famille de colonnes. Vous ne pouvez pas appeler la méthode org.apache.hadoop.hbase.client.Scan#setMaxResultsPerColumnFamily(int limit).
• Les résultats partiels ne sont pas acceptés. Les lignes sont toujours renvoyées entières. Les appels aux méthodes org.apache.hadoop.hbase.client.Scan#setBatch(int batch) et org.apache.hadoop.hbase.client.Scan#setAllowPartialResults(boolean allowPartialResults) sont ignorés.
• Lors d'un appel Table#getScanner(Scan) synchrone, org.apache.hadoop.hbase.client.Scan#setCaching(int caching) contrôle le nombre de lignes que le client récupère à la fois. AsyncTable#getScanner() ignore setCaching(). Les appels à la méthode org.apache.hadoop.hbase.client.Scan#setMaxResultSize(long maxResultSize) sont toujours ignorés.

Coprocesseurs

Les coprocesseurs ne sont pas acceptés. Vous ne pouvez pas créer de classes mettant en œuvre l'interface org.apache.hadoop.hbase.coprocessor.

Filtres

Le tableau suivant liste les filtres compatibles dans le package org.apache.hadoop.hbase.filter. Tous les autres filtres de ce package ne sont pas compatibles et génèrent une erreur UnsupportedOperationException.

Compatible	Compatible, avec des limitations
PrefixFilter recherche les lignes dans PrefixFilter dans la plupart des cas. Toutefois, si PrefixFilter figure dans une liste FilterList et dispose de l'opérateur MUST_PASS_ONE, Bigtable ne peut pas déterminer la plage implicite, mais effectue une analyse non filtrée de la ligne de début à la ligne de fin. Dans ce cas, utilisez PrefixFilter avec BigtableExtendedScan ou une combinaison de filtres pour optimiser les performances. Nécessite une seule famille de colonnes uniquement lorsque vous utilisez un qualificatif de colonne comme décalage de colonne. Accepte une seule famille de colonnes. Seul l'opérateur EQUAL est accepté, avec le comparateur BinaryComparator ou RegexStringComparator. La construction du filtre avec new KeyOnlyFilter(true) n'est pas acceptée. Ne peut pas faire partie d'un FilterList qui utilise l'opérateur MUST_PASS_ONE. Un PageFilter doit être le filtre de premier niveau ou le dernier filtre d'un FilterList de premier niveau qui utilise l'opérateur MUST_PASS_ALL, qui est le comportement par défaut. Un PageFilter dans un FilterList qui utilise l'opérateur MUST_PASS_ONE n'est pas accepté. Seul le comparateur BinaryComparator ou le comparateur RegexStringComparator avec l'opérateur EQUAL est accepté. Si un opérateur autre que EQUAL est utilisé, une seule famille de colonnes est acceptée. Accepte uniquement les comparateurs suivants : BinaryComparator RegexStringComparator sans indicateur (les indicateurs sont ignorés) et avec l'opérateur EQUAL Dépend du filtre de condition de Bigtable, qui peut être lent. Compatible, mais déconseillé. Une seule WhileMatchFilter est acceptée par analyse.
ColumnCountGetFilter ColumnPrefixFilter FilterList FirstKeyOnlyFilter FuzzyRowFilter MultipleColumnPrefixFilter PrefixFilter ^1 RandomRowFilter TimestampsFilter	ColumnPaginationFilter ^2 ColumnRangeFilter ^3 FamilyFilter ^4 KeyOnlyFilter ^5 MultiRowRangeFilter ^6 PageFilter ^7 QualifierFilter ^8 RowFilter ^4 SingleColumnValueExcludeFilter ^3, 9, 10 SingleColumnValueFilter ^9, 10 ValueFilter ^9 WhileMatchFilter ^6, 11

Les différences suivantes affectent également les filtres Bigtable :

• Seuls les comparateurs BinaryComparator et RegexStringComparator sont acceptés. Tous les autres comparateurs ne sont pas acceptés et génèrent une erreur UnsupportedOperationException.
• Dans les filtres qui utilisent le comparateur d'expressions régulières (org.apache.hadoop.hbase.filter.RegexStringComparator), les expressions régulières utilisent la syntaxe RE2 plutôt que la syntaxe Java.
• Les filtres personnalisés ne sont pas acceptés. Vous ne pouvez pas créer de classes qui héritent de org.apache.hadoop.hbase.filter.Filter. Pour utiliser un filtre Bigtable qui n'a pas d'équivalent HBase, encapsulez-le dans un com.google.cloud.bigtable.hbase.filter.BigtableFilter.
• La taille des expressions de filtre est limitée à 20 Ko, et les filtres ne peuvent pas être imbriqués sur plus de 20 niveaux. Pour réduire la taille d'une expression de filtre, utilisez une colonne supplémentaire qui stocke la valeur de hachage des critères de filtre.

Codes temporels

Bigtable stocke les horodatages en microsecondes, tandis que HBase les stocke en millisecondes. Cette distinction a des conséquences lorsque vous utilisez la bibliothèque cliente HBase pour Bigtable et que vos données présentent des horodatages inversés.

La bibliothèque cliente effectue les conversions entre microsecondes et millisecondes, mais comme la plus grande valeur d'horodatage HBase stockable par Bigtable est Long.MAX_VALUE/1000, toute valeur supérieure à ce nombre sera convertie en Long.MAX_VALUE/1000. Par conséquent, il est possible que les grandes valeurs d'horodatage inversées ne soient pas converties correctement.

Administration

Cette section décrit comment le client Bigtable HBase pour Java implémente l'interface org.apache.hadoop.hbase.client.Admin. Étant donné que Bigtable gère automatiquement la plupart des tâches de gestion des clusters et du stockage, de nombreuses méthodes d'administration HBase ne sont pas applicables. Toute méthode Admin qui n'est pas listée dans cette section comme étant compatible ou n'ayant aucun effet n'est pas compatible et génère une exception UnsupportedOperationException.

Gestion des tables

Les méthodes Admin suivantes pour gérer les tables et les familles de colonnes sont acceptées :

• addColumnFamily(TableName tableName, ColumnFamilyDescriptor columnFamily) et addColumnFamilyAsync(TableName tableName, ColumnFamilyDescriptor columnFamily) (HBase 1.x : addColumn(TableName tableName, HColumnDescriptor column))
• createTable(TableDescriptor desc), createTable(TableDescriptor desc, byte[][] splitKeys), createTable(TableDescriptor desc, byte[] startKey, byte[] endKey, int numRegions), createTableAsync(TableDescriptor desc) et createTableAsync(TableDescriptor desc, byte[][] splitKeys)
• deleteColumnFamily(TableName tableName, byte[] columnName) et deleteColumnFamilyAsync(TableName tableName, byte[] columnName) (HBase 1.x : deleteColumn(TableName tableName, byte[] columnName))
• deleteTable(TableName tableName), deleteTableAsync(TableName tableName), deleteTables(Pattern pattern) et deleteTables(String regex)
• disableTable(TableName tableName), disableTableAsync(TableName tableName), disableTables(Pattern pattern) et disableTables(String regex)
• enableTable(TableName tableName), enableTableAsync(TableName tableName), enableTables(Pattern pattern) et enableTables(String regex)
• getAlterStatus(TableName tableName) et getAlterStatus(byte[] tableName)
• getDescriptor(TableName tableName), getTableDescriptor(TableName tableName), getTableDescriptors(List<String> names) et getTableDescriptorsByTableName(List<TableName> tableNames)
• isTableAvailable(TableName tableName) et isTableAvailable(TableName tableName, byte[][] splitKeys)
• isTableDisabled(TableName tableName) et isTableEnabled(TableName tableName)
• listTableDescriptors(), listTableDescriptors(List<TableName> tableNames), listTableDescriptors(Pattern pattern) et listTableDescriptors(Pattern pattern, boolean includeSysTables) (HBase 1.x : listTables(), listTables(Pattern pattern), listTables(Pattern pattern, boolean includeSysTables), listTables(String regex) et listTables(String regex, boolean includeSysTables))
• listTableNames(), listTableNames(Pattern pattern), listTableNames(Pattern pattern, boolean includeSysTables), listTableNames(String regex) et listTableNames(String regex, boolean includeSysTables)
• modifyColumnFamily(TableName tableName, ColumnFamilyDescriptor columnFamily) et modifyColumnFamilyAsync(TableName tableName, ColumnFamilyDescriptor columnFamily) (HBase 1.x : modifyColumn(TableName tableName, HColumnDescriptor column))
• modifyTable(TableDescriptor td), modifyTable(TableName tableName, TableDescriptor td), modifyTableAsync(TableDescriptor td) et modifyTableAsync(TableName tableName, TableDescriptor td)
• tableExists(TableName tableName)
• truncateTable(TableName tableName, boolean preserveSplits) et truncateTableAsync(TableName tableName, boolean preserveSplits).

Les méthodes de gestion de table compatibles suivantes se comportent différemment sur Bigtable ou ignorent certains paramètres :

• Les tables Bigtable ne peuvent pas être désactivées. disableTable(), disableTableAsync(), disableTables(), enableTable(), enableTableAsync() et enableTables() ne modifient l'état de la table que dans la mémoire du client (que isTableDisabled() et isTableEnabled() lisent).
• modifyTable() et modifyTableAsync() n'appliquent que les modifications apportées aux familles de colonnes. Les attributs au niveau de la table sont ignorés.
• truncateTable() et truncateTableAsync() suppriment toutes les données de la table. Le paramètre preserveSplits est ignoré.
• Les surcharges listTableDescriptors(), listTables() et listTableNames() qui acceptent un paramètre includeSysTables ignorent includeSysTables, car Bigtable ne dispose pas de tables système.
• isTableAvailable(TableName tableName, byte[][] splitKeys) vérifie uniquement si la table existe et ignore le paramètre splitKeys.
• getAlterStatus() renvoie toujours (0, 0), car les modifications de schéma dans Bigtable sont synchrones.

Les tâches telles que le compactage et la division des tables sont gérées automatiquement. Par conséquent, les méthodes suivantes n'ont aucun effet :

• compact(TableName tableName)
• compact(TableName tableName, byte[] columnFamily)
• majorCompact(TableName tableName)
• majorCompact(TableName tableName, byte[] columnFamily)
• split(TableName tableName)
• split(TableName tableName, byte[] splitPoint)

Instantanés

Les méthodes d'instantané HBase créent et gèrent des sauvegardes Bigtable. Étant donné que les sauvegardes sont stockées dans un cluster spécifique, si votre instance comporte plusieurs clusters, vous devez définir la propriété de configuration google.bigtable.snapshot.cluster.id sur le cluster à utiliser. Les sauvegardes que vous créez avec snapshot() expirent après le nombre de secondes défini dans la propriété de configuration google.bigtable.snapshot.default.ttl.secs (24 heures par défaut). cloneSnapshot() restaure une sauvegarde dans une nouvelle table.

Les méthodes d'instantané suivantes sont compatibles avec Admin :

• cloneSnapshot(byte[] snapshotName, TableName tableName)
• cloneSnapshot(String snapshotName, TableName tableName)
• deleteSnapshot(byte[] snapshotName)
• deleteSnapshot(String snapshotName)
• snapshot(byte[] snapshotName, TableName tableName)
• snapshot(String snapshotName, TableName tableName)

De plus, AsyncAdmin est compatible avec listSnapshots(), listSnapshots(Pattern pattern) et snapshot(SnapshotDescription snapshot). Toutes les autres méthodes d'instantané, y compris restoreSnapshot(), deleteSnapshots(), deleteTableSnapshots(), listTableSnapshots() et cloneSnapshot(String snapshotName, TableName tableName, boolean restoreAcl), ne sont pas compatibles et génèrent une erreur UnsupportedOperationException.

Gestion de la région

Bigtable utilise des tablets, qui sont similaires aux régions. Les méthodes suivantes pour récupérer des informations sur la région sont compatibles, avec des différences par rapport à HBase standard :

• getRegions(TableName tableName) et getTableRegions(TableName tableName), ainsi que les méthodes de l'interface org.apache.hadoop.hbase.client.RegionLocator, renvoient des limites approximatives basées sur un échantillon de clés de ligne de la table. Les noms de serveurs dans les régions renvoyées ne sont pas de vrais serveurs.
• getRegionMetrics(ServerName serverName, TableName tableName) ignore le paramètre serverName et renvoie des métriques de taille de région approximatives basées sur un échantillon de clés de ligne de la table.

Étant donné que Bigtable gère automatiquement vos tablets, les méthodes suivantes n'ont aucun effet :

• assign(byte[] regionName)
• compactRegion(byte[] regionName)
• compactRegion(byte[] regionName, byte[] columnFamily)
• flushRegion(byte[] regionName)
• majorCompactRegion(byte[] regionName)
• majorCompactRegion(byte[] regionName, byte[] columnFamily)
• splitRegion(byte[] regionName)
• splitRegion(byte[] regionName, byte[] splitPoint)

Dans HBase 1.x, compactRegionServer(ServerName sn, boolean major), mergeRegions(byte[] encodedNameOfRegionA, byte[] encodedNameOfRegionB, boolean forcible), move(byte[] encodedRegionName, byte[] destServerName) et unassign(byte[] regionName, boolean force) n'ont également aucun effet. Leurs équivalents HBase 2.x ne sont pas compatibles et génèrent une exception UnsupportedOperationException.

État et connexion du cluster

Bigtable gère automatiquement les tâches de maintenance des clusters. Par conséquent, les méthodes de maintenance dans Admin génèrent une exception UnsupportedOperationException. Seules les méthodes de connexion et d'état suivantes sont acceptées :

• close() n'a aucun effet.
• getClusterMetrics(), getClusterMetrics(EnumSet<Option> options) et getClusterStatus() renvoient des valeurs d'espace réservé avec des listes de serveurs vides, et getClusterMetrics(EnumSet<Option> options) ignore le paramètre options.
• getConfiguration() renvoie l'objet client Configuration.
• getConnection() renvoie l'objet client Connection.

Espaces de noms

Bigtable n'utilise pas d'espaces de noms. Vous pouvez utiliser les préfixes de clé de ligne pour simuler des espaces de noms.

Par défaut, toutes les méthodes d'espace de noms génèrent une erreur UnsupportedOperationException. Toutefois, si vous définissez la propriété de configuration google.bigtable.namespace.warnings sur true, les méthodes suivantes enregistrent un avertissement et n'ont aucun effet (renvoyant null ou un résultat vide) au lieu de générer une exception :

• createNamespace(NamespaceDescriptor descriptor)
• deleteNamespace(String name)
• deleteNamespaceAsync(String name)
• getNamespaceDescriptor(String name)
• listNamespaceDescriptors()
• listTableDescriptorsByNamespace(byte[] name)
• listTableDescriptorsByNamespace(String name)
• listTableNamesByNamespace(String name)
• modifyNamespace(NamespaceDescriptor descriptor)

Même lorsque google.bigtable.namespace.warnings est défini sur true, listNamespaces() génère une erreur UnsupportedOperationException.

Autres fonctionnalités d'administration

Bigtable n'est pas compatible avec les méthodes Admin des catégories suivantes, et leur appel génère une exception UnsupportedOperationException :

• Groupes de localité : Bigtable ne vous permet pas de spécifier des groupes de localité pour les familles de colonnes.
• Coprocesseurs et procédures distribuées : Bigtable n'est pas compatible avec les coprocesseurs ni avec les procédures distribuées.
• Quotas : pour en savoir plus sur les quotas Bigtable, consultez Quotas et limites.
• Réplication : Bigtable réplique automatiquement les données entre les clusters d'une instance. Pour en savoir plus, consultez Présentation de la réplication. Pour répliquer de HBase vers Bigtable, consultez Répliquer de HBase vers Bigtable.
• Contrôle des accès : Bigtable utilise IAM pour le contrôle des accès.
• Groupes RegionServer : Bigtable gère automatiquement les serveurs et n'expose pas les groupes RegionServer.