Lindorm:Armazenar dados quentes e frios separadamente com base em timestamps

Como funciona

Ao gravar dados em uma tabela, eles são direcionados inicialmente para o armazenamento quente (tipo Standard ou Performance). Periodicamente, o Lindorm executa uma operação de compaction em segundo plano. Durante essa compactação, o sistema compara o timestamp de cada linha com o limite configurado (COLD_BOUNDARY para HBase Shell e API Java, ou CHS para Lindorm SQL). Linhas cujos timestamps ultrapassam esse limite são movidas para o armazenamento frio.

O arquivamento é assíncrono, ou seja, a migração dos dados não ocorre no exato momento em que atingem a idade definida. Para forçar uma transferência imediata, execute major_compact manualmente.

Por padrão, o timestamp de uma linha corresponde à hora do sistema no momento da gravação. Caso utilize a API ApsaraDB for HBase for Java, especifique um timestamp personalizado. Consulte Considerações operacionais para entender como timestamps personalizados afetam o roteamento de armazenamento.

Pré-requisitos

Antes de começar, verifique se você atende aos seguintes requisitos:

• O recurso de armazenamento frio está ativado. Para mais informações sobre como ativar o recurso, consulte Enable Capacity storage.

• Versão 2.1.8 ou superior do LindormTable instalada. Para mais detalhes, consulte Release notes of LindormTable e Upgrade the minor engine version of a Lindorm instance.

• Conexão estabelecida com o LindormTable por meio de uma das opções abaixo:

  • Apache HBase Shell. Para mais informações, consulte Use Lindorm Shell to connect to LindormTable.

  • API ApsaraDB for HBase for Java. Para mais informações, consulte Use ApsaraDB for HBase API for Java to develop applications.

  • lindorm-cli. Para mais informações, consulte Use lindorm-cli to connect to and use LindormTable.

• Atributo STORAGE_POLICY da tabela ou família de colunas de destino definido com um valor diferente de COLD. Para mais informações, consulte Configure cold storage.

Definir o limite entre dados quentes e frios

Escolha o método correspondente ao seu cliente.

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' = '';

Gravar dados

Grave dados em uma tabela com separação quente/frio da mesma forma que em uma tabela ampla padrão. Os dados são sempre gravados primeiro no armazenamento quente e movidos para o armazenamento frio na próxima compactação, assim que ultrapassarem o limite configurado.

Se utilizar a API ApsaraDB for HBase for Java, defina um timestamp personalizado em cada linha. Esse timestamp determina em qual camada de armazenamento a linha será alocada, e não o horário da operação de gravação em si. Consulte Comportamento de timestamp personalizado para obter detalhes.

Consultar dados

O LindormTable armazena dados quentes e frios na mesma tabela, permitindo acesso a todos os dados por meio de uma única consulta. Por padrão, uma consulta sem intervalo de tempo pode ler o armazenamento frio, e o throughput é limitado pela especificação desse armazenamento.

Para restringir uma consulta apenas ao armazenamento quente, utilize uma das opções a seguir:

• Parâmetro HOT_ONLY (Apache HBase Shell e API Java)

• Hint _l_hot_only_ (Lindorm SQL)

• Parâmetro TimeRange, configurado com um intervalo dentro da janela de dados quentes

-- 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);

Priorizar dados quentes em consultas SCAN

Em consultas SCAN que recuperam dados ordenados — como todos os pedidos ou mensagens de um usuário — o LindormTable normalmente lê tanto o armazenamento quente quanto o frio, o que aumenta o tempo de resposta. Ative a priorização de dados quentes com COLD_HOT_MERGE para varrer o armazenamento quente primeiro. O armazenamento frio só é lido quando o número de linhas no armazenamento quente for inferior à quantidade mínima de linhas de dados a serem consultadas.

Apache HBase Shell

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

API ApsaraDB for HBase for Java

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

Considerações operacionais

Perguntas frequentes

Após atualizar uma linha fria, ela ainda é considerada dado frio?

Não. A atualização de uma linha renova seu timestamp, fazendo com que o LindormTable a trate como dado quente.

Defini HOT_ONLY, mas minha consulta ainda retorna dados frios. Por quê?

Os dados são arquivados no armazenamento frio de forma assíncrona durante a compactação. Algumas linhas antigas o suficiente para serem consideradas frias podem não ter sido arquivadas ainda, permanecendo fisicamente no armazenamento quente e sendo retornadas pelas consultas.

Para excluir esses dados, especifique um intervalo de tempo explícito além de HOT_ONLY. Utilize os hints _l_ts_min_ e _l_ts_max_ no Lindorm SQL para definir a janela com precisão:

-- _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;

Minha consulta atinge o tempo limite mesmo com HOT_ONLY e TimeRange especificados. Por quê?

Isso geralmente ocorre após migrar dados para uma tabela ou ativar a separação de dados quentes e frios pela primeira vez. Uma grande quantidade de dados frios ainda reside fisicamente no armazenamento quente porque a compactação ainda não foi executada. Execute major compaction na tabela para forçar a movimentação dos dados. Para consultar a sintaxe, veja ALTER TABLE.