In che modo Google memorizza le tue grandi tabelle di query e in che modo ti influenza

Questa è un'installazione di un tech talk del nostro blog, presentata dallo straordinario sviluppatore Adam Knox.

Sebbene Big Query utilizzi una sintassi molto simile a SQL, in realtà richiede un tatto significativamente diverso rispetto a una soluzione per l'elaborazione di grandi quantità di dati. Big Query ha la tendenza a forzare le cose e in realtà non utilizza indici, quindi molti dati significano molti processori e tempo di elaborazione. Per ottenere questo risultato, Google ha adottato un modo diverso di archiviare i dati che potrebbero influenzare il modo in cui si progettano le query.

Formato del file

Quando viene creata una tabella, Google utilizza il formato ColumnIO per archiviare i tuoi dati. Ogni colonna viene archiviata come un file separato con l'eccezione dei campi ripetuti. Se hai una tabella con le colonne: name (stringa), phoneNumbers (intero ripetuto); il nominativo verrà memorizzato su un'unica riga con gli altri nominativi e tutti i numeri telefonici associati a quel nominativo verranno memorizzati su un'unica riga con i numeri telefonici. Anche le colonne possono essere suddivise se diventano troppo grandi, ma ciò non influirà sul flusso di lavoro.

Sapere questo offre la possibilità di eseguire query più veloci non elaborando colonne che non ti interessano effettivamente e in alcuni casi rende persino impossibile eseguire query in precedenza. Le query possono anche diventare più economiche poiché il sistema addebita la quantità di dati elaborati e se una colonna non è inclusa nella query, i dati non vengono elaborati.

Archiviazione di file

Se hai creato una tabella, puoi sentirti ragionevolmente sicuro che non andrà da nessuna parte, perché una volta creati i tuoi file, vengono archiviati in tre diversi data center e persino in tre posti diversi all'interno di ciascun data center. Poiché Big Query pone problemi ai processori, i dati devono essere prontamente accessibili. L'avvertenza a questo è dataset temporanei. C'è un'opzione per specificare un tempo di scadenza per le tabelle all'interno di un set di dati e le tabelle andranno via una volta che sono più vecchie di questa data di scadenza.

Gerarchia delle tabelle

Un progetto ha la capacità di memorizzare set di dati, ognuno dei quali è in grado di contenere tabelle. Il comando completo per accedere a una tabella nella sintassi di Big Query è [projectname:datasetname.tablename] , tuttavia può essere abbreviato in dataset.tablename se accedi alla tabella dal progetto su cui stai attualmente lavorando.

La suddivisione dei dati correlati in tabelle separate (ad es. per data o dopo che si è verificato un evento specifico) può essere utile per rendere le query più gestibili poiché le query generalmente vengono eseguite su tutte le righe di una tabella. Ciò significa che potresti voler guardare più tabelle, quindi c'è qualcosa chiamato metatabella nascosta in ogni set di dati che è accessibile in [projectname:datasetname.__TABLES__] e contiene informazioni su ciascuna tabella nel set di dati e può essere utilizzato per aggregare tabelle per interrogare.

Il comando TABLE_QUERY è un comando che consente di aggregare più tabelle simili prima di eseguire una query sull'aggregato e qualsiasi colonna in __TABLES__ può essere utilizzata per formare questo aggregato. Ad esempio, se voglio un'idea dei tempi di risposta dal 1 gennaio 2016 per un progetto, potrei eseguire la seguente query che mostra i tempi di risposta minimo, mediano e massimo:

 SELECT QUANTILES((protoPayload.endTime - protoPayload.startTime), 3) AS responseTimeBucketsInMilliseconds FROM (TABLE_QUERY(appengine_logs, "table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000"))

