Let’s Encrypt představila své nové databázové servery

Otevřená certifikační autorita Let’s Encrypt v příspěvku na svém blogu představila své nové databázové servery. Hardware: 2U rack server Dell EMC PowerEdge R7525, CPU 2x AMD EPYC 7542, Memory 2TB 3200MT/s, Storage 24x 6.4TB Intel P4610 NVMe SSD. Software: OpenZFS a MariaDB s InnoDB.

22.1.2021 16:33 | Ladislav Hagara | Zajímavý článek

Komentáře

[Max]

Trochu mně překvapuje, že jim to běží na MariaDB. Každopádně pěkný železo, o podobném budu usilovat koncem roku. Je dokonce možné, že to bude také Dell.
Zdar Max

[a1bert]

rusim vsechny LE certifikaty! jak muzu verit nekomu, kdo pouziva mysql, patlalove!

[Jakub Lucký]

Vždyť píšou MariaDB...

[Marek]

Přesně to mě taky zarazilo. Se nedivím, že potřebují tolik RAM

[ondro]

Co to ma spolocne s mnozstvom RAM?

Ak by pouzili inu DB, tak by nepotrebovali tolko RAM? V pripade DB je cim viacej ram tym lepsie.

[Adam]

Pořád lepší než PostgreSQL

[Martin Mareš]

V čem vlastně? (Nerejpu, jen jsem zvědavý - pracoval jsem pár let s obojím a naopak mi přijde PostgreSQL jako mnohem "dospělejší" databáze.)

[Adam]

Jen dokud z ní nepotřebuješ číst, to jí dělá problém.

[sid]

Konkretny problem by nebol?zatial to beriem ako nepodlozene tvrdenie ktore zobecnuje.

[Adam]

To si klidně ber, modří vědí, chytří si najdou.

[Filip Jirsák]

On si tu Adam žertuje, a všichni mu na to hned skočí…

[Martin Mareš]

Koukám, že i z /dev/null vytáhnu hodnotnější informace než z vás :)

[Adam]

A co ti brání najít si benchmarky? To snad ví každý kdo s postgres někdy rozumně pracoval (nějaký eshop nebo fórum nemyslím).

[Martin Mareš]

Právě že už jsem si vlastních benchmarků naměřil docela dost a vychází mi z nich poněkud opačné výsledky. Proto mě zajímá, co jste měřil vy a co vám vyšlo.

[Andrej]

A co ti brání najít si benchmarky?

Ale kdepak, ne, takhle svět nefunguje. Ty přicházíš s jakýmsi tvrzením → ty musíš dodat důkazy. Řeči typu „já si budu klidně tvrdit nesmysl a vy ostatní mi dokažte, že se mýlím“, jsou „argumentace“ páťáka.

Mimochodem, vůbec nic nikomu nebrání najít si benchmarky. Nedá se nic dělat, opravdová databáze PostgreSQL je po všech stránkách lepší než dětská hračka MySQL (a deriváty dětské hračky).

[Adam]

lol, určitě budu poslouchat náhodnou webovku, světoběžníku.

[Martin Mareš]

Řekl náhodný anonym

Zatím vaše slova nemají ani cenu bitů, kterými jsou přenášeny.

[Adam]

A kdo to potřebuje? Zrychlí to postgres?

[Jana J.]

Já už bych to nekrmila.

[OldFrog {Ondra Nemecek}]

Je to troll, neřešte to.

[mirec]

Ja dosť pracujem s PostgreSQL hoc trol predomnou nič konkrétne nenapísal skúsim to napraviť.

PostgreSQL by som si nedovolil hodnotiť ako pomalú, alebo rýchlu (ak sa bavíme o selectoch). Základ PostgreSQL je dosť akademický, takže človek môže pomerne konzistentne očakávať určitý výkon, či pomalosť v určitých prípadoch. Jednoducho tá databáza má základné štastistiky (ak sa vykonalo analyze) a na základe nastaveného času prístupu k náhodnému bloku na disku a ďalších parametrov sa snaží odhadnúť, ktorý spôsob prechádzania / zoadenia dát / použitia indexov bude najvhodnejší. Teoreticky fajn. Prakticky nie vždy. Z mojich skúseností základnú optimalizáciu robí skvele a predvídateľne. Oproti tomu MariaDB robí mnoho optimalizácií, ktoré vedú k drastickej redukcii času selectu. Niekedy. Nie moc predvídateľne. Škoda, že neviem teraz vyhrabať blog, ktorý som na túto tému našiel a ktorý zrovnával pomerne jednoduché selecty, ktoré sa dali na základe statickej analýzy dobre zoptimalizovať. MariaDB to zvládala, PostgreSQL nerobil prakticky žiadne optimalizácie, ale na druhej strane selecty sa dali prepísať iným spôsobom (napr. subselect namiesto left outer joinu podľa unique kľúča) takže sa dosiahol rovnaký výkon.

