Databáze - 300 GB tabulka

[PanVP]

Zdravím,

mám vedlejší úkol, se kterým nechci zabít enormně mnoho času a už vůbec kvůli tomu nechci pořizovat komerční software. Mám několik tabulek (několik sloupců, žádné provázání), jenže každá taková tabulka má od desítek do stovek GB.

MariaSQL si s tím neví rady, tabulky nad desítky GB jí spolehlivě zabijí.
Třeba insert pár set tisíc položek jí umrtví i na poměrně rychlém stroji se spoustou paměti.
PGSQL na tom prý není o moc lépe, ale už jsem jí déle neměl v ruce.
MSSQL mi nestačí z hlediska limitu free verze, to stejné asi platí pro Oracle.

Nechce se mi pouštět se do psaní vlastního toolu.

Co s tím?   

Vím, že se v poslední době objevilo víc databází, ale přiznám se, že kromě MongoDB žádné neznám a ani jejich schopnosti. PS: Hodil by se konektor pro C#.

https://bitnine.net/blog-useful-information/top-10-open-source-big-data-databases/

[Reklama]

[Mlocik97]

300GB tabuľka? To ako robíš BigData v SQL?

[alex6bbc]

a musi to byt db? jsou to binarni data, ze to je tak velke, jestli neni lepsi normalni filesystem.
a v db ukladat jen metadata pro hledani.

[PanVP]

300GB tabuľka? To ako robíš BigData v SQL?

Tak nechce se mi pro to psát vlastní B-Tree...nerad znovu dělám něco, co už někdo udělal.
Navíc, asi bych se svým Bstromem skončil zhruba na podobném místě jako ta MariaDB, kdy by se to nevešlo do paměti.
MariaDB není nejlepší DB, ale určitě jí nedělali hlupáci.
A tohle není core mojí práce, toho co dělám, vlastně to chci "nějak" udělat a zbavit se toho.
Ale lámu si s tím hlavu a nevím, jak na to.

jestli neni lepsi normalni filesystem.

Jenže řádky jsou vesměs "krátké", maximálně okolo sto bajtů.
Obávám se, že FS by pro tohle nebyl vhodnou databází.
Popravdě nevím, jak to uchopit.

[Jose D]

PGSQL

nooo, na jedný infrastrukture kterou provozuju velkou posgres DB mam, par tabulek, kazda tak do 1TB, co radek, tak timestamp a nejaky double hodnoty.

Neni to nic na cem je mozny delat neco jako interaktivni praci, zejmena na spatny dotazy odpoved trva. Proste az se dotaz sjede, tak se sjede. Ale nikomu se nechtelo psat a skolit novy spolehlivy DBMS, takze tohle bylo to nejmin blby reseni ktery bylo. jedno z tech min spatnych reseni.

[Reklama]

[z_sk]

Ako ukladas DB, kazda tabulka zvlast ukladana v DB, alebo vsetko ako jeden subor?

[Jose D]

Ako ukladas DB, kazda tabulka zvlast ukladana v DB, alebo vsetko ako jeden subor?

no soubory se stejně by default od urcity velikosti splituji - jestli se tedy bavime o pgsql.

[PanVP]

provozuju velkou posgres DB mam

Zajímavé! Nějaká živost mě netrápí, ale prvotní zpracování statisíců záznamů je na DB prostě záhul.
Nevadí mi, že bych databázi na pět minut umrtvil a pak zase.
Po měsíci data vyexportuji a mám na rok hotovo.

Jinak jsem s PGSQL pracoval, používal jsem dávkové importy, ale taky to pak začalo padat na ústa.
Možná jsem dost neoptimalizoval...
Vlastně jediná DB, která s tím tak nějak hýbala, byl Oracle, ale....cena...no...

Na druhou stranu, kdybych to dokázal zrychlit, třeba by z toho mohlo být něco užitečného...hmmm...
Ale spíš se toho rychle zbavit.

Ako ukladas DB, kazda tabulka zvlast ukladana v DB, alebo vsetko ako jeden subor?

Žádnou extra optimalizaci jsem nezkoušel, když MariaDB začala klekat okolo desítek GB.
Jinak innodb_file_per_table=ON je tuším defaultní hodnota a tu jsem určitě neměnil.
Nebo myslíš jiný parametr.

PS: Zase se mi předchozí odpověď smazala...kua...

[Jakub Štech]

