Leituras

Esta página descreve os tipos de pedidos de leitura que pode enviar para o Bigtable, aborda as implicações no desempenho e apresenta algumas recomendações para tipos específicos de consultas. Antes de ler esta página, deve conhecer a vista geral do Bigtable.

Vista geral

Os pedidos de leitura para o Bigtable transmitem em fluxo de volta os conteúdos das linhas pedidas por ordem das chaves, o que significa que são devolvidas pela ordem em que são armazenadas. Pode ler todas as escritas que tenham devolvido uma resposta.

As consultas suportadas pela sua tabela devem ajudar a determinar o tipo de leitura mais adequado para o seu exemplo de utilização. Os pedidos de leitura do Bigtable dividem-se em duas categorias gerais:

  • Ler uma única linha
  • Análises ou leitura de várias linhas

As leituras são atómicas ao nível da linha. Isto significa que, quando envia um pedido de leitura de uma linha, o Bigtable devolve a linha inteira ou, caso o pedido falhe, nenhuma parte da linha. Nunca é devolvida uma linha parcial, a menos que a peça especificamente.

Recomendamos vivamente que use as nossas bibliotecas de cliente do Cloud Bigtable para ler dados de uma tabela em vez de chamar a API diretamente. Estão disponíveis exemplos de código que mostram como enviar pedidos de leitura em vários idiomas. Todos os pedidos de leitura fazem a chamada API ReadRows.

Ler dados com a computação sem servidor do Data Boost

O Bigtable Data Boost permite-lhe executar tarefas de leitura em lote e consultas sem afetar o tráfego diário da aplicação. O Data Boost é um serviço de computação sem servidor que pode usar para ler os seus dados do Bigtable enquanto a sua aplicação principal usa os nós do cluster para computação.

O Reforço de dados é ideal para verificações e não é recomendado para leituras de linhas únicas. Não pode usar o aumento de dados para análises inversas. Para mais informações e critérios de elegibilidade, consulte a vista geral do Data Boost.

Leituras de linha única

Pode pedir uma única linha com base na chave da linha. As leituras de linha única, também conhecidas como leituras de pontos, não são compatíveis com a Otimização de dados. Estão disponíveis exemplos de código para as seguintes variações:

Análises

As análises são a forma mais comum de ler dados do Bigtable. Pode ler um intervalo de linhas contíguas ou vários intervalos de linhas do Bigtable, especificando um prefixo de chave de linha ou especificando chaves de linha de início e de fim. Estão disponíveis exemplos de código para as seguintes variações:

Inverter digitalizações

As análises inversas permitem-lhe ler um intervalo de linhas para trás, especificando um prefixo da chave de linha ou um intervalo de linhas. O prefixo da chave da linha é usado como o ponto de início da leitura inversa. Se especificar um intervalo de linhas, a chave da linha final é usada como o ponto de início da análise.

A leitura na ordem inversa pode ser útil para os seguintes cenários:

As análises inversas são menos eficientes do que as análises diretas. Em geral, conceba as chaves das linhas de modo que a maioria das análises seja para a frente. Use análises inversas para análises curtas, como 50 linhas ou menos, para manter um tempo de resposta de baixa latência.

Para fazer a leitura inversa, defina o valor do campo ReadRowsRequest como reversed verdadeiro. A predefinição é False.

As análises inversas estão disponíveis quando usa as seguintes bibliotecas de cliente:

  • Biblioteca cliente do Bigtable para C++ versão 2.18.0 ou posterior
  • Biblioteca cliente do Bigtable para Go versão 1.21.0 ou posterior
  • Biblioteca cliente do Bigtable para Java versão 2.24.1 ou posterior
  • Cliente HBase do Bigtable para Java versão 2.10.0 ou posterior

Para ver exemplos de código que demonstram como usar as leituras inversas, consulte o artigo Leia ao contrário.

Exemplos de utilização

Os exemplos seguintes mostram como as análises inversas podem ser usadas para encontrar a última vez que um cliente alterou a respetiva palavra-passe e as flutuações de preços de um produto num determinado dia.

Reposições de palavras-passe

Considere uma suposição de que as chaves de linhas contêm cada uma um ID de cliente e uma data no formato 123ABC#2022-05-02, e uma das colunas é password_reset, que armazena a hora em que a palavra-passe foi reposta. O Bigtable armazena automaticamente os dados lexicograficamente, como no exemplo seguinte. Tenha em atenção que a coluna não existe para linhas (dias) em que a palavra-passe não foi reposta.