[mirec]

Písal som komentár dosť narýchlo, nestihol som preto napísať žiaden príklad, takže teraz to skúsim napraviť.

Robím často dosť komplexné selecty s dátami z mnoho tabuliek. Väčšinou sa snažím urobiť čo najjednoduchší select z hlavnej tabuľky a zvyšná časť selectu je navrhnutá tak, aby nemohla zmeniť kardinalitu. Takže urobím select z hlavnej tabuľky s limitom napr. 10 offsetom 1000, výsledný čas pod 10ms. Potom urobím ten istý select s doplnenými buď outer joinmi s unique kľúčom, alebo subselectmi a bum, výsledný select trvá 10s, pretože databáza robí presne to isté, ako keby som od nej chcel prvých 1010 riadkov. V tom istom prípde MariaDB preskakuje načítanie atribútov, ktoré vo výsledku nie sú potrebné.

[sid]

Ako ked raz robis select s potom pridas join a ma to ist rovnako rychlo? Mozno by stalo za to sa pozriet na analyzu selectu tam je presne vidiet co je problem

[mirec]

Mám select. So subselectom / joinom, ktorý nikdy nemení kardinalitu prvých 10 záznamov vráti rýchlo. Bez subselectu, alebo joinu 10 záznamov s offsetom 1000 vráti rýchlo. So subselectom, alebo joinom 10 záznamov s offsetom 1000 vráti v porovnateľnom čase, ako keby som žiadal o 1010 záznamov. T.j. robí zbytočne subseelct aj nad riadkami, ktoré ma nezaujímajú aj keď ho môže pokojne vyodiť.

[okbobcz]

OFFSET nejde moc optimalizovat - OFFSET neznamena preskoc n radku, ale zahod n radku. Ten radek, ktery chcete preskocit se musi napred dohledat a nic vam nepomuze - v relacni db se nepracuje s polem, abych mohl jednoduse ziskat hodnotu na n pozici. Pokud pouzijete WHERE a treba PK, tak uz je to neco jineho.

[mirec]

OFFSET neznamena preskoc n radku, ale zahod n radku

Presne to je ten akademický návrh. Jednoduchý, predídateľný, presne podľa pravidiel relačnej algebry. V situácii keď sa dá 1000 riadkov preskočiť index scanom MySQL to preskočí a PostgreSQL zahadzuje, pričom na každom riadku vykonáva zbytočný subselect (ktorý nemôže ovplyvniť počet vrátených riadkov, pretože nevystupuje vo WHERE klauzule, ale je dosť pomalý).

Pokud pouzijete WHERE a treba PK, tak uz je to neco jineho

To sa dá použiť maximálne na také stránkovanie typu next next next, ale nie keď zákazník chce skočiť povedzme do polovice tabuľky. Teda áno použiť by to šlo, keby v PK neboli medzery. Pre normálne stránkovanie teda zostáva len offset a udržiavať selecty čo najmenšie a robiť selecty z ďalších tabuliek samostatne a urobiť join v kóde namiesto DB.

[okbobcz]

To samozřejmě není pravda - pokud se subselect nerozpustí v dotazu, tak se samozřejmě provede pouze tehdy pokud je to nutné. Nicméně většinou se optimalizátor snaží provést inline subselectu, poněvadž pak se dá dotaz výrazně lepe optimalizovat - například použít semijoin nebo antijoin. V opačném případě máte jen nested loop, což je to nejpomalejší, co může být. V některých případech ale selhávají odhady, a pak se paradoxně hloupý optimalizátor chová levé než chytrý. A optimalizátor v MySQL až do verze 8.0 byl velice hloupý. Nicméně Postgres skutečně nespouští subselecty, pokud to není potřeba (a nikdy to nedělal):

postgres=# explain analyze select (select oid from pg_class limit 1) from pg_class offset 300 limit 1;
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                          QUERY PLAN                                                          │
╞══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
│ Limit  (cost=13.02..13.06 rows=1 width=4) (actual time=0.271..0.273 rows=1 loops=1)                                          │
│   InitPlan 1 (returns $0)                                                                                                    │
│     ->  Limit  (cost=0.00..0.04 rows=1 width=4) (actual time=0.027..0.029 rows=1 loops=1)                                    │
│           ->  Seq Scan on pg_class pg_class_1  (cost=0.00..16.91 rows=391 width=4) (actual time=0.026..0.026 rows=1 loops=1) │
│   ->  Seq Scan on pg_class  (cost=0.00..16.91 rows=391 width=4) (actual time=0.089..0.211 rows=301 loops=1)                  │
│ Planning Time: 0.389 ms                                                                                                      │
│ Execution Time: 0.349 ms                                                                                                     │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
(7 rows)

