Názory k článku
Numpy zrychluje 17× řazení díky knihovně od Intelu využívající AVX-512
-
Filip JirsákStříbrný podporovatelJaký objem práce databáze podle vás dělá řazení čísel v paměti?
Je nám doufám všem jasné, že když databáze řadí nebo hledá podle indexu, není to žádné řazení v paměti, ale jde o speciální datovou strukturu navrženou tak, aby v ní data zároveň byla seřazená a zároveň se dala snadno aktualizovat při změnách dat.
-
Postgres se snaží při řazení (a i vytváření indexů) provést v paměti. Když to jde. Když se daty vejdete do work_mem, nebo maintainance_work_mem, tak se řadí quick sortem z glibc. To jsou ale spíš optimistické situace. work_mem je relativně malá (nechcete riskovat swap nebo OOM killera), tak se pak řadí external sortem.
Zdrojová data se nikdy neřadí. Tabulka je halda. Z ní se v rámci zpracování dotazu načítají data a ukládají do specifického lineárního seznamu - nebo do dočasných souborů. Pokud se vytváří index, tak se pak seřazená data serializují na disk. Pokud šlo o výpočet dotazu, tak se seřazená data po zpracování zahodí. Seřazená data v paměti se nikdy neaktualizují (v případě Postgresu).
In memory databáze fungují jinak.
17. 2. 2023, 15:24 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
To je mi jasné. Jen jsem si u předchozích dotazů nebyl jistý, jestli si to jejich autoři nepředstavují tak, že se použití téhle instrukce implementuje do PostgreSQL a to způsobí, že jejich
SELECT … FROM … ORDER BYbude 17× rychlejší, takže bude místo 30 sekund trvat 2 sekundy. -
jj
I na školeních mi dá práci vysvětlit, že provoz databáze je dost chaotický. Střídají se vám algoritmy - sortování a hashování, mění se vám velikost dat, hodně záleží na počtu a rozdělení duplicitních dat, záleží kde ty duplicity jsou, a do toho se pak přidávají různé cache - jasně se například ukazuje, že hashovací tabulky jsou od určité velikosti horší než sortování, jelikož přístup k nim není lokální - a to beru v potaz jen databázi. Pod ní je ještě filesystém, síťová vrstva, .. a všechno to má vliv na výkon v závislosti na datech a na tom jak je napsaná aplikace.
-
Režie samotného sortování je většinou docela malá, pokud pominu nějaké patologické situace, takže moc nedává smysl zrychlovat to, co už je samo docela rychlé.
Klasické OLTP databáze - jako je Postgres nebo MySQL, Oracle, atd jsou psané tak, aby v multiuživatelském provozu v režimu 30% zápisů, 70% čtení poskytovaly pokud možno stabilní výkon. Nejde o to, aby dotazy byly co nejrychlejší, ale aby jako celek databáze pokud možno nebyla příliš pomalá. Nepotřebujete, aby se dotazy zpracovaly maximálně rychle, ale chcete mít co nejnižší celkové latence. Navíc se předpokládá, že se vám data nevejdou do paměti, takže se musí s paměti docela dost šetřit, což vede k fragmentaci paměti.
U analytických databází je to něco jiného, a úplně něco jiného je to u analytických in memory databází. Tam vám latence tolik nevadí. Navíc data jsou více méně stabilní - 90-99% čtení, 10-1% zápisů, takže ten celý aparát lze uchopit jinak.
Všem koho by to zajímalo - a je to hodně poučné (i zajímavé) doporučuji si přečíst materiály dostupné k monetdb případně ke sloupcovým databázím.
-
V tom kódu používají "_mm512_mask_compressstoreu_epi32/64" - jedna z mála instrukcí, která je v Zen 4 microcoded když je výsledek uložený rovnou do paměti (a je to fakt pomalé).
Dá se to celkem jednoduše fixnout, ale nevím jestli to zrovna Intel chce :)
Toto je ale spíš problém AMD - z nějakého nepochopitelného důvodu udělali tuto instrukci celkem nepoužitelnou.
17. 2. 2023, 11:04 editováno autorem komentáře
