Lindorm:Séparer le stockage des données chaudes et froides en fonction des horodatages

Fonctionnement

Lorsque vous écrivez des données dans une table, elles sont stockées dans le stockage chaud (type Standard ou Performance). Lindorm exécute périodiquement une opération de compaction en arrière-plan. Pendant cette opération, Lindorm compare l'horodatage de chaque ligne à la limite configurée (COLD_BOUNDARY pour HBase Shell et l'API Java, ou CHS pour Lindorm SQL). Les lignes dont l'horodatage dépasse cette limite sont déplacées vers le stockage froid.

L'archivage est asynchrone : les données ne sont pas déplacées instantanément dès qu'elles dépassent la limite. Pour forcer un transfert immédiat, exécutez manuellement la commande major_compact.

Par défaut, l'horodatage d'une ligne correspond à l'heure système au moment de l'écriture des données. Si vous utilisez l'API ApsaraDB for HBase pour Java, vous pouvez spécifier un horodatage personnalisé. Consultez la section Considérations opérationnelles pour comprendre l'impact des horodatages personnalisés sur le routage du stockage.

Prérequis

Avant de commencer, assurez-vous d'avoir :

• Activé le stockage froid pour l'instance Lindorm. Pour plus d'informations, consultez la page Vue d'ensemble.

• Une version de LindormTable 2.1.8 ou ultérieure. Pour plus d'informations, consultez les Notes de version de LindormTable et la procédure de Mise à jour de la version mineure du moteur d'une instance Lindorm.

• Établi une connexion à LindormTable à l'aide de l'un des clients suivants :

  • Apache HBase Shell. Pour plus d'informations, consultez la page Utiliser Lindorm Shell pour se connecter à LindormTable.

  • API ApsaraDB for HBase pour Java. Pour plus d'informations, consultez la page Développer des applications avec l'API ApsaraDB for HBase pour Java.

  • lindorm-cli. Pour plus d'informations, consultez la page Utiliser lindorm-cli pour se connecter à LindormTable et l'utiliser.

• Défini l'attribut STORAGE_POLICY de la table ou de la famille de colonnes cible sur une valeur différente de COLD. Pour plus d'informations, consultez la page Configurer le stockage froid.

Définir la limite entre les données chaudes et froides

Choisissez la méthode correspondant à votre client.

HBase(main):002:0> create 'chsTable', {NAME=>'f', COLD_BOUNDARY=>'86400'}

HBase(main):005:0> alter 'chsTable', {NAME=>'f', COLD_BOUNDARY=>'42300'}

HBase(main):004:0> alter 'chsTable', {NAME=>'f', COLD_BOUNDARY=>""}

Admin admin = connection.getAdmin();
TableName tableName = TableName.valueOf("chsTable");
HTableDescriptor descriptor = new HTableDescriptor(tableName);
HColumnDescriptor cf = new HColumnDescriptor("f");
cf.setValue(AliHBaseConstants.COLD_BOUNDARY, "86400");
descriptor.addFamily(cf);
admin.createTable(descriptor);

HTableDescriptor descriptor = admin
    .getTableDescriptor(tableName);
HColumnDescriptor cf = descriptor.getFamily("f".getBytes());
cf.setValue(AliHBaseConstants.COLD_BOUNDARY, "86400");
admin.modifyTable(tableName, descriptor);

HTableDescriptor descriptor = admin
    .getTableDescriptor(tableName);
HColumnDescriptor cf = descriptor.getFamily("f".getBytes());
cf.setValue(AliHBaseConstants.COLD_BOUNDARY, null);
admin.modifyTable(tableName, descriptor);

CREATE TABLE dt (
  p1 integer, p2 integer, c1 varchar, c2 bigint,
  constraint pk primary key(p1 desc))
WITH (COMPRESSION = 'ZSTD', CHS = '86400', CHS_L2 = 'storagetype=COLD');

-- Enable hot and cold data separation on an existing table.
-- The table was created without CHS:
-- CREATE TABLE dt (p1 integer, p2 integer, c1 varchar, c2 bigint,
--   constraint pk primary key(p1 desc)) WITH (COMPRESSION = 'ZSTD');

ALTER TABLE dt SET 'CHS' ='86400', 'CHS_L2' = 'storagetype=COLD';

ALTER TABLE dt SET 'CHS'='1000';

ALTER TABLE dt SET 'CHS'='', 'CHS_L2' = '';

Écrire des données

Écrivez des données dans une table avec séparation chaud/froid de la même manière que dans une table large standard. Les données sont toujours écrites d'abord dans le stockage chaud, puis déplacées vers le stockage froid lors de la prochaine compaction une fois la limite configurée dépassée.

Si vous utilisez l'API ApsaraDB for HBase pour Java, vous pouvez définir un horodatage personnalisé pour chaque ligne. C'est cet horodatage qui détermine le niveau de stockage dans lequel la ligne sera placée, et non l'heure réelle de l'opération d'écriture. Consultez la section Comportement des horodatages personnalisés pour plus de détails.

