Dotaz: Postgres uz nestaci?

[Superklokan]

Dobry den,

mam key value tabulku v postgresql 10. Su to len 2 stlpce s key varchar a value varchar. Celkovo je to viac ako 1TB dat a cca 4e9 zaznamov. Objem dat bude len narastat.

90% operacii predstavuju INSERTy. Selecty su velmi rychle koli btree primarnemu klucu.

Cele to bezi na PC s 16GB RAM a platnovym diskom.

Bottleck su samozrejme IOPS a klasicky disk. INSERT "on duplicate do nothing" 1e6 novych zaznamov trva aj viac ako 12 hodin.

Particie moc nepomohli, subjektivne by som povedal ze je to este horsie, koli tomu ze je tam overhead na routovanie novych riadkov do tej spravnej subtabulky.

Co dalej? Co mam na vyber? Co mam vyskusat? Mam zvolit inu databazu? Investovat do noveho HW budem moct az ked objem dat prekroci 3-4TB :(.

Dakujem za kazdu radu.

---

---

Odpovědi

[Käyttäjä 11133]

Možná si to pamatuju špatně, ale není potřeba B-tree index při insertu přepočítat? Nebylo by lepší použít Hash index, záleží jaké děláš SELECTy... Pokud vždy konkrétní ID taky by to nemělo vadit.

[EtDirloth]

hash index sa neda pouzit ako unique

[OldFrog {Ondra Nemecek}]

Asi by pomohlo, pokud byste poslal strukturu té tabulky a vzorová data. Pro některé případy má Postgres specializovaná úložiště (Time Series...). A jak už řekl předřečník, porovnal bych dobu insertu pro různé indexy. Ještě existuje možnost data někam odrotovávat, mít repliku apod. To už záleží na způsobu použití.

[jekub]

Co třeba před takovým masivním insertem index vypnout (pokud to pg nemumí tak zrušit) a po skončení reindexovat/znovu vytvořit? Asi to bude rychlejší. Otázka je, jestli musí být tabulka v průběhu insertu dostupná pro select.

[jekub]

aha, on duplicate do nothing. Tak nic. Nebo data vložit do dočasné tabulky, odstarnit případné duplicity a pak teprve insert s vypnutým indexem.

[Kit]

Nebyla by pro daný účel vhodnější nějaká jednodušší databáze, např. DB4?

[Superklokan]

Rozmyslal som nad RocksDB alebo BDB ale to su embeded (tusim aj DB4) co by vyzadovalo programovanie. na co nemam skills, radsej by som pouzival uz hotovy produkt, ktory vyrobili superborci a ja ho mozem zadarmo :) pouzivat.

[vlasta]

Ona je otazka, jak vypadaji ty inserty, jestli se nekde v php na vzdalenym stroji toci jednotlive inserty s autocommitem, tak to by nezachranil ani oracle...

Problem muze byt take s velikosti toho indexu, nevleze se do pameti a pridavani novych hodnot znamena, ze si musi porad neco odkladat na disk... Takze pridani ram by mohlo pomoci

[dustin]

Nejsem žádný znalec postgresu, ale taky mi na 1TB tabulku se 4mld řádků a tolika inserty přijde 16GB málo.

[lertimir]

Selecty su velmi rychle koli btree primarnemu klucu.

Cele to bezi na PC s 16GB RAM a platnovym diskom.

Bottleck su samozrejme IOPS a klasicky disk. INSERT "on duplicate do nothing" 1e6 novych zaznamov trva aj viac ako 12 hodin.

No takhle to dopadne, když databaze admin, nemá ani šajnu, co matematika za relační databází dělá a jaké operace jsou potřeba k jeho cíli. Jednak varchar jako key je dost příšerné, klíče mají být fixní délky, jinak indexy trpí. Za druhé pokud to není nějak sofistikovaněji vypnuté, tak popsaný postup má vlastnost. insert dělá pro každý záznam z nových záznamů "search index" tedy alespoň 1e6 iops, a pro vkládané záznamy (n < 1e6) jeden záznam do souboru a jeden do indexu tedy 2n (v nejhorším případě 3e6 IOPS). Za 12 hodin je 45 600 sekund tedy pro 3e6 je to 75 IOPS za sekundu a těch operací je pravděpodobně výrazně více, protože vyhledání v indexu pro 4e9 nebude na jednu IOPS. spíše na cca 5 při cca 100 větvích pro b-tree uzel