Co za druh dat to je? Mám postgres (víceméně "tovární" nastavení, akorát shared_buffers nastavena na adekvátní hodnotu, default je jak z 90. let), v tom mám circa 200G cenových dat několika kryptoměn (int timestamp, int pair, float price, float volume). Dělají se nad tím selecty delších souvislých bloků (např. 1 měsíc) a běhá to svižně na 8jádrovém stroji s 8 GB RAM. Import/export (psql/pg_dump) trvá pár hodin, nic co by se nedalo přežít.

Původně jsme to měli na Influxu, ale ten je dost otřesnej jak z něj chcete dostat víc dat než pár set pointů do grafíčku v Grafaně - má pouze HTTP API, takže všechny ty miliardy čísel se konvertují na plaintext a v klientovi zase zpátky z textu na float. Postgres s tím pracuje bez toho kroku a ani s těmito objemy nemá problémy.

[Filip Jirsák]

Takže když to shrnu, sloupců v tabulkách je málo, objem dat v řádku je malý (takže to nejsou žádné velké bloby), takže ty tabulky mají spousty řádků.

A teď – co vlastně řešíte za problém? Psal jste o insertu většího množství řádků. To řešíte úvodní nalití dat? Nebo se tam takové množství dat má ukládat i za běhu? Má se z té databáze něco číst? Jsou tam nějaké indexy? Jsou ty tabulky rozdělené na partitions? Ten insert pár set tisíc položek – to jste zkoušel v jedné transakci, nebo rozdělené do více transakcí? Pokud jsou tam indexy, zkoušel jste je před nalitím dat vypnout a po nalití opět zapnout?

[PanVP]

• To řešíte úvodní nalití dat? -- Ne, hlavní tabulka má ~300 GB, ale tu to nedá naráz
• Nebo se tam takové množství dat má ukládat i za běhu? -- Dávky jsou řádově 5-50 GB
• Má se z té databáze něco číst? -- Po zpracování (jednou týdně)
• Jsou tam nějaké indexy? -- jen PK
• Jsou ty tabulky rozdělené na partitions? -- Ne
• Ten insert pár set tisíc položek – to jste zkoušel v jedné transakci, nebo rozdělené do více transakcí? -- Zkoušel jsem DB plnit prvními desítkami GB
• Pokud jsou tam indexy, zkoušel jste je před nalitím dat vypnout a po nalití opět zapnout? --...to jsem mohl co?
  

Dovolil jsem si to doplnit dovnitř.
Tabulka má primární klíč a pokud se nepletu, nad PK se vytváří index vždy automaticky.
Ale před bulk insertem jsem ho nevypínal...já měl za to, že ho bulk insert vypíná automaticky.

[linuxak]

Na takové úlohy mám dobrou zkušenost s LMDB, je to okleštěná databáze, v podstatě jen b-tree, ale killer feature je, že to funguje nad mmapovaným souborem, stovky GB dat to zvládá docela dobře: http://www.lmdb.tech/doc/

[Filip Jirsák]

Tabulka má primární klíč a pokud se nepletu, nad PK se vytváří index vždy automaticky.
Ale před bulk insertem jsem ho nevypínal...já měl za to, že ho bulk insert vypíná automaticky.

Zkusil bych se zamyslet, zda nejde tabulky rozdělit na partitions (tak, aby se na stará data už nemuselo sahat). Vyzkoušel bych, zda není lepší insert rozdělit do více transakcí (těžko se to odhaduje, může to být lepší, může to být horší). A samozřejmě při tom insertu vypnout indexy.

[PanVP]

zda nejde tabulky rozdělit na partitions (tak, aby se na stará data už nemuselo sahat)

Problém je, že import obsahuje až 60-90% už existujících dat.
Tj. bulk import v podstatě vytváří pro každý insert nejprve select, jestli je možné řádek vložit.
Do nějakých větších akcí s optimalizacemi jsem se nepouštěl, protože mi to zdechalo už okolo desítek GB importu.
Ale třeba to dělám vážně špatně, osobně se rozhodně nepovažuji za specialistu na databáze.

Možná bych měl nejprve menší tabulku naimportovat do nějaké "pracovní tabulky", možná memorytable (?), pak vyhodit všechny duplicity a pak provést insert do hlavní tabulky...hm(?)....?

Když mi někdo napíše "hele, asi to děláš blbě, zkus to znovu a lépe", tak je to taky nějaký progres.

mám dobrou zkušenost s LMDB, je to okleštěná databáze, v podstatě jen b-tree

Velmi děkuji, podívám se!

[ByCzech]

Žádnou extra optimalizaci jsem nezkoušel, když MariaDB začala klekat okolo desítek GB.
Jinak innodb_file_per_table=ON je tuším defaultní hodnota a tu jsem určitě neměnil.

Musí to být v InnoDB? Co takhle zkusit jiný storage engine?