Administrace komentářů

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 :)