`123ABC#2022-02-12,password_reset:03`
`123ABC#2022-04-02,password_reset:11`
`123ABC#2022-04-14`
`123ABC#2022-05-02`
`223ABC#2022-05-22`

Se quiser encontrar a última vez que o cliente 123ABC repôs a respetiva palavra-passe, pode procurar inversamente um intervalo de 123ABC# a 123ABC#<DATE>, usando a data de hoje ou uma data no futuro, para todas as linhas que contenham a coluna password_reset com um limite de linhas de 1.

Alterações de preços

Neste exemplo, as chaves de linhas contêm valores para o produto, o modelo e a data/hora, e uma das colunas contém o preço do produto e do modelo num determinado momento.

`productA#model2#1675604471,price:82.63`
`productA#model2#1676219411,price:82.97`
`productA#model2#1677681011,price:83.15`
`productA#model2#1680786011,price:83.99`
`productA#model2#1682452238,price:83.12`

Se quiser encontrar flutuações de preços em torno do preço de 14 de fevereiro de 2023, mesmo que não exista uma chave de linha para essa data específica na tabela, pode fazer uma análise para a frente a partir da chave de linha productA#model2#1676376000 para um número N de linhas e, em seguida, fazer uma análise inversa para o mesmo número de linhas a partir da mesma linha inicial. As duas verificações mostram-lhe os preços antes e depois da hora indicada.

Leituras filtradas

Se apenas precisar de linhas que contenham valores específicos ou linhas parciais, pode usar um filtro com o seu pedido de leitura. Os filtros permitem-lhe ser altamente seletivo nos dados que quer.

Os filtros também permitem garantir que as leituras correspondem às políticas de recolha de lixo que a sua tabela está a usar. Isto é particularmente útil se escrever frequentemente novas células com data/hora em colunas existentes. Uma vez que a recolha de lixo pode demorar até uma semana a remover dados expirados, a utilização de um filtro de intervalo de data/hora para ler dados pode garantir que não lê mais dados do que precisa.

A vista geral dos filtros oferece explicações detalhadas dos tipos de filtros que pode usar. Usar filtros mostra exemplos em vários idiomas.

Ler dados de uma vista autorizada

Para ler dados de uma vista autorizada, tem de usar uma das seguintes opções:

  • CLI gcloud
  • Cliente do Bigtable para Java

As outras bibliotecas cliente do Bigtable ainda não suportam o acesso de visualização.

Qualquer método que chame o método ReadRows ou SampleRowKeys da API Google Cloud Bigtable Data é suportado. Fornece o ID da vista autorizada além do ID da tabela quando cria o cliente.

Ler dados de uma vista materializada contínua

Pode ler dados de uma vista materializada contínua através de SQL ou da chamada da ReadRows API Data. As vistas materializadas contínuas são só de leitura. Os dados numa vista materializada são tipados com base na consulta que os define.

SQL

Para ler dados de uma vista materializada contínua através de SQL, pode usar o editor de consultas do Bigtable Studio ou uma das bibliotecas de cliente que suportam consultas SQL.

O SQL expõe automaticamente os resultados das consultas como colunas com tipo, pelo que não é necessário processar a codificação na sua consulta.

Quando cria uma vista materializada contínua, o Bigtable cria automaticamente um esquema de chave de linha para a tabela que define as chaves de linha estruturadas para a vista. Para mais informações sobre a consulta de chaves de linhas estruturadas com SQL, consulte o artigo Consultas de chaves de linhas estruturadas.

API Google Data

Se planeia ler a partir de uma vista materializada contínua com uma chamada ReadRows de uma das bibliotecas cliente do Bigtable, deve rever a consulta SQL usada para definir a vista. Tenha em atenção se a vista tem uma coluna _key definida, o que é recomendado para vistas destinadas a ser lidas com ReadRows, e se tem uma coluna _timestamp.

Também tem de saber o tipo de cada coluna e descodificar os dados das colunas no código da sua aplicação.

Os valores agregados numa vista materializada contínua são armazenados através da codificação descrita na tabela seguinte, com base no tipo de saída da coluna da definição da vista.