Pravděpodobně by pomohl následující postup. Vkládané záznamy vzít jako temporální tabulku ins1 Provést ins1 LEFT JOIN main-table do tabulky ins2. Vypnout index na main-table. Na ins2 provést select na záznamy které mají v části main-table hodnutu NULL (to jsou ty neduplicitní) a insertnout je do main-table. Zapnout index.

[Jindřich Makovička]

Z dokumentace Postgresu:

Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

[jekub]

Jednak varchar jako key je dost příšerné, klíče mají být fixní délky, jinak indexy trpí.

Tohle by mě zajímalo, můžete to nějak rozvést detailněji?

[EtDirloth]

Najvacsi rozdiel medzi varchar a integer je v PostgreSQL v tom, ze interne sa pouziva abstraktny typ Datum, ktory ma velkost pointera. Ak potrebujes prenasat hodnotu (typicky parameter funkcie) typu integer, moze sa do Datum nastavit priamo hodnota. Naproti tomu, varchar/text (ako aj ostatne typy dlhsie nez Datum) je potrebne prenasat odkazom na strukturu varlena, ktora pozostava z dlzky a hodnoty. Typ varchar/text ma tiez mozny overhead pri de/toastovani, porovnavanie dvoch hodnot tak moze byt radovo zlozitejsie nez porovnanie dvoch integerov, z ktorych kazdy sa bezne zmesti do jedineho registra. No a btree index je vlastne zoradenim hodnot - a na zoradenie je potrebne ich porovnanie. Vid skvele zhrnutie od Pavla.

Kazdopadne to nie je příšerné - je to len menej efektivne. Ak je to potrebne, tak to je potrebne a neda sa s tym nic robit. Ale to si uz musi povedat a zdovodnit ten, kto tu DB pozna. Expertne emocionalne vylevy tu budu vzdy - treba sa ich naucit filtrovat a ignorovat ;)

Hlavne by som pockal na doplnenie informacii od Superklokana - napr. ake su typicke hodnoty key, aku formu insertov pouziva, ako benchmarkoval bottleneck pri pouziti partitioningu a bez neho - ci mu to moze vyliezat z RAM na disk (napr. ma tam sorty pri insert-selectoch?), kolko klientov sa pripaja, ci sa klienti vzajomne nelockuju, ...

Bez nich ma napada vyskusat:

- skusit rozdelit inserty a paralelizovat ich podla rozdelenia do particii

- ak to povaha dat dovoli, skusit najprv naloadovat data do pomocnej tabulky (tu sa da experimentovat aj s atributmi unlogged, pripadne pouzitie tablespace v RAM-disku), eliminacia duplicit a bulkovy presun do cielovej key-value tabulky + truncate docasnej

- deffered unique constraint

[Kit]

Co takhle zkusit insert těch 1e6 záznamů strčit do jedné transakce, případně rozdělit třeba po 10k insertech?

[Käyttäjä 11133]

OMG každý kdo někdy dělal bulk data loady snad ví, že se to dělá v jedné transakci, proto jsem se na tohle ani neptal :D

[Superklokan]

Příloha:

• statistika_tabuliek.png (71462 bytů)

Tu je definicia tabulky, particie som zrusil a vratil sa k monolitickej tabulke, pretoze inserty boli este pomalsie.

CREATE UNLOGGED TABLE public.csvaddresses(
address character varying(34) COLLATE pg_catalog."default" NOT NULL,
private_key character varying(51) COLLATE pg_catalog."default",
CONSTRAINT csvaddresses_address_pk PRIMARY KEY (address) USING INDEX TABLESPACE crypto)
WITH (OIDS = FALSE) TABLESPACE crypto;

stlpec address moze mat dlzku 33 alebo 34 znakov

btree som zvolil lebo som si nebol isty ci hash index mozem pouzit v spojitosti s primarnym klucom, kedze chcem aby key/value boli unikatne.