Všimněte si loops u subselectu (zanořený plán). Je to 1, tj. subselect se vykonal pouze 1x.

[mirec]

Výber primárnej prílohy (primárneho obrázka v galérii) k produktu.

# EXPLAIN ANALYZE SELECT "catalog_product"."id", (SELECT U0."file" FROM "django_attachments_attachment" U0 INNER JOIN "django_attachments_library" U1 ON (U0."id" = U1."primary_attachment_id") WHERE U1."id" = "catalog_product"."gallery_id" ORDER BY U0."rank" ASC LIMIT 1) AS "sq" FROM "catalog_product" LIMIT 10 OFFSET 1000;
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                               QUERY PLAN                                                                                               │
├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Limit  (cost=16661.86..16828.47 rows=10 width=222) (actual time=8.214..8.271 rows=10 loops=1)                                                                                                          │
│   ->  Seq Scan on catalog_product  (cost=0.00..179614.80 rows=10780 width=222) (actual time=0.072..8.216 rows=1010 loops=1)                                                                            │
│         SubPlan 1                                                                                                                                                                                      │
│           ->  Limit  (cost=16.62..16.62 rows=1 width=20) (actual time=0.007..0.007 rows=1 loops=1010)                                                                                                  │
│                 ->  Sort  (cost=16.62..16.62 rows=1 width=20) (actual time=0.007..0.007 rows=1 loops=1010)                                                                                             │
│                       Sort Key: u0.rank                                                                                                                                                                │
│                       Sort Method: quicksort  Memory: 25kB                                                                                                                                             │
│                       ->  Nested Loop  (cost=0.57..16.61 rows=1 width=20) (actual time=0.005..0.005 rows=1 loops=1010)                                                                                 │
│                             ->  Index Scan using django_attachments_library_pkey on django_attachments_library u1  (cost=0.29..8.30 rows=1 width=4) (actual time=0.002..0.002 rows=1 loops=1010)       │
│                                   Index Cond: (id = catalog_product.gallery_id)                                                                                                                        │
│                             ->  Index Scan using django_attachments_attachment_pkey on django_attachments_attachment u0  (cost=0.29..8.30 rows=1 width=24) (actual time=0.002..0.002 rows=1 loops=842) │
│                                   Index Cond: (id = u1.primary_attachment_id)                                                                                                                          │

Sorry za humus SQL, vytiahol som to len z ORM-ka, bol som lenivý to teraz písať ručne, preto tie hnusné aliasy U0 a U1.

[mirec]

Ehm asi to nie je moc čitateľné tak ešte raz

SELECT
    "catalog_product"."id",
    (SELECT
        U0."file"
        FROM "django_attachments_attachment" U0
        INNER JOIN "django_attachments_library" U1
            ON (U0."id" = U1."primary_attachment_id")
        WHERE U1."id" = "catalog_product"."gallery_id"
        ORDER BY U0."rank" ASC
        LIMIT 1) AS "sq"
    FROM "catalog_product"
    LIMIT 10 OFFSET 1000;

[okbobcz]

subselect v seznamu hodnot se neoptimalizuje. Ten funguje jako optimalizacni bariera.

Mozna by se to dalo napsat pomoci LATERAL joinu

SELECT catalog_product.id
  FROM catalog_product,
       LATERAL (SELECT u0.file
                  FROM django_attachments_attachment U0
                       INNER JOIN django_attachments_library U1
                        ON U0.id = U1.primary_attachment_id
                       WHERE U1.id = catalog_product.gallery_id
                       ORDER BY U0.rank ASC
                       LIMIT 1) sq
LIMIT 10 OFFSET 1000;

[okbobcz]

ale to asi nepomůže, - tady by se hodila nějaká lazy exekuce, a tu Postgres nemá.

[mirec]

Možno by to šlo cez CTE, ten sa tuším na postgrese materializoval, ale zatiaľ som nemal príležitosť sa tomu poriadne venovať. Tieto problémy s výkonom som vyriešil cez ORM, ktoré má možnosť buď to riešiť cez subselecty, joiny, alebo samostatné selecty s WHERE pk in ... takže tretia možnosť ak vyslovene podľa toho poľa nepotrebujem sortovať, alebo filtrovať a moc ma to nepáli. Len som chcel upozorniť, že PostgreSQL nerobí jednoduché optimalizácie, ktoré by sa dali zistiť statickou analýzou.

