Vlákno názorů k článku Přestaňte už používat MySQL, není to skutečný open source od Pavel Stěhule - "Velká část uživatelů MySQL přešla na MariaDB již...
-
"Velká část uživatelů MySQL přešla na MariaDB již v polovině desátých let, "
Tady je urcite chyba - mariadb byla releasnuta 2009 - takze by se mohlo uvozovat spis o roce 2015 nez 1995.
Vloni Oracle bez vetsiho vysvetleni zredukoval vyvojovy tym MySQL. U MariaDB doslo ke generacni obmene managementu - navic probehly zpravy, ze MariaDB na tom financne neni nejlepe. Takze se letos do toho zkouseji oprit.
Na MySQL porad jede (a pojede) mraky aplikaci. Postgres ma vyhodu v diverzifikovanem vyvoji - tady se ukazuje urcita vyhoda BSD licence, diky ktere vznika vyssi mnozstvi specializovanych forku - z nich se do Postgresu vraci minimum nebo nula. Existuje ale neprimy benefit - s vyvojem Postgresu ma nejakou zkusenost nasobne vic vyvojaru nez s MySQL. Coz v dobach jako je dneska, kdy je nouze o finance vyhoda - distribuovany vyvoj se snaz ufinancuje
Na Postgresu bezproblemove bezi v CR Aukro, nebo Fortuna (o kterych neco vim), takze z hlediska zateze a provozu Postgres urcite dokaze zastoupit MySQL. Nicmene na kazda aplikace je portovatelna do Postgresu. Postgres ma rad dobre znormalizovane databaze. Naopak databaze s hodne sirokymi tabulkami s velkym poctem indexu navic casto updatovane zvlada podstatne lepe MySQL.
-
"z hlediska zateze a provozu Postgres urcite dokaze zastoupit MySQL" - tohle bohužel není pravda. Dodnes má MySQL (a MariaDB) při použití InnoDB mnohem lepší výkon pro aplikace které hodně mění data a Postgres u nich musí spouštět vacuum (při spuštění dochází k výraznému poklesu výkonu). Další podstatný rozdíl je v tom, jak Postgres (ne)zvládá spousty paralelních session, díky tomu že pro každou session spouští vlastní proces. Neprojevuje se to u každé aplikace, ale ty které jsou postižené a nemohou změnit svou architekturu bohužel musí Postgres opouštět.
-
Paralelních session můžete mít otevřených tisíce - v tom problém není. Problém je v tom, že v každé session můžete pustit dotaz, který se okamžitě začne vykonávat (bez jakékoliv fronty) - a tím si můžete úplně utavit server. Běžně se to řeší nasazením pgbounceru v transakčním módu - a nebývají s tím problémy.
Postgres není dobrá databáze na data, kde dochází k intenzivním změnám relativně malého počtu řádek navíc v rámci jedné transakce (je menší zlo udělat 10 změn na 100 řádcích než 100 změn na 10 řádcích). VACUUM vždy běží až po dokončení transakce. Co je problém - a kde je Postgres výrazně pomalejší než MySQL jsou updaty oindexovaných sloupců. Ve své praxi jsem se za poslední roky nesetkal s tím, že by VACUUM byl problém (pokud si někdo nevypne autovacuum).
Horší je, že pokud se nepoužije hotupdate, tak postgres kromě modifikace samotne tabulky přidává reference do všech indexů - i do těch, které se nezměnily - což u MySQL se neděje. Tam se sekundární indexy odkazují na index PK - a je to výrazně efektivnější. Což byl třeba problém, kvůli kterému Uber odešel z Postgresu. Už jsem to tu zmiňoval - pokud máte tabulku, která má mnoho oindexovaných sloupců (bavíme se například o vyšších desítkách nebo nižších stovkách), tak UPDATE bude na MySQL výrazně rychlejší. Nemůže za to VACUUM, ale to jak má Postgres navržené indexy.
14. 1. 2026, 12:57 editováno autorem komentáře
-
Jedna věc je rozpoznatelnost rozdílu v syntetickém benchmarku, druhá věc je použitelnost resp nepoužitelnost v praxi. Shodou okolností nedávno o tomto problému vyšel příspěvek na blogu https://www.depesz.com/2026/01/06/what-is-index-overhead-on-writes/
Design, který používá InnoDB zrychluje update (zvlášť přez PK) a SELECT (přes PK), ale na druhou stranu zpomaluje jiné operace - a to docela výrazně.
Dalším faktorem jsou síťové latence a režie protokolu. Pokud aplikace neběží lokálně - tak režie TCP bude určitě vyšší než režie indexů v Postgresu (pro jednotky indexů). U některých aplikací síťové latence jsou zásadní problém - a je úplně jedno, jestli je db Oracle, Postgres, MySQL nebo MSSQL.
Nikdy jsem ale netvrdil, a nebudu tvrdit, že Postgres je ideální databáze do které jde přeportovat libovolná aplikace. Ve výsledku může být ideální kombo Postgres, MySQL, redis, elastic, mongo - vždy budou určité typy zátěže, kde nějaká databáze bude excelovat a jiná na tom bude o dost hůře - a při větší zátěži se vyplatí ty databáze kombinovat.
14. 1. 2026, 15:09 editováno autorem komentáře
-
Ano, the rigth tool for the right job je rozhodně správný přístup.
Ostatně, nebyl to nějaký benchmark, ale zkušenost z praxe. A, pochopitelně, ta aplikace o kterou se jedná a kde se řeší ty řádově tisíce TPS, kombinuje memcache, mysql, redis, postgres, clickhouse a každá ta technologie dává smysl pro konkrétní úkol. -
"a při větší zátěži se vyplatí ty databáze kombinovat."
S timhle ovsem muzes pomerne tvrde narazit na udrzitelnost a administrovatelnost neceho takovyho. Ono se ti totiz potom stane (a nerikam ze muze, protoze takovy instance znam), ze mas data rozhazeny po 20ti ruznych databazich, filesystemech a vsem moznym i nemoznym, casem se ti stejne zatez ruzne meni, takze to co bylo mozna kdysi vyhodne a "jedine mozne" je po par letech totalni tragedie ...
-
Stejně tak můžete narazit na udržitelnost systému, i když použijete jen jeden databázový systém. A dost možná o dost dříve. A zrovna tak můžete mít mrdník v datech i když máte pouze jednu databázi.
Žádná technologie vám negarantuje, že něco neskončí jako totální tragédie - zvlášť pokud nemáte lidi, kteří mají dostatečný teoretický a technologický základ - a i to není zárukou.
Dost aplikací je tragických už od svého návrhu.
ČLÁNKY DO MAILU