Esta página foi traduzida pela API Cloud Translation.

Leituras

Esta página descreve os tipos de solicitações de leitura que podem ser enviadas ao Bigtable, discute as implicações de desempenho e apresenta algumas recomendações de tipos específicos de consultas. Antes de ler esta página, familiarize-se com a visão geral doBigtable.

Visão geral

As solicitações de leitura para o Bigtable transmitem o conteúdo das linhas solicitadas em ordem de chave, o que significa que elas são retornadas na ordem em que estão armazenadas. Você pode ler todas as gravações que retornaram uma resposta.

As consultas compatíveis com sua tabela devem ajudar a determinar o tipo de leitura mais adequado para seu caso de uso. As solicitações de leitura do Bigtable se enquadram em duas categorias gerais:

Como ler uma única linha
Verificações ou como ler várias linhas

As leituras são atômicas no nível da linha. Isso significa que, quando você envia uma solicitação de leitura para uma linha, o Bigtable retorna a linha inteira ou, no caso de falha da solicitação, nenhuma linha. Uma linha parcial nunca é retornada, a menos que você solicite especificamente uma.

Recomendamos que você use nossas bibliotecas de cliente do Cloud Bigtable para ler dados de uma tabela em vez de chamar a API diretamente. Os exemplos de código que mostram como enviar solicitações de leitura estão disponíveis em várias linguagens. Todas as solicitações de leitura fazem a chamada de API ReadRows.

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

O Data Boost do Bigtable permite executar consultas e jobs de leitura em lote sem afetar o tráfego diário do aplicativo. O Data Boost é um serviço de computação sem servidor que pode ser usado para ler dados do Bigtable enquanto o aplicativo principal usa os nós do cluster para computação.

O Data Boost é ideal para verificações e não é recomendado para leituras de linha única. Não é possível usar o Data Boost para verificações reversas. Para mais informações e critérios de qualificação, consulte a Visão geral do Data Boost.

Leituras de uma única linha

Você pode solicitar uma única linha com base na chave de linha. Leituras de linha única, também conhecidas como leituras de ponto, não são compatíveis com o Data Boost. Os exemplos de código estão disponíveis para as seguintes variações:

Verificações

As verificações são a maneira mais comum de ler dados do Bigtable. Para ler um intervalo de linhas contíguas ou vários intervalos de linhas pelo Bigtable, especifique um prefixo de chave de linha ou especifique as chaves de linha inicial e final. Os exemplos de código estão disponíveis para as seguintes variações:

Reverter verificações

As verificações reversas permitem que você leia um intervalo de linhas inversamente especificando um prefixo de chave de linha ou um intervalo de linhas. O prefixo da chave de linha é usado como o ponto inicial da verificação para ler de trás para frente. Se você especificar um intervalo de linhas, a chave de linha final será usada como o ponto inicial da verificação.

A verificação na ordem inversa pode ser útil nos seguintes cenários:

Você quer encontrar um evento (linha) e, em seguida, ler o número N de eventos anterior.
Você quer encontrar o valor mais alto antes de um determinado valor. Isso pode ser útil quando você armazena dados de série temporal usando um carimbo de data/hora como um sufixo de chave de linha.

As verificações reversas são menos eficientes do que as futuras. Em geral, projete as chaves de linha para que a maioria das verificações seja encaminhada. Use verificações reversas para verificações curtas, como 50 linhas ou menos, para manter o tempo de resposta de baixa latência.

Para verificar o contrário, defina o valor do campo ReadRowsRequest reversed como verdadeiro. O valor padrão é falso.

As verificações reversas estão disponíveis quando você usa as seguintes bibliotecas de cliente:

Biblioteca de cliente do Bigtable para C++ versão 2.18.0 ou mais recente
Biblioteca de cliente do Bigtable para Go versão 1.21.0 ou mais recente
Biblioteca de 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 amostras de código que demonstram como usar verificações reversas, consulte Verificação inversa.

Exemplos de casos de uso

Os exemplos a seguir mostram como os verificações reversas podem ser usados para encontrar a última vez que um cliente mudou a senha e as flutuações de preço de um produto em um dia específico.

Redefinições de senha

Considere uma suposição de que as chaves de linha contêm 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 senha foi redefinida. O Bigtable armazena automaticamente os dados de maneira lexicográfica, como no exemplo a seguir. Observe que a coluna não existe para linhas (dias) em que a senha não foi redefinida.

