Letture

In questa pagina vengono descritti 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 conoscere la panoramica di Bigtable.

Panoramica

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

Le query supportate dalla tua tabella dovrebbero aiutare a determinare il tipo di lettura che la soluzione migliore per il 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, nell'evento la richiesta non va a buon fine, nessuna riga. Non viene mai restituita una riga parziale a meno che richiederne una specifica.

Ti consigliamo vivamente di utilizzare le nostre librerie client Cloud Bigtable per leggere i dati da una tabella anziché chiamare direttamente l'API. Esempi di codice che mostrano come inviare richieste di lettura: 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 serverless computing che puoi utilizzare per leggere i tuoi Bigtable mentre l'applicazione principale utilizza i nodi del cluster per il calcolo.

Data Boost è ideale per le analisi e non è consigliato per le letture su riga singola. Non puoi utilizzare Data Boost per le scansioni inverse. Per ulteriori informazioni e sui criteri di idoneità, consulta la scheda Data Boost Panoramica.

Letture su riga singola

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 un intervallo di righe contigue o più intervalli di righe da Bigtable, specificando un prefisso di chiave di riga o specificando l'inizio e le chiavi di riga finali. Sono disponibili esempi di codice per le seguenti varianti:

Scansioni invertite

Le scansioni inverse consentono di leggere un intervallo di righe all'indietro specificando una riga o un intervallo di righe. Il prefisso della chiave di riga è utilizzato come punto di avvio punto della scansione per leggerle al contrario. Se specifichi un intervallo di righe, la chiave di riga finale viene utilizzata come dal punto di partenza della scansione.

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

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 vada avanti. Utilizza scansioni inverse per scansioni brevi, ad esempio 50 righe o meno, per mantenere un tempo di risposta a bassa latenza.

Per eseguire la scansione invertita, imposta il valore per il campo ReadRowsRequest reversed su true. Il valore predefinito è false.

Le scansioni inverse sono disponibili quando utilizzi quanto segue 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 2.24.1 o versioni successive
  • Client Bigtable HBase per Java versione 2.10.0 o successiva

Per gli esempi di codice che dimostrano come utilizzare le scansioni inverse, consulta Eseguire la scansione in inversa.

Esempi di casi d'uso

I seguenti esempi mostrano come è possibile utilizzare le scansioni inverse per trovare l'ultima ora un cliente ha cambiato la password e le fluttuazioni di prezzo di un prodotto in base a un giorno.

Reimpostazione password

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

`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 sapere quando è stata l'ultima volta che il cliente 123ABC ha reimpostato la password, puoi eseguire la scansione invertita di un intervallo compreso tra 123ABC# e 123ABC#<DATE>, utilizzando la o una data futura, per tutte le righe contenenti la colonna password_reset con un limite di 1 righe.

Modifiche ai prezzi

In questo esempio, le chiavi di riga contengono valori per product, model e timestamp, e una delle colonne contiene il prezzo del prodotto e del modello in un determinato nel tempo.

`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 per il 14 febbraio, 2023, anche se non esiste una chiave di riga per quella data specifica puoi eseguire una scansione in avanti iniziando dalla chiave di riga productA#model2#1676376000 per N numero di righe, quindi esegui una scansione inversa per lo stesso numero di righe nella stessa riga iniziale. Le due scansioni offrono i prezzi prima e dopo il periodo di tempo stabilito.

Letture filtrate

Se hai bisogno solo di righe che contengono valori specifici o righe parziali, puoi utilizzare un filtro con la richiesta di lettura. I filtri consentono di essere molto selettivi nelle i dati desiderati.

I filtri ti consentono inoltre di assicurarti che le letture corrispondano criteri di garbage collection utilizzati dalla tabella. Questo è particolarmente utile se scrivi spesso nuove celle con timestamp in celle colonne. Perché la rimozione della garbage collection può richiedere fino a una settimana di dati, l'utilizzo di un filtro per l'intervallo di timestamp per leggere i dati può assicurarti di non leggere i dati necessari.

La panoramica dei filtri fornisce spiegazioni dettagliate dei tipi di filtri che puoi utilizzare. L'utilizzo dei 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 di Bigtable non supportano ancora la visualizzazione l'accesso.

Qualsiasi metodo che chiama il metodo ReadRows o SampleRowKeys del metodo L'API Bigtable Data è supportata. 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 di 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 dovrebbero essere utilizzati per controllare l'efficienza della velocità effettiva, non una latenza di pochi millisecondi.

Se vuoi ottimizzare le prestazioni di lettura, considera quanto segue strategie:

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

  2. Per ulteriori ottimizzazioni delle prestazioni dopo aver limitato l'insieme di righe, prova ad aggiungere un filtro di base. Applicare limitazioni all'insieme di colonne o al numero restituite in genere non aumentano la latenza e a volte possono Bigtable esegue una ricerca più efficiente oltre i dati irrilevanti in ogni riga.

  3. Se vuoi perfezionare ulteriormente le prestazioni di lettura dopo le prime due strategie, valuta l'utilizzo di un filtro più complicato. Puoi provare questa procedura per alcuni motivi:

    • Continui a recuperare molti dati che non ti interessano.
    • Vuoi semplificare il codice dell'applicazione eseguendo il push della query Bigtable.

    Tieni presente, tuttavia, che i filtri che richiedono condizioni, interfoliazioni o espressioni regolari la corrispondenza su valori elevati tende a fare più male che bene se consente la maggior parte dei tramite i dati scansionati. Questo danno si presenta sotto forma di aumento della CPU all'utilizzo nel tuo cluster senza risparmi significativi sul lato client.

Oltre a queste strategie, evita di leggere un gran numero di chiavi di riga non contigue o intervalli di righe in un'unica richiesta di lettura. Quando richiedere centinaia di chiavi di riga o intervalli di righe in una singola richiesta, Bigtable analizza la tabella e legge le righe richieste in sequenza. Questa mancanza di parallelismo influisce sulla latenza complessiva e su qualsiasi le letture che hanno colpito un nodo attivo possono aumentare la latenza tail. Più intervalli di righe richiesti, maggiore sarà il tempo necessario per il completamento della lettura. Se la latenza è non accettabile, dovresti invece inviare più richieste in parallelo che e recuperare 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. Lettura di meno intervalli di righe in più richieste in parallelo ottimizza la latenza, ma non la velocità effettiva. Trovare il giusto equilibrio tra latenza e la velocità effettiva dipenderanno dai requisiti dell'applicazione e possono essere raggiunto modificando il numero di richieste di lettura simultanee e il numero di righe in una singola richiesta.

Righe grandi

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

Passaggi successivi