Poiché vengono utilizzate solo due colonne ciascuna contenente numeri interi, questa è ancora una query ragionevolmente economica ($ 0,0003), anche se sta accedendo a 28+ che mi è stato detto che è 1,857 TB dalla query seguente e costerebbe circa 9 $ per accedere a ogni campo da .

 SELECT SUM(size_bytes)/1000000000 FROM [repcore-prod:appengine_logs.__TABLES__] WHERE table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000

Aggiornamento dei file

Big Query è ottimo quando si tratta di registrare le modifiche e analizzare tali modifiche perché è possibile eseguire lo streaming di nuove righe in una tabella. È, tuttavia, un terribile dispositivo di archiviazione dati per ricerche rapide e frequenti di righe specifiche a causa della mancanza di indici, e inoltre non è eccezionale per archiviare rappresentazioni singolari di oggetti che prevedi di modificare perché le righe in una tabella non possono essere modificate o rimosse .

Tavoli divisori

In alcune situazioni anche l'accesso a una singola colonna è troppo difficile da gestire in Big Query. Ti presento la seguente query inutilizzabile che restituisce gli ID elenco in base all'ordine della data di creazione dell'elenco:

 SELECT lid FROM [repcore-prod:datastore.LIS] ORDER BY ct

Tecnicamente, di recente è diventato possibile che ciò abbia successo, ma non per le persone in Vendasta perché richiede l'abilitazione di un livello di fatturazione più elevato. Poiché non ci sono indici preordinati, sta elaborando una piccola quantità di dati in modo molto intensivo, quindi in questo caso stanno addebitando l'elaborazione. La modifica del livello di fatturazione può essere eseguita nelle query interattive nell'interfaccia utente di Big Query selezionando "consenti illimitato" (se abilitato) sotto il pulsante "opzioni".

Supponendo che la tua query sia il più efficiente possibile, sono rimasti un paio di approcci per ridurre le dimensioni delle tabelle per aggirare questo tipo di limiti rigidi. Il primo è decoratori da tavola e il secondo è con un hash.

Puoi saperne di più sui decoratori di tavoli qui. A differenza del filtraggio dei risultati utilizzando comandi come LIMIT/WHERE/HAVING/OMIT , i decoratori di tabelle ridurranno effettivamente il costo dell'interrogazione di una tabella perché non accederanno nemmeno ai dati al di fuori dell'intervallo specificato. Sfortunatamente, questo metodo è quasi inutile su Vendasta perché anche per tabelle come ListingHistoryModel su cui eseguiamo effettivamente lo streaming, eliminiamo comunque l'intera tabella e la sostituiamo ogni giorno con una replica se proveniente da NDB, il che significa che i decoratori dell'ora del tavolo funzioneranno solo sul ListingHistoryModel se ti interessano solo le voci del giorno corrente.

Guardare la registrazione è l'unico posto in cui possono essere abbastanza utili in Vendasta. A causa delle dimensioni del contenuto effettivo del registro, i limiti di calcolo e memoria sono facili da raggiungere e l'esecuzione di query anche solo sulla colonna del contenuto del registro è costosa. Con i registri, di solito ci si preoccupa solo di momenti specifici nel tempo, che è esattamente ciò con cui aiuta il decoratore del tempo.

Risultati della ricerca

Ogni volta che esegui una query, crea una nuova tabella e talvolta crea tabelle nascoste sconosciute dietro le quinte. Se lo desideri, puoi dare alla tabella dei risultati un nome per mantenerla, o lasciarla rimanere con il nome che Google gli ha dato e lasciarla scomparire dopo un giorno. Se mai ti imbatti in una "risposta troppo grande per essere restituita" è perché ti stanno proteggendo da te stesso. È facile creare tabelle enormi (soprattutto con giunzioni incrociate). Se ciò accade e ti aspettavi che accadesse, devi nominare la tabella e abilitare l'opzione "Consenti risultati di grandi dimensioni". Se ripeti una query a cui non sono state trasmesse nuove righe, otterrai solo i risultati memorizzati nella cache se sono ancora in circolazione.