tu su vzorove data - su to skutocne data, nie su obfuskovane, ani nijak upravene:

'176wsMBztSjpgSUJn3XY36gRT5gMRjPTu8','5KQ97zSKN3F368Yx91MmeXUezBiCziQS4gM6EaBr6Kb68u2Hxkt'
'1MyLinoP3PxWFuZVMrV4gFZixqqqK1qppJ','5JFSptsznKycpRxMhpDjysELbNvWsUNS3DZjJnqBA7pV7S5wbxU'
'1FrrVykiPsQTUNncJtfjKDBHRaKp2Tv1Bp','5KRBPVtAEctVcffBfJKNFAv4Ak8SYxfKHqA2mCuSuVExghzsgiU'
'14GeuhxLMdnQwLHKCtmiPiYiFxRUhANV5Z','5J5QbjmQZLRy5zkaWutn68z7CBsdvf7Gt46qPCk2PzeG9SEuAyz'
'1F8Z4N17FEgaokEpNUNUZuPmMAec8wSATj','5Kb6WQ5AzV7Rsv1XGBuTuh2w4vBkjP7d3vyGvQmVtyyq8JsUhGe'
'1BARTFB38UDZBymaKSDMftvCqMTV764nVE','5KXfrNqWm1NYGej2jDtVF73d3VWpSBuExbsrQwCS6QoGTnayzz7'
'1DMcSTmu7v6rhgVKQCuCaDTdH2vyvX5Pv1','5Jv5DLGBA3ip9XEabDxS8n6SgaZqEXQjoFvaDfDgVRjCto1RwqS'
'16yt1YqLuPqEn2vrAgwPqP5ZZhLhMdD3bC','5J8pkqkaX49cRYMM1o9Wb8fieSJgJWdbTw2jxvKYHeCGPY6L5K7'
'16om5EuYn2zbKqCznbK7g1ZZVSfEWu9ACg','5KY1bCQC1XEFW8Jus9fLnj7pvyGRm4speKDxwEEssCwjVwurVR2'
'1EYmvuVioUEV4AzaqAQRaikMnUYrCnr9yS','5JxojRJ29VXr38DFkKFLK96PdMneVjmhfm69gnMfd5w4BjZaEXt'
'18yfQtKAavtkEvrxSHZyYFgUnsZMTeufBq','5KaufvZ8uKnzancuChdLzVbGFcswJc66r7aLBxJbaNj7HDh81AE'
'15QoMdtZ73cgAkNMXCb4sk9qMrCXmaMJU3','5KKttwPpDguBo6gy6iPKDLiiwVtnTYiQv2NarxuFk5WCupVAoRi'
'1N664oBTfjCBbzPyN6r4iwndCVCvo8EkGx','5K4GjKeobmxdebY4CjcAnBHSrsox88TyGvKd5YW6Vp83avDNMUj'
'138xDo1VqcMJGJGpA5MRGBJSR8y8L66y2o','5KQKQduF8gNt9pbxxvX7bLq9AGGB9LoVGsAgJP8smtuPtEe9RU8'
'1EbpKC9uDRwaj9YEopBPSed9v8neS2thTo','5JqPNMM5XnpnFYRKis9GkpqFc9nRDSeB1HxFmAL3Kcy7wpjRUE9'

na strankach https://wiki.postgresql.org/wiki/Index_Maintenance som nasiel SQL prikaz na zobrazenie statistik "Index size/usage statistics". Screenshot prikladam do prilohy. Su tam vidiet aj docasne tabulky "*_tmp_*" do ktorych som importoval data z CSV suboru pomocou COPY, aby som sa vyhol importu dat do velkej "pomalej" tabulky.

data vkladam pomocou utility napisanej v C s vyzuitim kniznice libpq. nevyuzivam ziadne transacie iba cisto jeden prikaz - INSERT v cykle

paramValues[0] = (char *)crypto_address;
paramValues[1] = (char *)private_key;

PGresult *res = PQexecParams(
conn,										         /* connection string */
"INSERT INTO csvaddresses(address, private_key) VALUES($1, $2) ON CONFLICT DO NOTHING;", /* sql query */
2,										         /* number of parameters */
NULL,											 /* oid param type - default data type */
(const char * const *)paramValues,							 /* variable value */
NULL,											 /* length */
NULL,											 /* format */
0											 /* result format - text mode */
);

