înregistrare Logare
Puncte:0
avatar Server

Avem nevoie de ajutor pentru a decide cel mai bun motor de stocare MariaDB pentru cazul nostru de utilizare și limitările hardware ale serverului

drapel cn
Henrique Miranda

Lucrez pentru o companie mică și avem nevoie de un depozit de date.

Baza noastră de date de producție are aproximativ 50 GB de date (crește cu ~10 GB/an, în prezent), serverul nostru rulează puțin peste capacitatea sa și credem că am putea muta unele date istorice într-un depozit de date (aproximativ jumătate din acești 50 GB pot fi mutați ) astfel încât să poată rula din nou fără probleme.

Desigur, depozitul de date ar avea toate datele ETL-uri, nu doar datele istorice. În acest fel, putem prelua și acele rapoarte costisitoare și date din tablouri de bord din DW în loc de serverul de producție.

Intenționez să ETL datele în DW și să le stochez folosind o schemă de fulgi de zăpadă, iar apoi intenționez să creez niște magazine de date pentru raportare și BI. Aceste magazine de date ar fi create folosind scheme stea, pentru a face lucrurile mai simplu (mai rapid?) de interogat.

Suntem înclinați să folosim MariaDB pentru asta, ceea ce mă aduce la întrebarea mea principală și anume care motor de stocare se aplică cel mai bine cazului nostru, innoDB sau ColumnStore.Și cât de mult ar afecta această decizie asupra dimensionării serverului pe care va rula.

Bănuiala mea, din ceea ce am citit până acum, este că ColumnStore poate fi mai rapid și mai adecvat pentru cazul nostru de utilizare, dar ar avea nevoie și de hardware mai bun. În acest moment, nu ne putem permite mai mult de un singur server cu 4 nuclee CPU și 32 Gb de RAM (afacerea noastră a fost grav afectată de pandemia globală. Ne revenim, dar nu suntem încă acolo).

Deci, având în vedere specificațiile serverului de mai sus și cazul de utilizare, ați recomanda în continuare utilizarea ColumnStore peste innoDB? Suntem chiar deschiși și către alte soluții decât MariaDB.

67
0 + 0
djdomi avatar
drapel za
djdomi
Răspunde asta la întrebarea ta? [Mă puteți ajuta cu planificarea capacității mele?](https://serverfault.com/questions/384686/can-you-help-me-with-my-capacity-planning)
1
Răspunde
drapel cn
Henrique Miranda
Cred că întrebarea mea este mai specifică decât doar dimensionarea unui server. Am un buget limitat și aș dori să știu ce soluție de bază de date ar funcționa mai bine.
0
Răspunde
Puncte:2
avatar Server
drapel ua
Rick James

Motor: InnoDB. Perioadă. (Sigur, 1% din cazurile de utilizare sunt mai bine cu altceva, dar al tău nu pare să indice necesitatea unui alt motor.)

Fulg de zăpadă: Teribil, mai ales dacă trebuie să cauți pe o „gamă”. Vă rugăm să furnizați schema (de preferință prin AFIȚI CREATE TABLE); Voi fi mai specific. (Atunci s-ar putea să fiu de acord că Fulgul de zăpadă este bun, dar mă îndoiesc.)

Schema stelelor -- Bine. Normalizarea șirurilor comune: bine. Normalizarea valorilor „continue” (date, int, floats): rău. Dar scopul este de a economisi spațiu pe disc, prin urmare accelerarea unor interogări.

10 GB/an - asta sună ca „câteva” rânduri pe secundă în medie. Greu, dar nu îngrozitor de greu. Adică, procesarea ETL nu pare că aveți nevoie de ajutor.

Depozitarea datelor -- http://mysql.rjweb.org/doc.php/datawarehouse

Eliminați datele vechi -- Aceasta este una dintre puținele utilizări pentru PARTIZARE. http://mysql.rjweb.org/doc.php/partitionmaint

Împărțirea în tabele separate care sunt păstrate online -- probabil să fie o bătaie de cap, dar cu foarte puține beneficii.

Rapoarte costisitoare --> Tabele rezumative http://mysql.rjweb.org/doc.php/summarytables Tabelele rezumative sunt mult mai mici decât un tabel de fapte; este chiar acceptabil să se denormalizeze.

Columnstore -- Un mare plus este compresia semnificativă pe care o oferă. Dar nu văd 50 GB ca fiind foarte mari. Un alt avantaj al CS este „indexarea” automată a fiecărei coloane. Cu toate acestea, doar o coloană poate fi utilizată pentru eficiența pe două niveluri a căutării.

4 nuclee -- destule pentru InnoDB; mai multe nuclee ar fi utile pentru CS.

32 GB RAM -- Cu doar 50 GB de date și 10 GB/an -- Dacă tot ce faci este să te uiți la datele ultimului an, 32 GB sunt mai mult decât suficienti. Dacă scanați frecvent toți cei 50 GB, atunci vor fi multe I/O. Dacă implementați tabelele rezumative, atunci 32 GB este exagerat pentru majoritatea activităților. (Tabelele rezumative pot fi sub 10 GB și pot reveni la începutul datelor; prin urmare, foarte ușor de stocat în cache.)

32 GB + CS -- 50 GB vor deveni aproximativ 5 GB. (Dar nu știu dacă cei 32 vor fi exagerați.)

HDD vs.SSD -- SSD-ul este vizibil mai rapid.

Concluzie (și buget) -- Tehnicile menționate mai sus pot menține InnoDB pe 32 GB fredonând bine timp de câțiva ani.

0 + 0
drapel cn
Henrique Miranda
Multumesc pentru comentarii. Înțeleg mai bine ce trebuie să fac acum. Cât despre nu folosiți schema de fulgi de zăpadă, ce ați sugera în schimb? Scopul meu este ca DW să conțină totul din bazele noastre de date de producție și apoi, din el, aș extrage câteva tabele de fapte și dimensiuni (de asemenea, tabele rezumative) pentru raportare și BI.
0
Răspunde
drapel ua
Rick James
@HenriqueMiranda - re Snowflake: Arată-mi un exemplu specific, ca să pot da câteva comentarii specifice. Unul care îmi vine în minte este `Fact` -> `Adress` -> `City` -> `Country`; atunci căutarea rândurilor `Fact` pentru un anumit `country_id` este cu adevărat dezordonată și lentă.
0
Răspunde
drapel cn
Henrique Miranda
Sunt de acord, dar acele date nu vor fi interogate foarte des. Cele mai multe interogări s-ar întâmpla pe magazinele de date care folosesc scheme stea.
0
Răspunde
drapel ua
Rick James
@HenriqueMiranda - OK.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.