Tipo Codificação
BOOL Valor de 1 byte, 1 = verdadeiro, 0 = falso
BYTES Sem codificação
INT64 (ou INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT) 64 bits big-endian
FLOAT64 IEEE 754 de 64 bits, excluindo NaN e +/-inf
STRING UTF-8
HORA/INDICAÇÃO DE TEMPO Número inteiro de 64 bits que representa o número de microssegundos desde a época Unix (consistente com o GoogleSQL)
Para mais informações, consulte a secção Codificação na referência da API Data.

Além de saber o tipo de cada coluna na vista, tem de saber a família de colunas e o qualificador de colunas. A família de colunas predefinida chama-se default e o qualificador de coluna é o alias especificado na consulta de definição. Por exemplo, considere uma vista materializada contínua definida com esta consulta:

SELECT
  _key,
  SUM(clicks) AS sum_clicks
FROM
  mytable
GROUP BY
  sum_clicks

Quando consulta a vista com ReadRows, fornece a família de colunasdefault e o qualificador de coluna sum_clicks.

Leituras e desempenho

As leituras que usam filtros são mais lentas do que as leituras sem filtros e aumentam a utilização da CPU. Por outro lado, podem reduzir significativamente a quantidade de largura de banda da rede que usa, limitando a quantidade de dados devolvidos. Em geral, os filtros devem ser usados para controlar a eficiência da taxa de transferência e não a latência.

Se quiser otimizar o desempenho de leitura, considere as seguintes estratégias:

  1. Restrinja o conjunto de linhas o máximo possível. Limitar o número de linhas que os seus nós têm de analisar é o primeiro passo para melhorar o tempo até ao primeiro byte e a latência geral das consultas. Se não restringir o conjunto de linhas, o Bigtable terá quase certamente de analisar toda a tabela. É por isso que recomendamos que conceba o seu esquema de forma a permitir que as suas consultas mais comuns funcionem desta forma.

  2. Para uma otimização adicional do desempenho depois de restringir o conjunto de linhas, experimente adicionar um filtro básico. Restringir o conjunto de colunas ou o número de versões devolvidas geralmente não aumenta a latência e, por vezes, pode ajudar o Bigtable a procurar de forma mais eficiente dados irrelevantes em cada linha.

  3. Se quiser otimizar ainda mais o desempenho de leitura após as duas primeiras estratégias, considere usar um filtro mais complicado. Pode tentar isto por alguns motivos:

    • Continua a receber muitos dados que não quer.
    • Quer simplificar o código da aplicação ao enviar a consulta para o Bigtable.

    No entanto, tenha em atenção que os filtros que requerem condições, intercalações ou correspondência de expressões regulares em valores grandes tendem a fazer mais mal do que bem se permitirem a passagem da maioria dos dados analisados. Este dano assume a forma de um aumento da utilização da CPU no seu cluster sem grandes poupanças por parte do cliente.

Além destas estratégias, evite ler um grande número de chaves de linhas ou intervalos de linhas não contíguos num único pedido de leitura. Quando pede centenas de chaves de linhas ou intervalos de linhas num único pedido, o Bigtable analisa a tabela e lê as linhas pedidas sequencialmente. Esta falta de paralelismo afeta a latência geral e quaisquer leituras que atinjam um nó ativo podem aumentar a latência final. Quanto mais intervalos de linhas forem pedidos, mais tempo demora a leitura a ser concluída. Se esta latência for inaceitável, deve enviar vários pedidos simultâneos que obtenham menos intervalos de linhas.

ReadRows

Em geral, a leitura de mais intervalos de linhas num único pedido otimiza o débito, mas não a latência. A leitura de menos intervalos de linhas em vários pedidos simultâneos otimiza a latência, mas não a taxa de transferência. Encontrar o equilíbrio certo entre a latência e a taxa de transferência vai depender dos requisitos da sua aplicação e pode ser alcançado ajustando a contagem de pedidos de leitura simultâneos e o número de intervalos de linhas num pedido.

Linhas grandes

O Bigtable aplica os seguintes limites que se aplicam a linhas grandes:

  • 256 MB é o tamanho máximo de uma linha. Se precisar de ler uma linha que tenha crescido mais do que o limite, pode paginar o seu pedido e usar um filtro cells per row limit e um filtro cells per row offset. Tenha em atenção que, se chegar uma gravação para a linha entre os pedidos de leitura paginados, a leitura pode não ser atómica.

  • 512 KB é o tamanho máximo de uma chamada da API ReadRows. Se exceder o limite, o Bigtable devolve um erro INVALID_ARGUMENT.

O que se segue?