ako je vidiet na prilozenom screenshote indexy sa v ziadnom pripade nevojdu do pamate, index ma 233GB co je cca 50% velkosti tabulky.

tak isto som sa pohraval aj s myslienkov na nasadenie BDB/DB4, alebo RocksDB, ale nebol som si isty ci su vhodne na tento use case.

[Käyttäjä 11133]

Tak index se ti očividně nevleze do tabulky, rozhodně by to chtělo našetřit alespoň na 1TB SSD risk a dát indexy na ten; teďka má index 233GB, takže 1TB disk by ti vydržel do 2TB velikosti databáze zhruba...

BTW co to máš za softík ze kterého je ten screenshot, mohl by se mi hodit :) phpPgAdmin nepodporuje PgSQL 10+

[Käyttäjä 11133]

s/tabulky/paměti/

[Superklokan]

PgAdmin4 https://www.pgadmin.org

[Superklokan]

Tak index se ti očividně nevleze do tabulky, rozhodně by to chtělo našetřit alespoň na 1TB SSD risk a dát indexy na ten; teďka má index 233GB, takže 1TB disk by ti vydržel do 2TB velikosti databáze zhruba...

niekto uz robil benchmarky https://blog.2ndquadrant.com/tables-and-indexes-vs-hdd-and-ssd ked bol index na SSD pocet transakcii sa zvysil iba malo. najvaci narast vykonu (transakcii za sekundu) bolo v pripade tabulky na SSD.

[EtDirloth]

Zvladol by si previest hodnotu vkladanu do stlpca public.csvaddresses.address na 64b cislo? Ak ide o case-sensitive alfanumericke znaky, tak by malo ist len o 62 roznych hodnot [A-Za-z0-9] na textovu poziciu. To mi vychadza, ze 33 znakova address sa vojde do bigint s dvojbitovou rezervou... a tam by mohla byt uspora IO aj narast vykonu (ako pisem vyssie) signifikantny. Samozrejme, da sa ist dalej a podobne "komprimovat" aj hodnotu stlpca private_key (napr. pouzit bytea).

• Nepises, ako si vyuzil _tmp_ data z COPY - islo iba o inicialny import mimo utility v C? Mozno stoji za zmienku, ze file_fdw vie spristupnit CSV.
• Ak mas v tej utilite data na hromade, uspornejsi format INSERTU je VALUES (1,2), (3,4)... - ale neviem, co s tym vie spravit ta funkcia z libpq.
• Este lepsie by na tom mal byt prepared statement.
• Ak to predsa len nechas v textovom formate, zvazil by som skratenie hodnot v stlpci address (Aka je vlastne pravdepodobnost konfliktu dvoch roznych zaznamov?) a skusil by som sa viac pohrat so storage-parametrami stlpcov a indexov.

PS: ked budes googlit ten "kompresny" algoritmus, tak skus "base64" ;)

[.]

Jak jsi to počítal, nebo o jakém bigintu mluvíš?!

[Ovrscout]

data vkladam pomocou utility napisanej v C s vyzuitim kniznice libpq. nevyuzivam ziadne transacie iba cisto jeden prikaz - INSERT v cykle

Již to výše zmiňoval kit, ale protože to asi zapadlo, tj bez vaší reakce tak si dovolím víceméně zopakovat: Vyzkoušejte rozdělit vkládání do transkací (např 1k/10k/50k/100k insertů ) a změřte jak dlouho to trvá. pqlib sice neznám ale očekávám že bude mít defaultně autocommit, což znamená že se vynucuje "zapsání" dat a přepočítání indexů po každém insertu což zbytečně zpomaluje. Můžete i vyzkoušet jednu jedinou transakci(jak také zmiňuje kit), ale každopádně vyzkoušejte(a změřte) i transakce po částech, většinou je to rychlejší.

[Josef Kufner]

Vyzkoušejte rozdělit vkládání do transkací (např 1k/10k/50k/100k insertů)

S tímhle mám dobrou zkušenost na MySQL i SQLite. Při seskupení několika stovek insertů do transakcí se rychlost vkládání zvýšila i o několik řádů.

