Databáze - 300 GB tabulka

Re:Databáze - 300 GB tabulka
« Odpověď #30 kdy: 14. 03. 2021, 22:01:20 »
na takovehle akce pouzivam vetsinou SQLite.

No a pokud na to specham, tak se s uspechem necha pouzit napriklad Serverless SQL pool in Azure Synapse Analytics. Tomu se namapuji externi data (nemusi se do databaze nic importovat) a pusti se na tom ten dotaz. Pri cene asi 5$ za 1 TB to bude stat asi jako jedno pivo a je zpracovano za 10 minut.


Re:Databáze - 300 GB tabulka
« Odpověď #31 kdy: 14. 03. 2021, 22:09:39 »
  • MariaDB s InnoDB je na toto naprosto v pohodě, osobně bych použil ji.
  • Docela by mě zajímalo, co znamená "spousta paměti", alespoň 1/2 dat? Jestli míň, tak to může být docela problém.
  • Primární klíče se musí za každou cenu vejít do cache.
  • Nevisí to na storage? Plotna tohle nedá.
  • Pokud je dost paměti, tak si potuňte velikost buffer_poolu, max_dirty_pages (vysoké procento), nastavte si velký undo_log (řekněme alespoň 100GB), vypněte adaptive flushing, innodb_flush_log_at_trx_commit=2 (případně 0), innodb_adaptive_hash_index=OFF
  • Co transakce? Není to co zápis, to commit?
  • Věci jako velká tmp tabulka, ramdisk atp. nechte gynekologovi. To je tady totální plýtvání operační pamětí.

tralala5

Re:Databáze - 300 GB tabulka
« Odpověď #32 kdy: 14. 03. 2021, 23:06:23 »
cassandra, pri 300 GB len zacina, 3 nody rf 3 cl quorum, 6T pohoda, na casove rady to je jak usite
« Poslední změna: 14. 03. 2021, 23:11:41 od tralala5 »

Re:Databáze - 300 GB tabulka
« Odpověď #33 kdy: 15. 03. 2021, 10:21:36 »
Hoj, podobné tabulky jsem měl v firebirdu a celkem pohoda, dokonce i sqlite si vedla dobře akorát tenkrát neměla nějaké window funkce nebo co tak jsem to tak moc netunil. Ale očekával bych že to postgres také zvládne rozumně.

Zde jsou zpomalovače, víceméně v pořadí důležitosti a jak je obejít
  • Pomalost transakce/commit - ručně řídit transakce a dělat commit po x řádkách (já jsem měl dobré výsledky s 50tisíc řádek)
  • Vyloučení duplicitních položek - použít Merge nebo nějakou formu "Insert or ignore" která umí použít index. A samozřejmně mít na to správný index, kde se nemusí moc šahat na podkladová data. (bez tohoto se po pár desítkách tisíc zadýchá kterákoliv db)
  • Roundtrip k databázi - předem připravený prepared parametrized multi insert nebo stored procedura. Tj jedním execute vložit třeba 25 řádků
  • Aktualizace indexu - tady (někdy) pomůže temporary tabulka(pokud je pouze v ram) bez indexů do které se nejdříve naleje třeba 50tisíc řádek, a pak se jedním povelem vloží do Hlavní tabulky s indexem.
    Zkontrolovat že se temp tabulka vejde do paměti!!
    Ale třeba sqlite byla myslím rychlejší při vkládání napřímo.
  • Aktualizace indexu II - pokud je to možné tak zpracovávat data v pořadí v jakém do tabulky(indexu) patří. Např u mne to bylo si nejdříve seřadit soubory podle datumu(v názvu souboru) a pak je v tom pořadí zpracovávat a vkládat do databáze.
Případně potunit paměť pro indexy, ale moc bych to nepřeháněl.
Nějaký další fine-tununing byl tak desítka procent odhadem, ale juž je to dávno.

Re:Databáze - 300 GB tabulka
« Odpověď #34 kdy: 15. 03. 2021, 11:56:49 »
Já bych k těm předchozím komentářům znovu přidal zvážit rozdělení té hlavní tabulky na partitions. Pokud nově přidávaná data nejsou rozstrkaná rovnoměrně mezi všechna stávající data, ale jsou to třeba nějaká chronologická data a měnit se budou jen data „ke konci“, nemusí se pak přestavovat index celé velké tabulky, ale předělají se jen indexy nad pár oddíly. I kdyby byla data rovnoměrně rozesetá po celé tabulce, mohou partitions pomoci, pokud importní dávky rozsekáte tak, aby vždy zasáhly jen jednu nebo několik partitions. Ale tam už by to bylo ke zvážení, aby to zase nezpomalilo další zpracování dat.


Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Databáze - 300 GB tabulka
« Odpověď #35 kdy: 15. 03. 2021, 12:17:09 »
na takovehle akce pouzivam vetsinou SQLite.
Kdysi jsem se o něco podobného s SQLite pokoušel a dopadlo to neslavně. Asi jsem dělal něco hodně špatně.

To výše zmíněné rozsekání na "partitions" zní jako dobrý nápad.

Jose D

  • *****
  • 850
    • Zobrazit profil
Re:Databáze - 300 GB tabulka
« Odpověď #36 kdy: 15. 03. 2021, 13:40:59 »
@OP:

mě ještě napadlo, nezkoušels Elasticsearch?

M_D

  • ****
  • 319
    • Zobrazit profil
    • E-mail
Re:Databáze - 300 GB tabulka
« Odpověď #37 kdy: 15. 03. 2021, 22:07:29 »
Také mám 300GB+ tabulky v PostgreSQL a jde to. Pokud chápu tazatele, tak má data, co musí naimportovat hromadně 300GB, zpracovat, zahodit a za čas znovu.
Pak bych se zamysle nad tím Postgresem, možná včetně nadstavby TimescaleDB, mohlo by to být rozumně použitelné. Zazněl InfluxDB, tak mám zkušenost, že dávkový import velkého množství dat není žádný rychlík a co jsem se díval, tak podobě to vycházelo u dávkového masivního importu pro Cassandru. U Influxu také dotazy přes větší sady dat dost drhnou (jak to začne de/kompresovat) u toho TimescaleDB by to mohlo být průchodnější při potlačení komprese. Nebo použít navrhované partišny po nějakém časovém bloku, pokud nechci do toho PgSQL tahat TimescaleDB.
Určitě to dost ovlivní indexy, nevhodně složitý trvá pak jeho sestavneí a žere dost místa. U takovéto jendorázové operace by se mohl hodit hash index, sestavoval se rychleji a zabíral méně místa, než klasické btree (a zlomek třeba proti gist), ale nevím jak poslední verze PgSQL, dříve (do PgSQL10) nebyl spolehlivý z pohledu nutnosti reindexace po restartu DB, ale pokud celé zpracování proběhne během jednoho běhu DB a nepotřebuji vlastnosti, co hash index nemá (nepodporuju unique, vícesloupcový index, sorted index a možná ještě něco), tak by mohl pomoci s urychlením.
A pokud jde o časové řady a imporutji data, co jsou už relativně utříděné (což je urychlení vždy), tak i brin indexy pomohly.