`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 você quiser encontrar a última vez que o cliente 123ABC redefiniu a senha, faça a busca reversa de um intervalo de 123ABC# para 123ABC#<DATE>, usando a data de hoje ou uma data no futura para todas as linhas que contenham a coluna password_reset com um limite de linha de 1.

Mudanças no preço

Neste exemplo, as chaves de linha contêm valores de produto, modelo e carimbo de data/hora, e uma das colunas contém o preço do produto e do modelo em 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 você quiser encontrar variações no preço em 14 de fevereiro de 2023, mesmo que não exista uma chave de linha para essa data específica, faça uma verificação a partir da chave de linha productA#model2#1676376000 para N número de linhas e, em seguida, faça uma verificação reversa para o mesmo número de linhas a partir da mesma linha inicial. As duas verificações fornecem os preços antes e depois do horário especificado.

Leituras filtradas

Se você precisar apenas de linhas que contenham valores específicos ou linhas parciais, use um filtro com sua solicitação de leitura. Os filtros permitem que você seja altamente seletivo nos dados desejados.

Os filtros também permitem que você verifique se as leituras correspondem às políticas de coleta de lixo que sua tabela está usando. Isso é útil principalmente se você grava com frequência novas células com carimbo de data/hora em colunas existentes. Como a coleta de lixo pode levar até uma semana para remover os dados expirados, usar um filtro de intervalo de carimbo de data/hora para ler dados pode garantir que você não leia mais dados do que precisa.

A visão geral dos filtros fornece explicações detalhadas sobre os tipos de filtros que você pode usar. Como usar filtros mostra exemplos em várias linguagens.

Ler dados de uma visualização autorizada

Para ler dados de uma visualização autorizada, use uma das seguintes opções:

CLI da gcloud
Cliente Bigtable para Java

As outras bibliotecas de cliente do Bigtable ainda não oferecem suporte ao acesso à visualização.

Qualquer método que chame o método ReadRows ou SampleRowKeys da API Bigtable Data é aceito. Você fornece o ID da visualização autorizada, além do ID da tabela, ao criar o cliente.

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, elas podem reduzir significativamente a quantidade de largura de banda de rede usada, limitando a quantidade de dados retornados. Em geral, os filtros devem ser usados para controlar a eficiência da capacidade e não a latência.

Se você quiser otimizar seu desempenho de leitura, considere as seguintes estratégias:

Restrinja o conjunto de linhas o máximo possível. Limitar o número de linhas que os nós precisam verificar é o primeiro passo para melhorar o tempo até o primeiro byte e a latência geral da consulta. Se você não restringir o conjunto de linhas, o Bigtable certamente terá que verificar toda a tabela. Por isso, recomendamos que você projete seu esquema de modo que suas consultas mais comuns funcionem dessa maneira.
Para melhorar o desempenho depois de restringir o conjunto de linhas, tente adicionar um filtro básico. A restrição do conjunto de colunas ou do número de versões retornadas geralmente não aumenta a latência e pode ajudar o Bigtable a procurar dados irrelevantes em cada linha de maneira mais eficiente.
Se você quiser ajustar ainda mais o desempenho de leitura depois das duas primeiras estratégias, use um filtro mais complicado. Você pode tentar isso por alguns motivos:
- Você ainda está recebendo muitos dados indesejados.
- Você quer simplificar o código do aplicativo enviando a consulta para o Bigtable.
No entanto, lembre-se de que os filtros que exigem condições, intercalações ou correspondência de expressões regulares em valores grandes tendem a trazer mais danos que benefícios se permitirem que a maioria dos dados verificados passem. Esse dano ocorre na forma de maior utilização da CPU no cluster sem grandes reduções no lado do cliente.

Além dessas estratégias, evite ler um grande número de chaves ou intervalos de linha não contíguos em uma única solicitação de leitura. Quando você solicita centenas de chaves ou intervalos de linha em uma única solicitação, o Bigtable verifica a tabela e lê as linhas solicitadas sequencialmente. Essa falta de paralelismo afeta a latência geral, e qualquer leitura que atinja um nó quente pode aumentar a latência de cauda. Quanto mais intervalos de linhas solicitados, mais tempo o processo demora. Se essa latência for inaceitável, envie várias solicitações simultâneas, cada uma recuperando menos intervalos de linha.

Em geral, a leitura de mais intervalos de linhas em uma única solicitação otimiza a capacidade, mas não a latência. A leitura de menos intervalos de linhas em várias solicitações simultâneas otimiza a latência, mas não a capacidade. Encontrar o equilíbrio certo entre latência e capacidade dependerá dos requisitos do seu aplicativo. Isso poderá ser alcançado ao ajustar a contagem de solicitações de leitura simultâneas e o número de intervalos de linhas em uma solicitação.

Linhas grandes

O Bigtable limita o tamanho de uma linha a 256 MB, mas é possível exceder esse limite acidentalmente. Se você precisar ler uma linha maior que o limite, pagine sua solicitação e use um filtro cells per row limit e um filtro cells per row offset. Lembre-se de que, se uma gravação chegar à linha entre as solicitações de leitura paginadas, a leitura poderá não ser atômica.