[cronin]

Smieme vedieť, čo sú to vlastne za údaje? Možno taubľka relačnej databázy nie je to správne úložisko pre ne.

Aké selecty sa robia nad dátami? Možno by išli organizovať inak.

[Superklokan]

Vzor dat som publikoval vyssie, jedna sa o BTC adresu(key) a privatny kluc(value)

Ano pochopili ste to spravne, jedna sa svojim sposobom o rainbow tabulku. :)

[EtDirloth]

hod sem potom update, alebo riesenie, pre ktore si sa rozhodol - urcite to bude zaujimat viacerych

[Ivan]

Pokud jde o takhle specialni pripad, tak je otazka jestli potrebujes tak genericky SW jako je SQL databaze podporujici transakce. SQL databaze poskytuji vysokou uroven ochrany dat, za kterou se ale plati vykonem.

[EtDirloth]

vsimni si ten keyword UNLOGGED v CREATE TABLE statement

[cronin]

Dobre, s tým sa už dá pracovať. Stále zostáva vedieť:

- Koľko rôznych aplikácií do tabuľky zapisuje?

- Koľko rôznych aplikácií z dabuľky číta?

- A hlavne: ako vyzerajú selecty?

[Superklokan]

v podstate je to one man show. iba jeden clovek zapisuje. zatial zbieram/generujem data do jednej velkej tabulky. SELECT je velmi rychly koli btree primarnemu klucu.

[Jendа]

Tak to ale nechceš relační databázi, ale nějaký key-value store nebo něco úplně custom.

[Superklokan]

Zo zaciatku pracujem s tym co ako-tak poznam. Akonahle bude tych dat viac budem rozmyslat nad distributed key-value storage. ale to este nie je take horuce :)

[Josef Kufner]

Koukni na ElasticSearch. Zkušenost s ním nemám – znám ho jen z vyprávění, ale co jsem slyšel, tak by to pro tebe mohlo být zajímavé. Prý si to s většími objemy dat (v řádů GB) poradilo nad očekávání rychle.

[Superklokan]

aj nad tym som uz uvazoval, ale prislo mi ze indexy zaberaju vela miesta na disku

[Superklokan]

Pocas benchmarkov som nasiel bottleneck - dovod preco sa pomaly zapisuje do velkej tabulky. Podelim sa s vysledkami a nakoniec zhodnotim kde bol problem.

Tak ako bolo navrhnute vyssie zvolil som 4 datasety o 1k, 10k, 50k, 100k zaznamoch a budem ich vkladat do najvacsej tabulky csvaddresses, kde je momentalne 4.23587e+09 riadkov.

1. Benchmark: "INSERT ON DUPLICATE DO NOTHING" v cykle pomocou utility (je napisana v C) vyuzivajucu libpq

1k zaznamov:
16s

10k zaznamov:
164s

50k zaznamov:
817s

100k zaznamov:
1621s

2. Benchmark: z predpripravenych docasnych tabuliek s 1k, 10k, 50k, 100k riadkov.

1k zaznamov:
INSERT INTO csvaddresses SELECT * FROM csvaddresses_tmp_1k ON CONFLICT DO NOTHING;
15s

10k zaznamov:
INSERT INTO csvaddresses SELECT * FROM csvaddresses_tmp_10k ON CONFLICT DO NOTHING;
129s

50k zaznamov:
INSERT INTO csvaddresses SELECT * FROM csvaddresses_tmp_50k ON CONFLICT DO NOTHING;
758s

100k zaznamov:
INSERT INTO csvaddresses SELECT * FROM csvaddresses_tmp_100k ON CONFLICT DO NOTHING;
6149s - neviem si vysvetlit tak vysoku hodnotu oproti ostatnym.

Ako vidno z benchmarkov, lepsi vykon sa dosiahne za pouzitia docasnych tabuliek csvaddresses_tmp_#k. Sice som netestoval vlozenie 1m riadkov, ale podla dosiahnutych vysledkov to urcite nebude viac ako niekolko hodin.

