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í
×
dnes 15:11 | Zajímavý článek

Softwarový syntezátor pro Linux Yoshimi (fork ZynAddSubFX) byl vydán ve verzi 2.0. Lukáš Růžička představuje Yoshimi v článku Hahaha Yamaha aneb Jak si z notebooku udělat synťák? na MojeFedora.cz.

Ladislav Hagara | Komentářů: 0
dnes 09:00 | Nová verze

Byla vydána nová verze 21.0 komunitní edice multiplatformního v Javě naprogramovaného univerzálního SQL klienta a nástroje pro správu databází DBeaver (Wikipedie). Proběhla změna číslování. Verze 21.0 vychází po verzi 7.3. Zdrojové kódy jsou k dispozici na GitHubu pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 0
včera 09:00 | Zajímavý článek

Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 103 (pdf), HackSpace 40 (pdf), Wireframe 47 (pdf) a Hello World 15 (pdf).

Ladislav Hagara | Komentářů: 1
27.2. 16:22 | IT novinky

Google na svém blogu věnovaném AI představil nový hlasový kodek Lyra. Kvalitou je kodek Lyra s datovým tokem 3 kbps srovnatelný s kodekem Opus s datovým tokem 8 kbps.

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

Po šestnácti měsících byla vydána nová verze 2.3 a krátce na to opravná verze 2.3.1 open source nástroje OnionShare pro přenos souborů, hostování webů a chatování přes Tor. Přehled novinek v příspěvku na blogu. Pro Linux je OnionShare k dispozici také ve formátech Flatpak a Snap.

Ladislav Hagara | Komentářů: 2
27.2. 08:00 | Nová verze

Bola vydaná nová verzia komunitnej distribúcie Mageia 8, ktorá je priamym nasledovníkom niekdajšej Mandrake/Mandrivy. Prináša podporu pre architektúru ARM, novšie prostredie GNOME 3.38.3 a KDE Plasma 20.12.0 a prechod na Python 3. Viac info sa dozviete v poznámkach k vydaniu, ináč Mageia je plne lokalizovaná do národných jazykov a poskytuje tak ako klasické aj živé inštalačné obrazy.

lukve | Komentářů: 0
26.2. 14:22 | Zajímavý software

GNU poke dospěl po třech letech vývoje do verze 1.0. Jedná se o interaktivní rozšiřovatelný editor pro práci se strukturovanými binárním daty. Přednáška věnovaná GNU poke na konferenci Kernel Recipes 2019.

Ladislav Hagara | Komentářů: 0
26.2. 09:00 | Komunita

Počet sad změn v OpenStreetMap dosáhl 100 milionů. Uživatel Lamine Ndiaye přidal budovy ve vesnici Nianiane v Senegalu.

Ladislav Hagara | Komentářů: 4
26.2. 08:00 | Nová verze

Byla vydána nová stabilní verze 2.92 svobodného 3D softwaru Blender. Přehled novinek v oznámení o vydání a na YouTube.

Ladislav Hagara | Komentářů: 0
26.2. 07:00 | IT novinky

Společnost Framework představila svůj první produkt: Framework Laptop. Jedná se o modulární notebook, který bude možné "libovolně" konfigurovat, upgradovat a opravovat. Podrobnosti budou zveřejňovány postupně. V prodeji by měl být v létě [Hacker News].

Ladislav Hagara | Komentářů: 1
Co používáte k zaznamenávání úkolů či poznámek?
 (35%)
 (15%)
 (34%)
 (9%)
 (22%)
 (21%)
 (22%)
Celkem 350 hlasů
 Komentářů: 14, poslední 19.2. 10:41
Rozcestník

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. 16:33 | Ladislav Hagara | Zajímavý článek


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

Komentáře

Vložit další komentář

Max avatar 22.1. 19:20 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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
Měl jsem sen ... :(
23.1. 09:54 a1bert | skóre: 22
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
rusim vsechny LE certifikaty! jak muzu verit nekomu, kdo pouziva mysql, patlalove!
Jakub Lucký avatar 23.1. 11:50 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Vždyť píšou MariaDB...
If you understand, things are just as they are; if you do not understand, things are just as they are.
23.1. 09:59 Marek
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Přesně to mě taky zarazilo. Se nedivím, že potřebují tolik RAM
23.1. 13:32 ondro
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.
23.1. 12:33 Adam
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Pořád lepší než PostgreSQL
23.1. 13:34 Martin Mareš
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.)
23.1. 14:07 Adam
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Jen dokud z ní nepotřebuješ číst, to jí dělá problém.
23.1. 15:34 sid
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Konkretny problem by nebol?zatial to beriem ako nepodlozene tvrdenie ktore zobecnuje.
23.1. 21:01 Adam
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
To si klidně ber, modří vědí, chytří si najdou.
23.1. 22:58 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
On si tu Adam žertuje, a všichni mu na to hned skočí…
24.1. 01:26 Martin Mareš
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Koukám, že i z /dev/null vytáhnu hodnotnější informace než z vás :)
24.1. 01:55 Adam
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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).
24.1. 17:44 Martin Mareš
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.
25.1. 01:46 Andrej | skóre: 48 | blog: Republic of Mordor | Zürich
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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).

ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
25.1. 06:51 Adam
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
lol, určitě budu poslouchat náhodnou webovku, světoběžníku.
25.1. 08:04 Martin Mareš
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Řekl náhodný anonym :-D

Zatím vaše slova nemají ani cenu bitů, kterými jsou přenášeny.
25.1. 08:35 Adam
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
A kdo to potřebuje? Zrychlí to postgres?
26.1. 09:42 Jana J. | skóre: 4 | blog: Sem_vlozte_jmeno_blogu | Praha
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Já už bych to nekrmila.
23.1. 22:54 OldFrog {Ondra Nemecek} | skóre: 34 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
Je to troll, neřešte to.
-- OldFrog
mirec avatar 24.1. 10:36 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery

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.

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
mirec avatar 24.1. 12:43 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery

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

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
24.1. 16:45 sid
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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 avatar 25.1. 06:07 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery

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

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
25.1. 07:11 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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 avatar 25.1. 08:54 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
25.1. 09:49 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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 avatar 25.1. 10:11 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery

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.

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
mirec avatar 25.1. 10:18 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery

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;
LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
25.1. 10:35 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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;
25.1. 10:39 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
ale to asi nepomůže, - tady by se hodila nějaká lazy exekuce, a tu Postgres nemá.
mirec avatar 25.1. 10:48 mirec | skóre: 31 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery

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.

LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
25.1. 11:04 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.

28.1. 07:04 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.
25.1. 13:49 Tom K | skóre: 21
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.
echo -n "u48" | sha1sum | head -c3; echo
25.1. 10:21 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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é.
25.1. 01:28 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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.
Quando omni flunkus moritati
25.1. 07:17 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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

25.1. 09:49 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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

Quando omni flunkus moritati
25.1. 10:01 okbobcz | skóre: 2
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
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ů)
24.1. 19:49 freehate
Rozbalit Rozbalit vše Re: Let’s Encrypt představila své nové databázové servery
2 TB RAM pre MariaDB je žalostne málo...

Založit nové vláknoNahoru


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