abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 19:33 | Zajímavý článek Marek Stopka | Komentářů: 14
včera 17:55 | Nová verze

Bylo oznámeno vydání nové verze 3.0.0 a krátce na to opravných verzí 3.0.1 a 3.0.2 nástroje mitmproxy určeného pro vytváření interaktivních MITM proxy pro HTTP a HTTPS komunikaci. Přehled novinek v příspěvku na blogu. Přispělo 56 vývojářů. Aktualizována byla také dokumentace [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 01:11 | Nová verze

Byla vydána nová major verze 3.0 svobodného multiplatformního geografického informačního systému QGIS (Wikipedie). Její kódové jméno je Girona, dle názvu města, ve kterém proběhlo 15. setkání vývojářů QGISu. Přehled novinek i s náhledy a animacemi v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
23.2. 20:33 | Zajímavý článek

Nadace Raspberry Pi vydala sedmašedesáté číslo (pdf) anglicky psaného časopisu MagPi věnovanému Raspberry Pi a projektům postaveným na tomto jednodeskovém počítači a čtvrté číslo (pdf) časopisu pro kutily HackSpace věnovanému navíc 3D tisku, pájení, řezání nebo i elektronice a IoT.

Ladislav Hagara | Komentářů: 0
23.2. 18:33 | Komunita

Morevna Project, který stojí za řadou svobodného softwaru pro animátory (např. Synfig Studio, RenderChan nebo Papagayo-NG) a svobodnými (CC-BY-SA) animovanými filmy/komiksy Morevna (3. díl) a Pepper&Carrot: The Potion Contest (6. díl), sbírá do 1. března příspěvky na 4. díl svého animovaného filmu Morevna. Mezi odměnami přispěvatelům lze najít např. i videokurzy animace v Synfigu či Blenderu.

xHire | Komentářů: 0
23.2. 12:22 | Bezpečnostní upozornění

Ve středu vydaná "npm@next" verze 5.7.0 správce balíčků pro JavaScript npm (Wikipedie, Node Package Manager) přinesla řadě uživatelů Linuxu nečekanou nepříjemnost. V závislosti na způsobu instalace a ve spojení s příkazem sudo mohlo dojít ke změně vlastníka u systémových souborů, také například /. Chyba je opravena v před několika hodinami vydané verzi npm 5.7.1 [reddit].

Ladislav Hagara | Komentářů: 14
23.2. 10:00 | Nová verze

Byla vydána verze 10.5 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Zdůraznit lze integrovanou podporu Let's Encrypt.

Ladislav Hagara | Komentářů: 0
22.2. 12:33 | Komunita

Příspěvek na blogu Signalu (Wikipedie) informuje o založení neziskové nadace Signal Foundation, jež bude zastřešovat další vývoj tohoto svobodného bezpečného komunikátoru běžícího také na Linuxu (Signal Desktop). Brian Acton, spoluzakladatel WhatsAppu, věnoval nadaci 50 milionů dolarů [Hacker News].

Ladislav Hagara | Komentářů: 1
22.2. 05:55 | Zajímavý článek

Článek na Fedora Magazine krátce představuje programovací jazyk Rust a několik zajímavých v Rustu naprogramovaných terminálových aplikací. Jedná se o alternativu k příkazu grep ripgrep, moderní barevnou alternativu k příkazu ls exa, příkazem cloc inspirovaný tokei a zvířátko v terminálu ternimal.

Ladislav Hagara | Komentářů: 0
21.2. 23:55 | Zajímavý projekt

Byl spuštěn Humble Classics Return Bundle. Za vlastní cenu lze koupit hry Broken Sword 5 - The Serpent's Curse, Shadowrun Returns a Shadowrun: Dragonfall - Director's Cut. Při nadprůměrné platbě (aktuálně 8,48 $) také Shadowrun: Hong Kong - Extended Edition, Wasteland 2: Director's Cut - Standard Edition, Age of Wonders III a Xenonauts. Při platbě 15 $ a více lze získat navíc Torment: Tides of Numenera a Dreamfall Chapters: The Final Cut Edition.

Ladislav Hagara | Komentářů: 0
Který webový vyhledávač používáte nejčastěji?
 (2%)
 (27%)
 (62%)
 (2%)
 (3%)
 (0%)
 (1%)
 (1%)
Celkem 458 hlasů
 Komentářů: 35, poslední 21.2. 19:51
    Rozcestník

    Dotaz: Postgres uz nestaci?

    30.1. 13:08 Superklokan
    Postgres uz nestaci?
    Přečteno: 1804×
    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.


    Řešení dotazu:


    Odpovědi

    Marek Stopka avatar 30.1. 13:53 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    30.1. 23:19 EtDirloth | skóre: 6
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    hash index sa neda pouzit ako unique
    30.1. 15:21 OldFrog {Ondra Nemecek} | skóre: 29 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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í.
    -- OldFrog
    30.1. 19:18 jekub
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    30.1. 19:20 jekub
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    30.1. 20:13 Kit | skóre: 40 | Brno
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Nebyla by pro daný účel vhodnější nějaká jednodušší databáze, např. DB4?
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    3.2. 00:41 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    30.1. 20:27 vlasta | skóre: 10 | Brno
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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
    30.1. 21:13 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Nejsem žádný znalec postgresu, ale taky mi na 1TB tabulku se 4mld řádků a tolika inserty přijde 16GB málo.
    30.1. 21:27 lertimir | skóre: 61 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.

    30.1. 21:46 Jindřich Makovička | skóre: 14
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    30.1. 21:55 jekub
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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?
    30.1. 23:17 EtDirloth | skóre: 6
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?

    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
    30.1. 21:29 Kit | skóre: 40 | Brno
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Co takhle zkusit insert těch 1e6 záznamů strčit do jedné transakce, případně rozdělit třeba po 10k insertech?
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    Marek Stopka avatar 30.1. 22:18 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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
    30.1. 22:37 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Příloha:

    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.

    Marek Stopka avatar 31.1. 00:04 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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+
    Marek Stopka avatar 31.1. 00:05 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    s/tabulky/paměti/
    31.1. 13:44 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    31.1. 13:59 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    31.1. 00:43 EtDirloth | skóre: 6
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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" ;)
    4.2. 00:36 .
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Jak jsi to počítal, nebo o jakém bigintu mluvíš?!
    31.1. 10:25 Ovrscout
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?

    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 avatar 31.1. 22:39 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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ů.
    Hello world ! Segmentation fault (core dumped)
    31.1. 18:55 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    1.2. 08:52 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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. :)
    1.2. 09:18 EtDirloth | skóre: 6
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    hod sem potom update, alebo riesenie, pre ktore si sa rozhodol - urcite to bude zaujimat viacerych
    1.2. 13:55 Ivan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    1.2. 14:03 EtDirloth | skóre: 6
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    vsimni si ten keyword UNLOGGED v CREATE TABLE statement
    2.2. 08:16 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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?

    3.2. 00:46 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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а avatar 3.2. 01:55 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Tak to ale nechceš relační databázi, ale nějaký key-value store nebo něco úplně custom.
    3.2. 20:48 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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 avatar 31.1. 22:48 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    Hello world ! Segmentation fault (core dumped)
    3.2. 00:52 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    aj nad tym som uz uvazoval, ale prislo mi ze indexy zaberaju vela miesta na disku
    3.2. 00:37 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?

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

    3.2. 07:54 .
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Tohle nejsou ty navrhované transakce a problém je v tom, že děláš něco úplně jiného, než na co ses ptal.
    3.2. 20:55 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    uvedte priklad ako v jednej transakcii prekopirovat/presunut data medzi tabulkami. lepsie riesenie ako "INSERT INTO ... SELECT ... FROM ... WHERE" ma nenapadlo.
    3.2. 21:08 OldFrog {Ondra Nemecek} | skóre: 29 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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 :-)
    -- OldFrog
    3.2. 22:22 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?

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

    3.2. 22:55 OldFrog {Ondra Nemecek} | skóre: 29 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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
    3.2. 18:28 OldFrog {Ondra Nemecek} | skóre: 29 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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...).
    -- OldFrog
    3.2. 20:58 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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
    4.2. 00:35 .
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    14.2. 10:18 Xerces
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    16.2. 11:04 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?

    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".

    Řešení 1× (Josef Kufner)
    3.2. 04:51 Kit | skóre: 40 | Brno
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    3.2. 12:23 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    Jenže on má těch záznamů tisíckrát víc.
    3.2. 13:01 Kit | skóre: 40 | Brno
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    3.2. 21:07 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    uz to netrva tak dlho... prisiel som na problem vid vissie.. pouzival som LIKE '111$' namiesto id.
    3.2. 21:19 OldFrog {Ondra Nemecek} | skóre: 29 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    -- OldFrog
    3.2. 15:57 Kit | skóre: 40 | Brno
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    3.2. 21:40 Superklokan
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?

    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.

    7.2. 21:54 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Postgres uz nestaci?
    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é.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.