Uz teraz viem kde som spravil chybu (prisiel som na to pocas robenia benchmarkov) a tym velky bottleneck. Chcel som si velmi zdednodusit pracu a pouzival som len tieto 2 prikazy, skratka pouzival som pattern matching - LIKE '111%' aby som velmi jednoducho vedel zmazat z docasnej tabulky uz vlozene zaznamy do tej velkej.

INSERT INTO csvaddresses SELECT * FROM csvaddresses_tmp_6 ON CONFLICT DO NOTHING WHERE address LIKE '111%';
DELETE FROM csvaddresses_tmp_6 WHERE address LIKE '111%';

Teraz len tak cvicne som pustil prikaz na zratanie hodnot ktore vyhovuju '111%'. No po asi 90 minutach som ho zastavil. Takze teraz s istotou mozem povedat ze bottleneck bol LIKE

SELECT count(*) FROM csvaddresses_tmp_6 WHERE address LIKE '111%';

Riesenie:

Doplnit docasnu tabulku o stlpec id, pouzivat ho ako offset na presunutie dat do velkej tabulky a nasledne ich zmazanie.

DROP INDEX csvaddresses_tmp_6_address_idx;
ALTER TABLE csvaddresses_tmp_6 ADD COLUMN id bigserial PRIMARY KEY;

3. Benchmark: "INSERT INTO csvaddresses SELECT * FROM csvaddresses_tmp_6 WHERE id < ##### ON CONFLICT DO NOTHING;"

1k zaznamov:
INSERT INTO csvaddresses(address, private_key) SELECT address, private_key FROM csvaddresses_tmp_6 WHERE id <= 1000 ON CONFLICT DO NOTHING;
18s

10k zaznamov:
INSERT INTO csvaddresses(address, private_key) SELECT address, private_key FROM csvaddresses_tmp_6 WHERE id <= 10000 ON CONFLICT DO NOTHING;
134s

50k zaznamov:
INSERT INTO csvaddresses(address, private_key) SELECT address, private_key FROM csvaddresses_tmp_6 WHERE id <= 50000 ON CONFLICT DO NOTHING;
789s

100k zaznamov:
INSERT INTO csvaddresses(address, private_key) SELECT address, private_key FROM csvaddresses_tmp_6 WHERE id <= 100000 ON CONFLICT DO NOTHING;
1592s

A nasledne mozem pohodlne a rychlo vymazat presunute zaznamy

DELETE FROM csvaddresses_tmp_6 WHERE id <= 100000;

Vyhodnotenie:

• Presuvanie z docasnej tabulky vybavenej dodatocnym stlpcom id je najlepsie riesenie a ponuka vyhodu lahkej, rychlej kontroly. Ake riadky boli uz prenesene a ake sa mozu zmazat.
• Vzdycky pouzivat stlpec id aj ked na prvy pohlad je to zbytocnost.
• Dat si tu namahu a cas a robit benchmarky
• Woooow Postgres zvlada cca 4,3e9 riadkov v jednej tabulke, zatial budem generovat data do 3-4TB a potom uvidim :)

Dakujem vsetkym za rady/otazky, pomocou benchmarkov bolo odhalene uzke hrdlo a ukazany priklad ako sa to NEMA robit :). Pre mna to boli nazaj vyzivne prispevky, mam ale dalsie otazky ked budu aktualne urcite sa ozvem. @EtDirloth si mi nasadil chrobaka do hlavy s tym base64 enkodovanim :). Pri rainbow tabulke sa hodi kazdy bit :)

[.]

Tohle nejsou ty navrhované transakce a problém je v tom, že děláš něco úplně jiného, než na co ses ptal.

[Superklokan]

uvedte priklad ako v jednej transakcii prekopirovat/presunut data medzi tabulkami. lepsie riesenie ako "INSERT INTO ... SELECT ... FROM ... WHERE" ma nenapadlo.

[OldFrog {Ondra Nemecek}]

Tady je ale na místě otázka, proč ta data mezi tabulkami vůbec přesouvat?

Jinak původní dotaz zněl na pomalý insert, což většina pochopila jako pomalý import do databáze, ale nakonec se ukázalo že jde o pomalý select

[Superklokan]

