Letture

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

Panoramica

Le richieste di lettura a Bigtable restituiscono i contenuti delle righe richieste in ordine di chiave, ovvero nell'ordine in cui sono 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

Per visualizzare la distribuzione del traffico di lettura tra i tipi di query, ad esempio letture puntuali, scansioni brevi, scansioni inverse, letture sparse e letture collettive, consulta Analizza i pattern di accesso.

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, se la richiesta non va a buon fine, nessuna riga. Una riga parziale non viene mai restituita, a meno che tu non la richieda specificamente.

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 di Data Boost

Bigtable Data Boost ti consente di eseguire job di lettura con throughput elevato senza influire sul traffico delle applicazioni del percorso di gestione. Data Boost è un servizio di serverless computing che puoi utilizzare per leggere i dati Bigtable mentre l'applicazione principale utilizza i nodi del cluster per il computing. Enterprise Plus estende la funzionalità di query di Data Boost con il supporto di SQL e l'accesso ai dati di archiviazione HDD e a livelli.

Data Boost è ideale per le scansioni e non è consigliato per le letture di singole righe. Non puoi utilizzare Data Boost per le scansioni inverse. Per saperne di più e per i criteri di idoneità, consulta la panoramica di Data Boost.

Letture di singole righe

Puoi richiedere una singola riga in base alla chiave di riga. Le letture di una singola 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 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 consentono di leggere un intervallo di righe al contrario specificando un prefisso della chiave di riga o un intervallo di righe. Il prefisso della chiave di riga viene utilizzato come punto di partenza della scansione per la lettura a ritroso. 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 sia in avanti. Utilizza le scansioni inverse per scansioni brevi, ad esempio di 50 righe o meno, 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 di Bigtable per C++ versione 2.18.0 o successive
  • Libreria client di 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 inverse, consulta Esegui la scansione in ordine inverso.

Esempi di casi d'uso

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

Reimpostazioni 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 la password è stata reimpostata. Bigtable archivia automaticamente i dati in ordine lessicografico, come mostrato 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 una scansione inversa di 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.

Variazioni di prezzo

In questo esempio, le chiavi di riga contengono valori per prodotto, modello e timestamp, mentre 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 intorno 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 righe, quindi eseguire una scansione inversa per lo stesso numero di righe dalla stessa riga di partenza. Le due scansioni ti forniscono i prezzi prima e dopo l'ora specificata.

Letture filtrate

Se hai bisogno solo di righe che contengono valori specifici o di 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 anche di assicurarti che le letture corrispondano alle policy di garbage collection utilizzate dalla tabella. Questo è particolarmente utile se scrivi spesso nuove celle con timestamp in colonne esistenti. Poiché la garbage collection può richiedere fino a una settimana per rimuovere i dati scaduti, l'utilizzo di un filtro per l'intervallo di timestamp per leggere i dati può garantire che non vengano letti più dati del necessario.

La panoramica dei filtri fornisce spiegazioni dettagliate dei tipi di filtri che puoi utilizzare. Utilizzo dei filtri mostra esempi in più linguaggi.

Leggi i dati da una vista autorizzata

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

  • gcloud CLI
  • Client Bigtable per Java

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

È supportato qualsiasi metodo che chiama il metodo ReadRows o SampleRowKeys dell'API Bigtable Data. Quando crei il client, fornisci l'ID della visualizzazione autorizzata oltre all'ID della tabella.

Leggi i dati da una vista materializzata continua

Puoi leggere i dati da una vista materializzata continua utilizzando SQL o la chiamata API di dati ReadRows. Le viste materializzate continue sono di sola lettura. I dati in una vista materializzata vengono digitati in base alla query che li definisce.

SQL

Per leggere i dati da una vista materializzata continua utilizzando SQL, puoi utilizzare l'editor di query di Bigtable Studio o una delle librerie client che supportano le query SQL.

SQL espone automaticamente i risultati delle query come colonne tipizzate, quindi non è necessario gestire la codifica nella query.

Quando crei una vista materializzata continua, Bigtable crea automaticamente uno schema della chiave di riga per la tabella che definisce le chiavi di riga strutturate per la vista. Per saperne di più sull'esecuzione di query su chiavi di riga strutturate con SQL, consulta Query su chiave di riga strutturate.

Lettura dei dati durante il popolamento iniziale

Quando crei una vista materializzata continua su una tabella esistente, Bigtable avvia un processo di popolamento iniziale che copia i dati della tabella esistente nella vista.