[okbobcz]

Možná CTE by to šlo. Tohle je totiž úloha, která jde úplně proti relačnímu konceptu. Je to klasický ISAM přístup. Tohle nejde optimalizovat - tam jde spíš o to, jestli executor (runtime) umí něco vykonat líně nebo ne. Nicméně pokud by uměl, tak je to větvení na kritické cestě, takže pro dotazy jiného typu to bude představovat režii.

Tohle skutečně umělo dobře MySQL - protože MyISAM engine byl napsaný na tento typ úloh.

[okbobcz]

Přemýšlel jsem o tom, a implementace by byla poměrně jednoduchá, ale realizace by pak mohla mít nechtěné dopady. Problém by mohl nastat v zamykání, a v detekci race conditions. Pokud by nějaká data sémanticky byla přečtená, ale reálně nikoliv (protože by se nevykonávaly poddotazy), tak mohou nastat problémy v zajištění izolace transakce. U MySQL ISAM tabulek se to vůbec neřešilo, tak to nebyl problém (ISAM nemá řádkové zámky a také neřeší izolaci transakcí a transakce vůbec). Tam je problém, že tento způsob stránkování je hodně slabý při multiuživatelském přístupu, a hodí se jen pro jednouživatelské aplikace nebo aplikace, kde si uživatele nelezou moc do dat.

[Tom K]

Nečekám, že by to mělo nějaký velký vliv na výsledek, ale podle čeho se bere ten limit a offset? Podle mě v tom dotazu drobet chybí ORDER BY, který má pro plánovač taky význam.

[okbobcz]

Je ale pravda, že v jiných případech ten nested subselect se vykoná. V tom máte pravdu. Je to daň za executor typu volcano. Asi by to bylo možné optimalizovat, nicméně je otázkou co by to obnášelo a jestli by to nezpomalilo něco jiného.

Což ale může být zajímavé, poněvadž v MySQL 8.0 se na tento typ executoru přešlo také.

[trekker.dk]

Jo, na něco podobného jsem narazil taky. SQL dotaz s vyhledáváním v tabulce o cca 20 mil. záznamech podle sloupce/ů, nad kterým/i je index. Když to zavolám bez omezení, je výsledek za nějakých 200ms. Když to zavolám s limit 20, offset 0, trvá to 10 sekund, protože se Postgresu nezdá, že použít ten index stojí za to.

[okbobcz]

S klauzuli LIMIT jsou obcas problemy - tato klauzule muze obcas deformovat odhad. Dalsi problem muze byt v tom, ze cela teorie nad kterou je to postavene, predpoklada, ze data jsou v tabulce ulozena rovnomerne. To ale nemusi byt pravda. Nekdy nejaka zajimava data mohou byt fyzicky ulozena na konci datoveho souboru nebo tam byt nemusi, ale optimalizator si mysli, ze je najde rychle jelikoz se jedna o nekolik malo zaznamu. Tam je pak potreba pouzit osklivy workaround s OFFSET 0 (ktery blokuje flattening dotazu).

SELECT * FROM (puvodni dotaz OFFSET 0) s LIMIT 20

[trekker.dk]

Tam je pak potreba pouzit osklivy workaround s OFFSET 0

Jo, já jsem si říkal, že bych tohle dělal v té aplikaci (i když by to asi pěkně houpalo s pamětí.) Ale je to Rails věc, tj. já ty dotazy nepíšu, takže to je jedna komplikace. Plus to není nijak důležitá aplikace, takže se mi to ani moc nechtělo řešit. Upřímně řečeno bych tu tabulku mohl klidně promazat, ale dělám si na ní benchmark, co PostgreSQL zvládne

A nutno uznat, že zpracování dotazu řádově v desítkách milisekund s tabulkou o 20M záznamech při vyhledávání dle obsahu JSON dat dělá docela dobrý dojem

[okbobcz]

Tam proti vám jde i matematika. Násobí se malá čísla malými čísly (výrazně menšími než 1) a ještě se to porovnává s jinými malými čísly. A do toho ještě skutečná hustota dat vždy bude jiná než ideální, ale někdy může být ta nejhorší možná. Ta chytristika, optimalizace fungují dobře tak v 80% případech, a v 5-10% to naopak dělá zle (a vyhrává primitivní optimalizace typu použij index nad PK vždy - protože ta není citlivá na extrémní odchylky od předpokladů)

[freehate]

2 TB RAM pre MariaDB je žalostne málo...