povodne data som mal v CSV suboroch - niekolko 100viek GB dat s duplicitami. aj ked som urobil "sort | unique" a CSV importoval do velkej 4e9 tabulky pomocou prikazu COPY aj tak som dostaval hlasky "Error duplicate primary key". Bolo to peklo, a za kazdu cenu som chcel mat velku tabulku bez duplicit.

ano v zasade bol problem SELECTU s LIKE :), Je super ze je tu ziva IT komunita odbornikov, ktory pomohli najst riesenie a ponukli moznosti ako dalej pri vytvarani BTC rainbow tabulky :), popripade tie benchmarky co sme robili s kolegom budu niekom k niecomu :)

[OldFrog {Ondra Nemecek}]

Akorát, že tohle

cat FILE | sort | unique

Vám filtruje unikátní celé řádky, zatímco jste potřeboval mít unikátní jen tu část toho řádku. Unikátní řádky jsou např.

aaa 123
aaa 456
ccc 789

a stejně se tam opakuje to "aaa". Jinak problém, který jste řešil při importu, chápu. Bylo tu nebo na root.cz rozsáhlé vlákno na téma hromadného importu velkého množství dat, co si pamatuju tak nejrychlejší z toho byl ten COPY.

[OldFrog {Ondra Nemecek}]

Plyne z toho ještě jedno ponaučení - a to sice ponaučení pro dotazy v poradně:

Příště položit přesnější dotaz, přibližně stejně podrobný jako je to Vaše rozuzlení výše. Nejlepší je dát přesný postup, který reprodukuje nevhodné chování - s dotazem, co nevyhovuje a čeho chcete dosáhnout. Tímto postupem si člověk občas odpoví sám, ještě než ten dotaz vůbec položí (vlastní zkušenost...).

[Superklokan]

uplny suhlas.... nicmenej prispevky ktore tu odzneli mi ukazali cestu ako sa dalej popasovat s datami - komprimovat ich konvertom base64 a setrit tak miesto na disku

[.]

Base64 není komprese. Z každé trojice bytů udělá čtyři. Ta adresa podobným kódováním - Base58 - už prošla. Když budeš ukládat původní binární hodnotu, tak při vynechání kontrolního součtu ti u jedničkových adres místo těch 34 bytů na adresu stačí 20.

[Xerces]

Správně položená otázka totiž v sobě vždy skrývá odpověď. Pokud ne, tak je buď špatně položená, nebo nemá smysl si ji klást.

[Superklokan]

Neda mi a musim zareagovat. V tomto momente sme uz davno za hranicou technickej temy o postgrese a diskusia nabrala silny OT filozoficky smer ci ma zmysel klast otazky. teraz neuvazujme nad kvalitou otazok/odpovedi, Aj ked vsetko ma svoje hranice a nato tu musi byt mechanizmus aby zabranil urazaniu/osocovaniu/spamovaniu a podla moznosti drzal diskusiu v rozumnych medziach.

Ludia stojaci za ABC robia svoju pracu a robia ju DOBRE. Mam dojem ze ABC chce by portalom ktory poskytuje rozne sluzby komunite a ludom zo sveta IT. Nie vsetci tito ludia su naskillovany geeci alebo hakery. Su to ludia ktory sa hraju, su to ludia ktory travia svoj volny cas (relaxuju) programovanim/bastlenim blbniek, su to ludia, ktory si na otazku "Preco?" odpovedali "Because I can!".

Do kategorie "Because I can!" spadam aj ja. Precital som si nieco ohladom rainbow tabuliek, o BTC, precital som si, ze ani vo vermire nie je tolko atomov, kolko BTC adries. A napiek tomu ja ako laik som si zbastlil C program na generovanie BTC adries a ukladam si ich do databazy. Preco? "Because I can!" a pretoze ma to zaujima/bavi a popri tom som sa dozvedel milion iny zaujimavych veci.

Samozrejme pocas bastlenia som narazil na problemy ktore som sam nevedel vyriesit. Koho som sa mal opytat? frajerky, ktora si mysli ze Sun Solaris je opalovaci krem do solarka? rodicov pre ktorych cely internet je oranzova liska? spoluziakov, ktory maju PC len na fb/hry/porno? kamaratov co si myslia ze RPI je nieco ako RPMN?

