Fórum Root.cz
Hlavní témata => Server => Téma založeno: PanVP 13. 03. 2021, 19:00:34
-
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? :o ???
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/ (https://bitnine.net/blog-useful-information/top-10-open-source-big-data-databases/)
-
300GB tabuľka? To ako robíš BigData v SQL?
-
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.
-
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.
-
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.
-
Ako ukladas DB, kazda tabulka zvlast ukladana v DB, alebo vsetko ako jeden subor?
-
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.
-
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...
-
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.
-
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?
-
- 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.
-
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/
-
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.
-
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!
-
Žá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?
-
@Krčmář: Mohl bys to rozbité fórum spravit. Člověk si nedá pozor a odhlásí ho to...
Pokud jsou tam indexy, zkoušel jste je před nalitím dat vypnout a po nalití opět zapnout?
Tak jsem si to myslel správně:
Note: When you insert into an empty table with INSERT or LOAD DATA, MariaDB automatically does an DISABLE KEYS before and an ENABLE KEYS afterwards.
A třeba to dělám úplně špatně:
Nejprve provedu:
SET @@session.unique_checks = 0;
SET @@session.foreign_key_checks = 0;
SET @@global.innodb_autoinc_lock_mode = 2;
A samozřejmě import obalím:
SET autocommit=0;
... SQL import statements ...
COMMIT;
A pak:
LOAD DATA LOCAL INFILE 'file_name' INTO TABLE table_name;
Čímž jsem skončil, protože zhruba ve chvíli, kdy se tabulka nevejde do paměti, tak to lehne...
Nejsem odborník na databáze, takže netvrdím, že to "JE" chyba na straně MáňaDB.
Když se někdo jebne kladivem do ruky, není to chyba kladiva.
Ale ...co udělat líp??
-
Zdravim, pouzivame PostgreSQL na archivaciu hodnot procesnych dat (cize v podstate nieco ako casove rady).
Nastavenych je iba par parametrov tykajucich sa pamate.
Jedna z velkych aplikacii: data su archivovane s definovanou hlbkou archivacie (per objekt), ale zaroven sa ukladaju aj data, ktore sa nemazu - mesacne "casove rezy", v ramci mesiaca vznika u tohto zakaznika nie 1 ale 5 tabuliek v 5 databazach (ale to je technikalita). V maji 2018 vzniklo v tych 5 tabulkach 135 GB dat, vid blog
https://www.ipesoft.com/sk/blog/archiv-a-postgresql-trezory
Tabulky maju par stlpcov (ID objektu, hodnota, nejake priznaky, casova znacka).
Momentalne tam je cca 14 TB dat (od r. 2006). Citanie je vzdy s vyuzitim indexu (ID konkr. procesnej veliciny + cas). Standardne disky, ziadne SSD (aj ked aj to sa chysta pri najblizsej migracii na nove zelezo).
Tieto data boli povodne v Oracle databaze, v 2017-2018 premigrovane do PostgreSQL, odvtedy to bezi tam.
(https://www.ipesoft.com/sk/blog/migracia-trezorov-na-postgresql-v-praxi)
V podstate bez problemov a bezudrzbovo.
Takze: zapis prebieha stale 24/7/365. Citanie na ziadost uzivatelov (obcas si stazuju, ale v zasade je to interaktivne..).
-
Děkuju!
Přesně to jsem potřeboval!
-
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(?)....????
Přesně tak. Neimportujte všechna data do pomocné tabulky a teprve pak odstraňujte duplicity. 300 GB asi do memory tabulky nedostanete, ale to nevadí.
Nejsem odborník na databáze, takže netvrdím, že to "JE" chyba na straně MáňaDB.
Když se někdo jebne kladivem do ruky, není to chyba kladiva.
Ale ...co udělat líp??
Myslel jsem, že se bavíme o PostgreSQL. Do MariaDB/MySQL bych se takový objem dat nepokoušel nacpat. Asi to jde, používá se i na velkých projektech, ale pak to asi znamená, že to spravuje někdo, kdo se v MariaDB/MySQL fakt vyzná.
-
problém bych neřekl, že je v použité databázi, ale ve způsobu jak s ní pracuješ, jak s mariadb, tak i pgsql je možné mít tabulky i k TB, ale už to chce odejít z výchozího nastavení.
Pg umí od 9.x insert on conflict do nothing, stejně tak mariadb umí insert on duplicate key. V kombinaci s prepared statements a bulkem pro třeba 5000 values, zvedneš rychlost ukládání dat do db o dva řády (tj. cca 20000 insertů za vteřinu na jediné instanci při 10 paralelních dotazech a ve výchozím nastavení). Pg umí i dobře komprinovat data, takže ti ušetří místo na disku. Na webu najdeš řadu kalkulaček pro nastavení db podle množství dat a druhu práce.
Zkus ClickHouse, tenhle úkol by mohl zvládat ve výchozím nastavení a poměrně rychle, má pokročilé metody komprese dat a můžeš ušetřit i 80 % původní velikosti.
Pokud nepotřebuješ přímo databázi, mrkni třeba na formát dat Apache Parquet, dostupný je z řady programovacích jazyků, data umí velice efektivně deduplikovat, komprimovat. Rychle s tím lze pracovat třeba přes spark (python, scala, r), za pár desítek minut na středně silném stroji to máš uložené a zpracované.
Další možnost je jít do cloudu, pronajmout si na pár desítek minut nějakou databázi, tam data zpracovat a pak si je stáhnout zpracovaný a deduplikovaný, pokud teda to chceš jednorázově.
-
proc se asi btrfs takto jmenuje, protoze ma b-tree index.
takze proc by neslo pouzit fs a metadata v db.
vidim chybu v navrhu.
-
Myslel jsem, že se bavíme o PostgreSQL. Do MariaDB/MySQL bych se takový objem dat nepokoušel nacpat.
Tak to jsem pochopil opačně, jako že mám dát MariaDB ještě šanci ;D
Totiž, mně by MariaDB vlastně vyhovovala, skutečně jí znám.
Ale už jsem na ní provařil dost času, tak to zkusím s PGSQL.
Budu na to myslet, díky.
-
Takže co s tím, ať se to trochu hejbe?
A)Projít optimalizace PGSQL pro bulk importy
https://www.2ndquadrant.com/en/blog/7-best-practice-tips-for-postgresql-bulk-data-loading/
B)Základní "mega" tabulku naprdět do PGSQL přes COPY nebo dbcrossbar
http://www.dbcrossbar.org/
C) Vytvořit RAMDISK (30 GB pro začátek)
https://www.linuxbabe.com/command-line/create-ramdisk-linux
https://www.techrepublic.com/article/how-to-use-a-ramdisk-on-linux/
(S tím jsem se už kdysi drbal a musel jsem kvůli tomu sestavovat jádro, protože tam byl nějaký limit na 4MB nebo co. Snad už to teď nebude potřeba.)
D) Vytvořit TABLESPACE přes nově vytvořený RAMDISK
https://www.postgresql.org/docs/9.1/manage-ag-tablespaces.html
E) Založit uvnitř tabulku s parametrem UNLOGGED
https://www.postgresql.org/docs/9.1/sql-createtable.html#AEN67445
F) Do UNLOGGED tabulky nacpat import (jeho část rozšiřuje hlavní tabulku).
G) Promazat tuhle pracovní tabulku, což zmenší počet záznamů na 10 až 40% původní velikosti
H) Exportovat jí nebo se jí pokusit rovnou dostat do hlavní tabulky.
Fakticky bych asi dokázal data spojit i na disku.
I) Dropnout pracovní tabulku a pokračovat další dávkou.
Zapomněl jsem na něco, co by mohlo mít zásadní vliv na rychlost zpracování?
BTW...vyčlenil jsem si na to 4H...jako že "to dám"...chudák já... ::)
-
Já bych se pro začátek vykašlal na ten RAM disk. Připadá mi to jako předčasná optimalizace. Teprve kdybyste viděl, že to pořád drhne, dává smysl se jím zabývat.
-
@Fórum je hrozně rozjebaný....zase mi to smázlo post
vykašlal na ten RAM disk
Teda ne že bys neměl asi pravdu, ale když už mám teda řídit Černobyl, tak si chci zmáčknout všechna tlačítka ne ;D
Jinak právě kvůli těmto čarodějným praktikám přibyl "TEMPORARY TABLESPACE".
Jeho použití vypadá celkem bezpečně:
https://blog.dbi-services.com/about-temp_tablespaces-in-postgresql/ (https://blog.dbi-services.com/about-temp_tablespaces-in-postgresql/)
https://blog.dbi-services.com/can-i-put-my-temporary-tablespaces-on-a-ram-disk-with-postgresql/
A líbí se mi na tom i to, že by se nemusel vytvářet žádný historický hnůj...
-
@Fórum je hrozně rozjebaný....zase mi to smázlo post
Zdejší fórum běží na nějaké staré verzi SMF (http://www.simplemachines.org/). Nemyslím si, že by fórum někdo opravil, takže zbývá jen možnost naučit se s tím žít a nepsat příspěvky jako nepřihlášený uživatel.
Teda ne že bys neměl asi pravdu, ale když už mám teda řídit Černobyl, tak si chci zmáčknout všechna tlačítka ne ;D
OK :-)
Jinak právě kvůli těmto čarodějným praktikám přibyl "TEMPORARY TABLESPACE".
Jeho použití vypadá celkem bezpečně:
https://blog.dbi-services.com/about-temp_tablespaces-in-postgresql/ (https://blog.dbi-services.com/about-temp_tablespaces-in-postgresql/)
https://blog.dbi-services.com/can-i-put-my-temporary-tablespaces-on-a-ram-disk-with-postgresql/
A líbí se mi na tom i to, že by se nemusel vytvářet žádný historický hnůj...
PostgreSQL je dost schopná databáze, akorát člověk občas musí prolézat různá zákoutí, aby našel, co potřebuje. Ten objem dat, co potřebujete zpracovat, není nijak závratný – takže by mi přišlo divné, kdyby to PostgreSQL nezvládl.
-
Z relačních databází mám zkušenosti jen s Postgresem, ten by to dát měl (jak už psali jiní výše). Ale nestačila by nějaká KV databáze? Ty bývají rychlé a bez zádrhelů, když nejsou potřeba indexy. Chtělo by jich to ale vyzkoušet víc, třeba s Tokyem mám špatné zkušenosti ("korupce"), jiní hlásí to samé s LevelDB. KV databáze by také efektivně vyřešila problém s duplicitami.
-
K fóru: napsanou odpověď, když Vás to odlásí, jde dostat z konzole browseru.(Otevřete ji, jdete na záložku network, dáte reload...)Akorát pak chce ve výslednejch datech requestu vyházet HTML značky....
-
Nebo něco jako Form History addon Firefoxu.
-
Mno, uplne sice nechapu zadani, lec pokud je potreba pracovat s time-series daty, doporucil bych time-series databazi.
Konkretne v postgresu velice schopna extenze TimescaleDB, kdera podporuje i komprimaci
Jinak co se tyce mych zkusenosti s Postgresem, je nutno mit na mysli, ze je to databaze transakcni.
Mnoho podivnych brzd v Postgresu uz vyresilo nastrkani commitu, kde je vsude mozno logicky strcit.
-
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.
-
- 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í.
-
cassandra, pri 300 GB len zacina, 3 nody rf 3 cl quorum, 6T pohoda, na casove rady to je jak usite
-
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.
-
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.
-
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.
-
@OP:
mě ještě napadlo, nezkoušels Elasticsearch?
-
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.