Interroger des données

LindormTable stocke les données chaudes et froides dans la même table ; toutes les données sont donc accessibles via une seule requête. Par défaut, une requête sans plage de temps peut lire le stockage froid, et le débit est limité par les spécifications du stockage froid.

Pour limiter une requête au stockage chaud, utilisez l'une des options suivantes :

• Le paramètre HOT_ONLY (Apache HBase Shell et API Java)

• L'indicateur _l_hot_only_ (Lindorm SQL)

• Le paramètre TimeRange , défini sur une plage incluse dans la fenêtre des données chaudes

-- Query all data (may include cold storage)
HBase(main):013:0> get 'chsTable', 'row1'

-- Query only hot storage
HBase(main):015:0> get 'chsTable', 'row1', {HOT_ONLY=>true}

-- Query by time range (UNIX timestamp in milliseconds)
HBase(main):016:0> get 'chsTable', 'row1', {TIMERANGE => [0, 1568203111265]}

// Query all data (may include cold storage)
Get get = new Get("row1".getBytes());
System.out.println("result: " + table.get(get));

// Query only hot storage
get = new Get("row1".getBytes());
get.setAttribute(AliHBaseConstants.HOT_ONLY, Bytes.toBytes(true));

// Query by time range
get = new Get("row1".getBytes());
get.setTimeRange(0, 1568203111265);

SELECT /*+ _l_hot_only_ */ * FROM dt WHERE pk IN (1, 2, 3);

-- Scan all data (may include cold storage)
Lindorm(main):017:0> scan 'chsTable', {STARTROW =>'row1', STOPROW=>'row9'}

-- Scan only hot storage
Lindorm(main):018:0> scan 'chsTable', {STARTROW =>'row1', STOPROW=>'row9', HOT_ONLY=>true}

-- Scan by time range
Lindorm(main):019:0> scan 'chsTable', {STARTROW =>'row1', STOPROW=>'row9', TIMERANGE => [0, 1568203111265]}

TableName tableName = TableName.valueOf("chsTable");
Table table = connection.getTable(tableName);

// Scan all data (may include cold storage)
Scan scan = new Scan();
ResultScanner scanner = table.getScanner(scan);
for (Result result : scanner) {
    System.out.println("scan result:" + result);
}

// Scan only hot storage
scan = new Scan();
scan.setAttribute(AliLindormConstants.HOT_ONLY, Bytes.toBytes(true));

// Scan by time range
scan = new Scan();
scan.setTimeRange(0, 1568203111265);

Prioriser les données chaudes dans les requêtes SCAN

Dans les requêtes SCAN qui récupèrent des données ordonnées, telles que toutes les commandes ou messages d'un utilisateur, LindormTable lit normalement à la fois le stockage chaud et le stockage froid, ce qui augmente le temps de réponse. Activez la priorisation des données chaudes avec COLD_HOT_MERGE pour analyser d'abord le stockage chaud. Le stockage froid n'est lu que si le nombre de lignes dans le stockage chaud est inférieur au nombre minimal de lignes de données à interroger.

Apache HBase Shell

Lindorm(main):002:0> scan 'chsTable', {COLD_HOT_MERGE=>true}

API ApsaraDB for HBase pour Java

scan = new Scan();
scan.setAttribute(AliHBaseConstants.COLD_HOT_MERGE, Bytes.toBytes(true));
scanner = table.getScanner(scan);

Considérations opérationnelles

FAQ

Après avoir mis à jour une ligne froide, reste-t-elle une donnée froide ?

Non. La mise à jour d'une ligne actualise son horodatage, de sorte que LindormTable la traite comme une donnée chaude.

J'ai défini HOT_ONLY, mais ma requête renvoie toujours des données froides. Pourquoi ?

Les données sont archivées dans le stockage froid de manière asynchrone lors de la compaction. Certaines lignes assez anciennes pour être considérées comme froides n'ont peut-être pas encore été archivées ; elles se trouvent donc toujours physiquement dans le stockage chaud et sont renvoyées par les requêtes.

Pour exclure ces données, spécifiez une plage de temps explicite en plus de HOT_ONLY. Utilisez les indicateurs _l_ts_min_ et _l_ts_max_ dans Lindorm SQL pour définir précisément la fenêtre :

-- _l_ts_min_: difference between current time and the hot/cold boundary
-- _l_ts_max_: current system time
-- Both values must use the same unit.
SELECT /*+ _l_hot_only_(true), _l_ts_min_(1000), _l_ts_max_(2001) */ * FROM test WHERE p1>1;

Ma requête expire même si j'ai spécifié HOT_ONLY et TimeRange. Pourquoi ?

Cela se produit généralement après avoir migré des données dans une table ou activé la séparation des données chaudes et froides pour la première fois. Une grande quantité de données froides se trouve toujours physiquement dans le stockage chaud car la compaction n'a pas encore été exécutée. Exécutez major compaction sur la table pour forcer le déplacement des données. Pour connaître la syntaxe, consultez la page ALTER TABLE.