Som preto rad ze mozem niekde polozit otazku, som rad ze sem chodia naskillovanejsi ludia ako ja, som rad ze ludia mi zadarmo pomohli/nasmerovali, som rad za pre mna vyzivnu diskusiu. za co som vdacny.

Bez zivej diskusie, bez zivej komunity by sa tento portal premenil iba na polomrtvy spravodajsky web typu linuxexpress.cz

Takze za mna ano, ma zmysel sa pytat, ma zmysel sa pytat aj nie celkom presne. na to je tu diskusia. aby ten co CHCE poradit si vypytal dalsie informacie, ktore pre zakladatela temy nemusia byt zrejme/klucove. Napokon aj code review alebo programovanie v paroch/teamoch je o "viac hlav viac rozumu".

[Kit]

Zkusil jsem benchmark s DB4. Vytvořil jsem si CSV dle vzoru - 1M unikátních záznamů, 90MB:

První milión  - 182s
Druhý milión  - 201s
Třetí milión  - 205s
Čtvrtý milión - 214s
Pátý milión   - 220s

Program napsán v PHP, CPU Intel Celeron 2,4 GHz, 2 GB RAM. Výsledná databáze s 5M záznamy má 985 MB.

[dustin]

Jenže on má těch záznamů tisíckrát víc.

[Kit]

Ano, vložení denní dávky 1e6 záznamů mu trvá 12 hodin. V DB4 totéž trvá 3-4 minuty. Ještě můžu zkusit přidat dalších 1e7 záznamů, aby se neprojevila přítomnost diskové cache.

[Superklokan]

uz to netrva tak dlho... prisiel som na problem vid vissie.. pouzival som LIKE '111$' namiesto id.

[OldFrog {Ondra Nemecek}]

Pro úplnost - radikálního zrychlení LIKE dotazů se dá docílit použitím viz Trigram/Trigraph indexů Hádám ale, že to je nepoužitelné pro vaše účely, index by byl asi příliš velký, ale je dobré o tom vědět.

[Kit]

Teď už tam těch záznamů mám 2e7, databáze má 4 GB. Zápis posledních 1e7 záznamů trvalo 37 minut. Vše s kontrolou na duplicity.

[Superklokan]

dakujem za data.

ja mam v PG tabulku (csvaddresses_tmp_5) o 1.99221e7 riadkoch. Data: 2394 MB data + Btree Index varchar(34): 1122 MB spolu 3516MB, co je o trochu menej voci DB4, asi tym ze je UNLOGGED, takze DB4 vyrazny space overhead nema.

aj ja som urobil 2 testy, vlozenim 1m a 10m riadkov do tabulky s poctom riadkov 1.99221e7.

cielova tabulka:
CREATE UNLOGGED TABLE public.csvaddresses_tmp_5
(
    address character varying(34) COLLATE pg_catalog."default" NOT NULL,
    private_key character varying(51) COLLATE pg_catalog."default"
)
WITH (
    OIDS = FALSE
)

CREATE INDEX csvaddresses_tmp_5_idx
    ON public.csvaddresses_tmp_5 USING btree
    (address COLLATE pg_catalog."default")

Vysledok:

INSERT INTO csvaddresses_tmp_5(address, private_key) SELECT address, private_key FROM csvaddresses_tmp_6 LIMIT 1000000 ON CONFLICT DO NOTHING; 
INSERT 0 1000000
Time: 9063.276 ms (00:09.063)


INSERT INTO csvaddresses_tmp_5(address, private_key) SELECT address, private_key FROM csvaddresses_tmp_6 LIMIT 10000000 ON CONFLICT DO NOTHING;
INSERT 0 10000000
Time: 99088.943 ms (01:39.089)

Az som neveril ked som uvidel ten cas. Zrejme velmi zalezi na velkosti cielovej tabulky. predtym benchmark ukazal cas 1592s pri vkladani 100k zaznamov do cielovej tabulky o 4e9 zaznomoch.

[Filip Jirsák]

To, co popisujete, je datovou strukturou klasická key-value databáze. Podíval bych se tedy po key-value databázích, které jsou přesně na tohle optimalizované.