Per impostazione predefinita, per garantire la correttezza dei dati, Bigtable rifiuta le richieste di lettura che tentano di leggere da una vista materializzata continua durante la creazione della vista. Se esegui una query su una visualizzazione ancora in fase di compilazione, Bigtable restituisce l'errore Materialized view is still creating.. L'errore ha un codice di stato FAILED_PRECONDITION.

Se la tua applicazione può tollerare dati incompleti, puoi attivare la lettura dalla vista prima che il popolamento iniziale sia terminato. Per leggere da una vista materializzata continua durante la popolazione iniziale, aggiungi il suggerimento per la query a livello di istruzione allow_incomplete_view=true alla query SQL:

SELECT key_part FROM `VIEW_ID` @{allow_incomplete_view=true}

Sostituisci VIEW_ID con l'identificatore univoco della tua vista materializzata continua.

Per saperne di più, consulta Creazione di viste materializzate continue su tabelle esistenti.

API di dati

Se prevedi di leggere da una vista materializzata continua con una chiamata ReadRows da una delle librerie client per Bigtable, devi esaminare la query SQL utilizzata per definire la vista. Prendi nota se la vista ha una colonna _key definita, consigliata per le viste che devono essere lette utilizzando ReadRows, e se ha una colonna _timestamp.

Devi anche conoscere il tipo di ogni colonna e decodificare i dati della colonna nel codice dell'applicazione.

I valori aggregati in una vista materializzata continua vengono archiviati utilizzando la codifica descritta nella tabella seguente, in base al tipo di output della colonna dalla definizione della vista.

Tipo Codifica
BOOL Valore di 1 byte, 1 = true, 0 = false
BYTES Nessuna codifica
INT64 (o INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT) Big-endian a 64 bit
FLOAT64 IEEE 754 a 64 bit, esclusi NaN e +/-inf
STRING UTF-8
TIME/TIMESTAMP Numero intero a 64 bit che rappresenta il numero di microsecondi trascorsi dall'epoca di Unix (coerente con GoogleSQL)
Per saperne di più, consulta Codifica nel riferimento dell'API di dati.

Oltre a conoscere il tipo di ogni colonna nella vista, devi conoscere la famiglia di colonne e il qualificatore di colonna. La famiglia di colonne predefinita è denominata default e il qualificatore di colonna è l'alias specificato nella query di definizione. Ad esempio, considera una vista materializzata continua definita con questa query:

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

Quando esegui una query sulla vista con ReadRows, fornisci la famiglia di colonne default e il qualificatore di colonna sum_clicks.

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, i filtri devono essere utilizzati per controllare l'efficienza del throughput, 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 Time to First Byte e la latenza complessiva delle query. Se non limiti il set di righe, Bigtable dovrà quasi sicuramente scansionare l'intera tabella. Per questo motivo, ti consigliamo di progettare lo schema in modo che le query più comuni funzionino in questo modo.

  2. Per un'ulteriore ottimizzazione delle prestazioni dopo aver limitato il set 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 non pertinenti in ogni riga.

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

    • Ricevi ancora molti dati che non ti interessano.
    • Vuoi semplificare il codice dell'applicazione eseguendo il push della query in Bigtable.

    Tieni presente, tuttavia, che i filtri che richiedono condizioni, interfoliazioni o corrispondenze di espressioni regolari su valori di grandi dimensioni tendono a fare più male che bene se consentono il passaggio della maggior parte dei dati scansionati. Questo danno si presenta sotto forma di un aumento dell'utilizzo della CPU nel cluster senza grandi risparmi lato client.

Oltre a queste strategie, evita di leggere un numero elevato di chiavi di riga o intervalli di righe non contigui in una singola richiesta di lettura. Quando richiedi 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 le letture che interessano un nodo hot possono aumentare la latenza tail. Più intervalli di righe vengono richiesti, più tempo sarà necessario per completare la lettura. Se questa latenza è inaccettabile, devi inviare più richieste in parallelo, ognuna delle quali recupera un numero inferiore di 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 il throughput. La ricerca del giusto equilibrio tra latenza e throughput dipenderà dai requisiti della tua applicazione e può essere ottenuta modificando il numero di richieste di lettura simultanee e il numero di intervalli di righe in una richiesta.

Righe grandi

Bigtable applica i seguenti limiti alle righe di grandi dimensioni:

  • 256 MB è la dimensione massima di una riga. Se devi leggere una riga che ha superato 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.

  • 512 kB è la dimensione massima di una chiamata API ReadRows. Se superi il limite, Bigtable restituisce un errore INVALID_ARGUMENT.

Passaggi successivi