Letture

Questa pagina descrive i tipi di richieste di lettura che puoi inviare a Bigtable, illustra le implicazioni sul rendimento e presenta alcuni consigli per tipi specifici di query. Prima di leggere questa pagina, devi conoscere la panoramica di Bigtable.

Panoramica

Le richieste di lettura a Bigtable restituiscono in streaming i contenuti delle righe richieste in ordine di chiave, ovvero nell'ordine in cui vengono archiviate. Puoi leggere tutte le scritture che hanno restituito una risposta.

Le query supportate dalla tabella dovrebbero aiutarti a determinare il tipo di lettura più adatto al tuo caso d'uso. Le richieste di lettura di Bigtable rientrano in due categorie generali:

  • Lettura di una singola riga
  • Scansioni o lettura di più righe

Le letture sono atomiche a livello di riga. Ciò significa che quando invii una richiesta di lettura per una riga, Bigtable restituisce l'intera riga o, nel caso in cui la richiesta non vada a buon fine, nessuna riga. Una riga parziale non viene mai restituita, a meno che non la richieda specificamente.

Ti consigliamo vivamente di utilizzare le nostre librerie client Cloud Bigtable per leggere i dati da una tabella anziché chiamare direttamente l'API. Gli esempi di codice che mostrano come inviare richieste di lettura sono disponibili in più lingue. Tutte le richieste di lettura eseguono la chiamata all'API ReadRows.

Lettura dei dati con il serverless computing di Data Boost

Bigtable Data Boost ti consente di eseguire query e job di lettura collettivi senza influire sul traffico giornaliero delle applicazioni. Data Boost è un servizio di calcolo serverless che puoi utilizzare per leggere i dati Bigtable mentre l'applicazione principale utilizza i nodi del cluster per il calcolo.

Data Boost è ideale per le scansioni e non è consigliato per le letture di una riga. Non puoi utilizzare Data Boost per le scansioni inverse. Per ulteriori informazioni e i criteri di idoneità, consulta la panoramica di Data Boost.

Letture di una riga

Puoi richiedere una singola riga in base alla chiave di riga. Le letture di una riga, note anche come letture puntuali, non sono compatibili con Data Boost. Sono disponibili esempi di codice per le seguenti varianti:

Scansioni

Le scansioni sono il modo più comune per leggere i dati di Bigtable. Puoi leggere da Bigtable un intervallo di righe contigue o più intervalli di righe, specificando un prefisso della chiave di riga o le chiavi di riga iniziale e finale. Sono disponibili esempi di codice per le seguenti varianti:

Scansioni inverse

Le scansioni inverse ti consentono di leggere un intervallo di righe in ordine inverso specificando un prefisso della chiave di riga o un intervallo di righe. Il prefisso della chiave di riga viene utilizzato come punto di inizio della scansione per la lettura all'indietro. Se specifichi un intervallo di righe, la chiave di riga finale viene utilizzata come punto di inizio della scansione.

La scansione in ordine inverso può essere utile nei seguenti scenari:

Le scansioni inverse sono meno efficienti di quelle in avanti. In generale, progetta le chiavi di riga in modo che la maggior parte delle scansioni avvenga in avanti. Utilizza le ricerche inverse per ricerche brevi, ad esempio con massimo 50 righe, per mantenere un tempo di risposta a bassa latenza.

Per eseguire la scansione in ordine inverso, imposta il valore del campo ReadRowsRequest reversed su true. Il valore predefinito è false.

Le scansioni inverse sono disponibili quando utilizzi le seguenti librerie client:

  • Libreria client Bigtable per C++ versione 2.18.0 o successive
  • Libreria client Bigtable per Go versione 1.21.0 o successive
  • Libreria client Bigtable per Java versione 2.24.1 o successive
  • Client Bigtable HBase per Java versione 2.10.0 o successive

Per esempi di codice che mostrano come utilizzare le scansioni in ordine inverso, consulta Eseguire una scansione in ordine inverso.

Esempi di casi d'uso

I seguenti esempi mostrano come le analisi inverse possono essere utilizzate per trovare l'ultima volta che un cliente ha modificato la password e le fluttuazioni di prezzo di un prodotto in un determinato giorno.

Reimpostazione delle password

Supponiamo che le chiavi di riga contengano ciascuna un ID cliente e una data nel formato 123ABC#2022-05-02 e che una delle colonne sia password_reset, che memorizza l'ora in cui è stata reimpostata la password. Bigtable memorizza automaticamente i dati in ordine alfabetico, come segue. Tieni presente che la colonna non esiste per le righe (giorni) in cui la password non è stata reimpostata.

