Letture

Questa pagina descrive i tipi di richieste di lettura che puoi inviare a Bigtable, illustra le implicazioni in termini di prestazioni e presenta alcuni suggerimenti per tipi specifici di query. Prima di leggere questa pagina, dovresti acquisire familiarità con la panoramica di Bigtable.

Panoramica

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

Le query supportate dalla tua tabella dovrebbero aiutare a determinare il tipo di lettura migliore per il tuo caso d'uso. Le richieste di lettura di Bigtable rientrano in due categorie generali:

  • Lettura di una singola riga
  • Esegue scansioni o lettura di più righe

Le letture sono atomiche a livello di riga. Questo 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. Non viene mai restituita una riga parziale, a meno che non ne richiedi espressamente una.

Ti consigliamo vivamente di utilizzare le nostre librerie client di 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 effettuano la chiamata API ReadRows.

Lettura dei dati con il serverless computing Data Boost

Bigtable Data Boost consente di eseguire query e job di lettura batch senza influire sul traffico giornaliero delle applicazioni. Data Boost è un servizio di computing 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 su riga singola. Non puoi utilizzare Data Boost per le analisi inverse. Per ulteriori informazioni e per i criteri di idoneità, consulta la panoramica di Data Boost.

Letture su riga singola

Puoi richiedere una singola riga in base alla chiave di riga. Le letture su riga singola, note anche come letture punti, 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 un intervallo di righe contigue o più intervalli di righe da Bigtable, specificando il prefisso di una chiave di riga o le chiavi di riga di inizio e fine. Sono disponibili esempi di codice per le seguenti varianti:

Scansioni inverse

Le analisi inverse consentono di leggere un intervallo di righe a ritroso specificando il prefisso di una chiave di riga o un intervallo di righe. Il prefisso della chiave di riga è usato come punto iniziale della scansione da leggere a ritroso. Se specifichi un intervallo di righe, la chiave di riga finale viene utilizzata come punto di avvio della scansione.

La scansione in ordine inverso può essere utile per i 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 analisi vada avanti. Utilizza scansioni inverse per brevi scansioni, ad esempio 50 righe o meno, per mantenere tempi di risposta a bassa latenza.

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

Quando utilizzi le seguenti librerie client, sono disponibili analisi inverse:

  • 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 2.24.1 o versioni successive
  • Client Bigtable HBase per Java versione 2.10.0 o successive

Per esempi di codice che mostrano come utilizzare le scansioni inverse, consulta Eseguire scansioni inverse.

Esempi di casi d'uso

I seguenti esempi mostrano come è possibile utilizzare le scansioni inverse per trovare l'ultima volta che un cliente ha modificato la propria password e le fluttuazioni di prezzo per un prodotto in un determinato giorno.

Reimpostazione 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, in cui è memorizzata l'ora in cui la password è stata reimpostata. Bigtable archivia automaticamente i dati lessicograficamente, come di seguito. 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 in un intervallo compreso tra 123ABC# e 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 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 di prezzo relative al prezzo del 14 febbraio 2023, anche se nella tabella non esiste una chiave di riga per quella data specifica, puoi eseguire una scansione in avanti a partire dalla chiave di riga productA#model2#1676376000 per N numero di righe, poi eseguire una scansione inversa per lo stesso numero di righe della stessa riga iniziale. Le due analisi ti forniscono i prezzi prima e dopo il periodo indicato.

Letture filtrate

Se hai bisogno solo di righe che contengono valori specifici o righe parziali, puoi utilizzare un filtro con la tua richiesta di lettura. I filtri ti consentono di scegliere in modo altamente selettivo i dati che vuoi.

I filtri consentono inoltre di assicurarti che le letture corrispondano ai criteri di garbage collection utilizzati nella tabella. Questo è particolarmente utile se spesso scrivi nuove celle con timestamp in colonne esistenti. Poiché la garbage collection può richiedere fino a una settimana per rimuovere i dati scaduti, l'uso di un filtro per intervallo di timestamp per leggere i dati può assicurarti di non leggere più dati del necessario.

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

Leggere i dati da una vista autorizzata

Per leggere i dati da una vista autorizzata, devi utilizzare uno dei seguenti elementi:

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

Le altre librerie client di Bigtable non supportano ancora l'accesso in visualizzazione.

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

Letture e prestazioni

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

Se vuoi ottimizzare le prestazioni di lettura, prendi in considerazione le seguenti strategie:

  1. Limita il più possibile il set di righe. Limitare il numero di righe che i nodi devono analizzare è il primo passo per migliorare il tempo per il primo byte e la latenza complessiva delle query. Se non limiti il set di righe, Bigtable dovrà quasi certamente scansionare l'intera tabella. Per questo motivo ti consigliamo di progettare lo schema in modo che permetta alle query più comuni di funzionare in questo modo.

  2. Per un'ulteriore ottimizzazione delle prestazioni dopo aver limitato il set di righe, prova ad aggiungere un filtro di base. Limitare l'insieme di colonne o il numero di versioni restituite in genere non aumenta la latenza e a volte può aiutare Bigtable a cercare in modo più efficiente i dati non pertinenti in ogni riga.

  3. Se vuoi perfezionare ulteriormente le prestazioni di lettura dopo le prime due strategie, valuta la possibilità di utilizzare un filtro più complicato. Potresti provare a farlo per diversi motivi:

    • Stai ancora ricevendo molti dati indesiderati.
    • Vuoi semplificare il codice dell'applicazione eseguendo il push della query in Bigtable.

    Tuttavia, tieni presente che i filtri che richiedono condizioni, interleaving o corrispondenza di espressioni regolari su valori di grandi dimensioni tendono a fare più male che bene se lasciano passare la maggior parte dei dati analizzati. Questo danno si presenta sotto forma di aumento dell'utilizzo della CPU nel cluster senza grandi risparmi sul lato client.

Oltre a queste strategie, evita di leggere un numero elevato di chiavi di riga o intervalli di righe non contigue in una singola richiesta di lettura. Quando richiedi centinaia di chiavi di riga o intervalli di righe 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 ad accesso frequente può aumentare la latenza tail. Maggiore è il numero di intervalli di righe richiesti, più lungo sarà il tempo di completamento della lettura. Se questa latenza non è accettabile, devi inviare più richieste in parallelo, ognuna delle quali recupera 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 in parallelo ottimizza la latenza, ma non la velocità effettiva. Trovare il giusto equilibrio tra latenza e velocità effettiva dipende dai requisiti della tua applicazione e può essere ottenuto regolando il numero di richieste di lettura simultanee e il numero di intervalli di righe in una richiesta.

Righe grandi

Bigtable limita le dimensioni di una riga a 256 MB, ma è possibile che venga accidentalmente superato questo limite massimo. Se devi leggere una riga che è cresciuta oltre il limite, puoi impaginare la richiesta e utilizzare un filtro cells per row limit e un filtro cells per row offset. Tieni presente che se arriva una scrittura per la riga tra le richieste di lettura impaginate, la lettura potrebbe non essere atomica.

Passaggi successivi