Cum stochează Google tabelele mari de interogări și cum vă afectează

Aceasta este o instalare de discuții tehnice a blogului nostru, oferită de un dezvoltator extraordinar, Adam Knox.

Deși Big Query folosește o sintaxă foarte asemănătoare cu SQL, este nevoie de un tact semnificativ diferit față de o soluție pentru procesarea unor cantități mari de date. Big Query are tendința de a forța brută și nu folosește de fapt indici, așa că o mulțime de date înseamnă o mulțime de procesoare și timp de procesare. Pentru a realiza acest lucru, Google a optat pentru o modalitate diferită de stocare a datelor, care poate afecta modul în care vă proiectați interogările.

Tipul fisierului

Când este creat un tabel, Google folosește formatul ColumnIO pentru a vă stoca datele. Fiecare coloană este stocată ca fișier separat, cu excepția câmpurilor repetate. Dacă aveți un tabel cu coloanele: nume (șir), numere de telefon (întreg repetat); numele va fi stocat pe o singură linie cu celelalte nume și toate numerele de telefon asociate cu acel nume vor fi stocate pe o singură linie cu numerele de telefon. De asemenea, coloanele pot fi împărțite dacă devin prea mari, dar asta nu va avea impact asupra fluxului de lucru.

Cunoașterea acestui lucru oferă posibilitatea de a rula interogări mai rapid prin neprocesarea coloanelor de care nu vă pasă și, în unele cazuri, face posibilă, anterior, executarea interogărilor. Interogările pot deveni, de asemenea, mai ieftine, deoarece sistemul taxează în funcție de cantitatea de date procesate, iar dacă o coloană nu este inclusă în interogare, atunci datele respective nu sunt procesate.

Stocarea fișierelor

Dacă ați creat un tabel, vă puteți simți în siguranță că nu va merge nicăieri, deoarece odată ce fișierele dvs. sunt create, acestea sunt stocate în trei centre de date diferite și chiar în trei locuri diferite în fiecare centru de date. Deoarece Big Query pune procesoarelor probleme, datele trebuie să fie ușor accesibile. Avertisment la aceasta este seturile de date temporare. Există o opțiune de a specifica un timp de expirare pentru tabelele dintr-un set de date, iar tabelele vor dispărea odată ce sunt mai vechi decât această dată de expirare.

Ierarhia tabelului

Un proiect are capacitatea de a stoca seturi de date, care pot conține fiecare tabele. Comanda completă pentru accesarea unui tabel în sintaxa Big Query este [projectname:datasetname.tablename] , dar aceasta poate fi scurtată la dataset.tablename dacă accesați tabelul din proiectul în care lucrați în prezent.

Împărțirea datelor asociate în tabele separate (de exemplu: după dată sau după un anumit eveniment) poate fi benefică pentru a face interogări mai ușor de întreținut, deoarece interogările rulează în general pe toate rândurile dintr-un tabel. Aceasta înseamnă că poate doriți să priviți mai multe tabele, așa că există ceva numit meta-tabel ascuns în fiecare set de date care este accesibil la [projectname:datasetname.__TABLES__] și conține informații despre fiecare tabel din setul de date și poate fi folosit pentru agregarea tabelelor pentru interogarea.

Comanda TABLE_QUERY este o comandă care permite ca mai multe tabele similare să fie agregate înainte de a rula o interogare pe agregat, iar orice coloană din __TABLES__ poate fi utilizată pentru a forma acest agregat. De exemplu, dacă vreau o idee despre timpii de răspuns începând cu 1 ianuarie 2016 pentru un proiect, aș putea rula următoarea interogare care arată timpii de răspuns minim, median și maxim:

 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"))

Deoarece sunt folosite doar două coloane care conțin numere întregi fiecare, aceasta este încă o interogare relativ ieftină (0,0003 USD), chiar dacă accesează 28+, despre care mi se spune că are 1,857 TB prin interogarea de mai jos și ar costa aproximativ 9 USD pentru a accesa fiecare câmp de la .

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

Actualizarea fișierelor

Big Query este grozav când vine vorba de înregistrarea modificărilor și analiza acestor modificări, deoarece puteți transmite în flux noi rânduri într-un tabel. Este, totuși, un dispozitiv groaznic de stocare a datelor pentru căutări rapide și frecvente ale anumitor rânduri din cauza lipsei de indici și, de asemenea, nu este grozav pentru stocarea reprezentărilor singulare ale obiectelor pe care vă așteptați să le schimbați, deoarece rândurile dintr-un tabel nu pot fi modificate sau eliminate. .

Tabele de împărțire

În unele situații, chiar și accesarea unei singure coloane este prea mult de rezolvat în Big Query. Vă prezint următoarea interogare inutilizabilă care returnează ID-uri de listă în ordinea datei de creare a listării:

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

Din punct de vedere tehnic, recent a devenit posibil ca acest lucru să reușească, dar nu pentru oamenii de la Vendasta, deoarece necesită activarea unui nivel de facturare mai ridicat. Deoarece nu există indici precomandati, procesează o cantitate mică de date foarte intens, astfel încât în ​​acest caz taxează pentru procesare. Modificarea nivelului de facturare se poate face în interogări interactive din interfața de utilizare Big Query, bifând „permiteți nelimitat” (dacă este activat) sub butonul „opțiuni”.

Presupunând că interogarea dvs. este cât se poate de eficientă, mai sunt câteva abordări pentru a reduce dimensiunile tabelelor pentru a ocoli aceste tipuri de limite stricte. Primul este decoratorii de masă, iar al doilea este cu hash.

Puteți afla mai multe despre decoratorii de masă aici. Spre deosebire de filtrarea rezultatelor folosind comenzi precum LIMIT/WHERE/HAVING/OMIT , decoratorii de tabel vor scădea efectiv costul interogării unui tabel, deoarece nici măcar nu va accesa datele în afara intervalului dat. Din nefericire, această metodă este aproape inutilă la Vendasta, deoarece chiar și pentru tabele precum ListingHistoryModel la care de fapt transmitem în flux, încă scăpăm întregul tabel și îl înlocuim în fiecare zi cu o replică dacă este de la NDB, ceea ce înseamnă că decoratorii pentru timpul mesei vor lucra numai pe ListingHistoryModel dacă vă pasă doar de intrările din ziua curentă.

Privind la logare este singurul loc în care pot fi de mare ajutor la Vendasta. Datorită dimensiunii conținutului efectiv al jurnalului, limitele de calcul și de memorie sunt ușor de atins, iar interogarea chiar și numai a coloanei de jurnal este costisitoare. Cu buștenii, de obicei, cineva îi pasă doar de anumite momente în timp, care este exact ceea ce ajută decoratorul de timp.

Rezultatele interogării

De fiecare dată când rulați o interogare, aceasta creează un tabel nou și uneori creează tabele ascunse necunoscute în culise. Dacă alegeți așa, puteți da tabelului de rezultate un nume pentru a-l păstra sau îl puteți lăsa cu numele pe care i l-a dat Google și îl lăsați să dispară după o zi. Dacă te întâlnești vreodată cu un „Răspuns prea mare pentru a reveni” este pentru că te protejează de tine. Este ușor să creezi mese enorme (în special cu îmbinări încrucișate). Dacă se întâmplă acest lucru și te așteptai să se întâmple, trebuie să denumești tabelul și să activezi opțiunea „Permite rezultate mari”. Dacă repeți o interogare care nu are rânduri noi transmise în flux la ea, atunci vei primi doar rezultatele stocate în cache dacă acestea sunt încă prin preajmă.