`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 vuoi trovare l'ultima volta che il cliente 123ABC ha reimpostato la password, puoi eseguire la scansione inversa di un intervallo da 123ABC# a 123ABC#<DATE>, utilizzando la data odierna o una data futura, per tutte le righe che contengono la colonna password_reset con un limite di righe pari a 1.

Modifiche ai prezzi

In questo esempio, le chiavi di riga contengono i valori per prodotto, modello e timestamp e una delle colonne contiene il prezzo del prodotto e del modello in un determinato 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 vuoi trovare le fluttuazioni dei prezzi intorno al prezzo del 14 febbraio 2023, anche se nella tabella non esiste una chiave di riga per quella determinata data, puoi eseguire una ricerca in avanti a partire dalla chiave di riga productA#model2#1676376000 per un numero N di righe e poi una ricerca inversa per lo stesso numero di righe dalla stessa riga iniziale. Le due scansioni ti forniscono i prezzi prima e dopo l'ora specificata.

Letture filtrate

Se ti servono solo righe che contengono valori specifici o righe parziali, puoi utilizzare un filtro con la richiesta di lettura. I filtri ti consentono di essere molto selettivo nei dati che vuoi.

I filtri ti consentono inoltre di assicurarti che le letture corrispondano alle norme di raccolta dei rifiuti utilizzate dalla tabella. Questa funzionalità è particolarmente utile se scrivi spesso nuove celle con timestamp nelle colonne esistenti. Poiché la garbage collection può richiedere fino a una settimana per rimuovere i dati scaduti, l'utilizzo di un filtro per un intervallo di timestamp per leggere i dati può garantire che non vengano letti più dati di quelli necessari.

La panoramica dei filtri fornisce spiegazioni dettagliate dei tipi di filtri che puoi utilizzare. Utilizzare i filtri mostra esempi in più lingue.

Leggere i dati da una vista autorizzata

Per leggere i dati da una visualizzazione autorizzata, devi utilizzare una delle seguenti opzioni:

  • Interfaccia a riga di comando gcloud
  • Client Bigtable per Java

Le altre librerie client Bigtable non supportano ancora l'accesso alle visualizzazioni.

È supportato qualsiasi metodo che chiami il metodo ReadRows o SampleRowKeys dell'API Bigtable Data. Fornisci l'ID vista autorizzata oltre all'ID tabella quando crei il client.

Letture e prestazioni

Le letture che utilizzano i filtri sono più lente di quelle senza filtri e aumentano l'utilizzo della CPU. D'altra parte, possono ridurre notevolmente la quantità di larghezza di banda di rete utilizzata, limitando la quantità di dati restituiti. In generale, i filtri devono essere utilizzati per controllare l'efficienza del throughput, non la latenza.

Se vuoi ottimizzare il rendimento delle letture, valuta le seguenti strategie:

  1. Limita il set di righe il più possibile. Limitare il numero di righe che i tuoi nodi devono analizzare è il primo passo per migliorare il tempo di risposta al primo byte e la latenza complessiva delle query. Se non limiti l'insieme di righe, Bigtable dovrà quasi sicuramente eseguire la scansione dell'intera tabella. Per questo motivo, ti consigliamo di progettare lo schema in modo che le query più comuni funzionino in questo modo.

  2. Per ulteriori ottimizzazioni delle prestazioni dopo aver limitato l'insieme di righe, prova ad aggiungere un filtro di base. La limitazione dell'insieme di colonne o del numero di versioni restituite in genere non aumenta la latenza e a volte può aiutare Bigtable a cercare in modo più efficiente i dati irrilevanti precedenti in ogni riga.

  3. Se vuoi ottimizzare ulteriormente il rendimento della lettura dopo le prime due strategie, ti consigliamo di utilizzare un filtro più complesso. Potresti provare questa operazione per diversi motivi:

    • Ricevi ancora molti dati che non ti interessano.
    • Vuoi semplificare il codice dell'applicazione inviando la query a Bigtable.

    Tieni presente, però, che i filtri che richiedono condizioni, interlinee o corrispondenza di espressioni regolari su valori elevati tendono a fare più male che bene se consentono il passaggio della maggior parte dei dati sottoposti a scansione. Questo danno si manifesta sotto forma di un aumento dell'utilizzo della CPU nel cluster senza grandi risparmi lato client.

Oltre a queste strategie, evitare di leggere un numero elevato di chiavi di riga o intervalli di riga non contigui in una singola richiesta di lettura. Quando richiedi centinaia di chiavi di riga o intervalli di riga in una singola richiesta, Bigtable esegue la scansione della tabella e legge le righe richieste in sequenza. Questa mancanza di parallelismo influisce sulla latenza complessiva e qualsiasi lettura che colpisce un nodo caldo può aumentare la latenza della coda. Maggiore è il numero di intervalli di righe richiesti, maggiore è il tempo necessario per completare la lettura. Se questa latenza è inaccettabile, ti consigliamo di inviare più richieste in contemporanea che recuperano ciascuna meno intervalli di righe.

In generale, la lettura di più intervalli di righe in una singola richiesta ottimizza la velocità effettiva, ma non la latenza. La lettura di un numero inferiore di intervalli di righe in più richieste simultanee ottimo la latenza, ma non il throughput. Trovare il giusto equilibrio tra latenza e throughput dipende dai requisiti dell'applicazione e può essere ottenuto modificando il numero di richieste di lettura simultanee e il numero di intervalli di righe in una richiesta.

Righe grandi

Bigtable limita la dimensione di una riga a 256 MB, ma è possibile superare accidentalmente questo valore massimo. Se devi leggere una riga di dimensioni superiori al limite, puoi paginare la richiesta e utilizzare un filtro cells per row limit e un filtro cells per row offset. Tieni presente che se viene eseguita una scrittura per la riga tra le richieste di lettura paginate, la lettura potrebbe non essere atomica.

Passaggi successivi