Vlákno názorů k článku Databáze MariaDB válcuje MySQL od talpa - mysql byl vzdy shit a stale je... na...
-
enough good (neregistrovaný)
je to o uhlu pohledu, systemove postgres zabira zhruba nastejno, robusnosti a moznostmi je postgres nesrovnatelne lepsi. Takze je to spis o tom jestli kdyz vedle sebe mas cinske tenisky, kterym praska pata nebo nejnovejsi model adidasky a chces si zabehat. Urcite si muzes vzit oboje, ale dnes opravdu nevidim duvod proc mysql pouzivat. Promin ale prave to "dostacujici" jsem nejcasteji slysel u lenochu co se nechteji ucit nove veci a u lidi co kaslou na rozsiritelnost a vetsi moznosti. Jim to proste staci a zakaznikovi samozrejme taky.
Stejne tak jako argument ze mysql je stale jeste na vetsine hosting serveru. Ten mohu v krajnosti brat jako smerodatny, kdyz si neuvedomis ze vyjimecne je za tim neco jineho nez lenost neco menit.
-
to neni o lenosstvi, to ja o bambilionu bezicich a existujicich projektu. V cem konkretne bude mit pro me prinos posgres pro wordpress, joomlu, drupal, cokoliv? Kdyz delam Drupal a bezi mi na nem x projektu na mysql co mi prinese kdyz nove dam na posgres? Co mi posgres prinese kdyz mam 100% kodu v aplikaci a 0% v DB? Prinese mi jen roztristenost a starosti navic.
-
omg (neregistrovaný)
> jsem nejcasteji slysel u lenochu co se nechteji ucit nove veci
Pokud je primarni zamereni tech lidi db, tak prosim. Ale pak je tu nepomerne vetsi dav lidi, kteri maji vyrazne jine projekty v hledacku o kterych Vy jste se neracil zjistit si ani jedine slovo a taky Vas neurazi slovy o lensich.
Hezke arogantni svatky preji.
-
talpa (neregistrovaný)
omg:aby se me tve urazky dotkly musel bys byt konkretni:) ale takhle to je jen placani, kazda rozumna aplikace se stavi zezdola tj. od db.
sice nevim o kterych projektech mluvis, pac jsi se ani nenamahal je vyjmenovat, ale budu obecny.
1)aplikace se vetsinou stavi dle standard sql, kdyz uz myslim do budoucna
2) pokud projekty jsou site na miru mysql, uz to samo o sobe ve me budi urcite obavy (pokud se nejedna o phpmyadmin ;)
ale plkej dal :)
-
„je to o uhlu pohledu, systemove postgres zabira zhruba nastejno, robusnosti a moznostmi je postgres nesrovnatelne lepsi.“
To není o úhlu pohledu.
PostreSQL si dlouho hrál na super enterprise. Řada verzí byla navíc nespolehlivá.
MySQL od počátku byla velmi multiploatfromní, zatímco PostreSQL dávala najevo nenávist k Windows a vůbec všemu neposixovému.
xxxxxxxxxxxxxxxxxxxxxx
„Urcite si muzes vzit oboje, ale dnes opravdu nevidim duvod proc mysql pouzivat.“
Pokud jste fanatik, tak máte pravdu.
Těžko třeba uděláte z PostreSQL embedded databázi.
MySQL má navíc velmi dobře udělané multithreadové věci.
A znovu, MySQL je mnohem lépe přenositelná, zatímco PostgreSQL dodnes není zcela bez problémů (byť dnes již velmi nepatrných a zanedbatelných) na naposixových systémech.
xxxxxxxxxxxxx
„Promin ale prave to "dostacujici" jsem nejcasteji slysel u lenochu co se nechteji ucit nove veci a u lidi co kaslou na rozsiritelnost a vetsi moznosti.“
Umím jak MySQL, tak PostgreSQL, stejně jako několik dalších DBMS.
Přesto na řadu míst raději nasazuji MySQL.
Jsem také lenoch co se nechce učit nové věci?
Kdyby PostreSQL neustále nevyvolávala nenávist vůči všemu neunixovému a byla schopna na tom dobře běham i ve vzdálenější minulosti, zřejmě by bylo PostgreSQL daleko rozšířenější. Nicméně, PostreSQL jakž takž Windows vzala na vědomí a zvládla až v roce 2010, tedy před dvěma lety. A stále to není zcela ono.
MySQL pro malá data a jednoduché operace je leckdy i rychlejší, než PostgreSQL. Není třeba pro seznam PSČ hned instalovat dedikovaný databázový server s PosgtreSQL.
xxxxxxxxxxxxxxxxxxx
„Stejne tak jako argument ze mysql je stale jeste na vetsine hosting serveru. Ten mohu v krajnosti brat jako smerodatny, kdyz si neuvedomis ze vyjimecne je za tim neco jineho nez lenost neco menit.“
Když už jste fanatik, ono „něco měnit“ znamená v komerčním prostředí investovat peníze, zaplatit lidi, atd. Není to zadarmo.
Zřejmě Vaše argumenty pro PostgreSQL nejsou dostatečně silné, aby vyvážily finanční náklady změny. Podobně je to u IPv6 versus IPv4.
-
Jen pár klasických komentářů:
PostgreSQL je POSIXová databáze - byla tak vyvíjena od začátku a aktuálně vlastně už není podporovaný žádný neposixový systém (bo WinNT je vlastně POSIXový systém). K MS Win komunita žádnou nenávist nechovala - případné porty nerealizovala komunita, ale firmy, které chtěly provozovat Postgres na svém systému - nepochybně, kdyby Microsoft dodal patche s podporou, tak by byly akceptované. Bohužel MS nic nedodal - a zároveň stav POSIXu v NT byl takový, že neumožňoval snadnou portaci - a nebyly k dispozici ani nástroje. Jediný chvíli, kdy se komunita opřela do Win technologií bylo rozhodnutí zkomplikovat instalaci pg na FAT32, jelikož se na tomto systému nebylo možné garantovat ACID.
Portace na Win NT proběhla ve verzi 8.0 (rok 2005), a minimálně od verze 8.2 (prosinec 2006) s ní na Win nejsou žádné výraznější problémy - což jestli se nepletu je 6 let a nikoliv 2 roky. Samozřejmě, že na POSIXovém systému má lepší parametry než na Win NT - za což může orientace na POSIX (procesy, sdílená paměť), což je něco, na co nejsou Win NT optimalizovány. Ale to platí i pro Oracle nebo DB2 (pro Oracle je primární platforma Linux). Ale existují firmy, které na MS Win a PostgreSQL provozují i kritické aplikace a fungují.
Je fakt, že kdyby PostgreSQL už v 90 letech podporoval MS Win, tak by měl asi výrazně větší zastoupení bo v 90 letech sice většina webů a db běžela na Linuxu, ale vývoj byl na MS Win. Na druhou stranu tehdy to nikdo neudělal - a komunita v 90 letech bylo cca 10 lidí, kteří řešili primárně funkcionalitu a nikoliv co největší pokrytí trhu (na rozdíl od MySQL, kde fungoval komerční vývoj od samotného začátku). Ale i kdyby port existoval, tak je otázka, jak by byl úspěšný - na tehdejší běžný hw (na kterém se běžely první www aplikace) byl pro pg slabý - a vyhovoval MySQL, kde se neřešily transakce, ACID, bezpečnost dat, neřešily sofistikované plány, statistiky, ale jednoduché dotazy nad relativně malými databázemi (limitované tehdejšími disky) běžely velice rychle i na relativně slabší 386. Resp. MySQL bylo psané pro slabší hw. Postgres vznikal na univerzitách, kde (v USA) s lepším hw neměli problém.
PostgreSQL si na Enterprise hraje cca od verze 7.4 - spíš od 8. řady a více méně úspěšně - a žádná z verzí nebyla taková, že bych ji označil za chybnou. Je pravda, že port pro MS Win 8.1 explicitně není doporučován (ale tehdy byla podpora win braná jako experimentální) a chyby nebyly toho charakteru, že by uživatelé přišli o data, ale v 8.2 se přišlo na to, jak optimalizovat určité subprocesy na Win a došlo k významnému zlepšení výkonu.
-
Prosím o konkrétní příklad kdy PostgreSQL komunita nějak vyvolávala nenávist vůči Windows prostředí.
To že provoz na Windows historicky nebyl tak spolehlivý jako např. na Linuxu, a na starších verzích Windows nebyly příliš doporučovány, to rozhodně není "vyvolávání nenávisti". Vývoj PostgreSQL jednoduše začal na Unixu a POSIX-compliant systémech, mezi vývojáři tak bylo jen minimum lidí kteří se dostatečně orientují v relevantních částech Windows, atd.
-
Program (neregistrovaný)
MySQL není nikdy obecně dostačující. MySQL je dobré tam, kde je spousta jednoduchých dotazů a hodně write dotazů (Ve srovnání s PostgreSQL mnohem rychleji updatuje indexy a IO subsystém je na mnohem lepší úrovni), ale pak se Vám to naplní daty a vy jen koukáte, jak nějaký větší select jede hodiny se 100% zatížením CPU, protože to MySQL neumí naplánovat líp.
Stavět nový projekt na MySQL je úplná hloupost.
-
Zvláštní, mám MySQL databázi, kde některé tabulky mají i přes 10 miliónů řádek a třeba 1 GB velikost.
Ani složité dotazy přes několik tabulek, kde SQL je přes celou obrazovky nejsou problém z hlediska rychlosti.
Co dělám špatně? Není to tím, že nevím, že mám mít problémy s MySQL a proto je nemám? Jiný důvod asi není.
-
Honza (neregistrovaný)
Takovou relativně malou databázi by asi stíhala i SQLite. Ale budeme-li se bavit o řádově bilionech řádcích a stovkách GB, pak s MySQL zapláčete nad výdělkem. Ostatně s výběrem MySQL už se spálilo tolik velkých projektů, že už si ji dnes snad nikdo nezvolí pro seriózní projekt.
-
backup (neregistrovaný)
u jednoho zakaznika se rozhodovalo, jakou databazi. V uzsim vyberu byla krome jedne komercni z usa (relativne neznamy produkt) i postgresql. Ta komercni databaze byla preferovana. A pri srovnavani tech zakladnich technickych udaju se zjistilo, ze ta komercni zvlada pouze 18 petabytu, zatimco postgres je limitovana pouze velikosti uloziste.
Z toho je videt, jak rychle se muze stat, ze clovek neuvazene sahne po horsim produktu.
-
Program (neregistrovaný)
S tímhle jste si dost naběhl. 10mil. řádků a 1GB velikost tabulky a k tomu ještě: "třeba i přes"... Vynásobte alespoň 10 a selectujte tak 10 joinovaných tabulek takové velikosti. Nechápu, co MySQL provádí, ale je schopné to počítat klidně celý den i když to má všechno v paměti. Jó, kdyby to musel tahat z disku, tak ještě beru, ale když to má nacachované...
-
Program (neregistrovaný)
Je to běžná DB + nešťastně napsaný systém, který dokáže vygenerovat select na x stránek (jestli si dobře vzpomínám, tak kolem 100kB). Samozřejmně, že některé tabulky jsou větší, než 100mil., některé menší. Celkově 10 joinů je spíš minimum. Výsledek v MySQL je "věčný" select.
-
Program (neregistrovaný)
SQL je deklarativní jazyk, je sice naivní tím skončit, ale vina je na programátorovi jen z části. Ten systém prostě vygeneroval velký select a SŘBD ho musí zpracovat co nejefektivněji. Jasně, že ten dotaz je v produkci na houby, ale nějakých 20h (pak kill) je na select poněkud moc (výsledkem dotazu je malé množství dat, takže žádné vytváření obřích tmp tabulek atp.). A opakuji, celou dobu se to točilo v InnoDB buffer poolu a ani tmp tabulky to nevytvářelo velké (nevylezly z MySQL do tmp).
Celou DB jsem do jiného SŘBD nekonvertil, zatím. Určitě to jde ale vymyslet v řádech max. desítek minut.
-
U MySQL záleží na engine a s MyISAM se naráží často - vloni jsem se setkal s extrémně pomalými JOINy - a nejednalo se o nijak komplikované dotazy v databázi s tabulkami kolem 1G - nicméně servery mají cca 70G RAM. Ukázalo se, že zakopaný pes je v nested loopu - nic jiného MySQL neumí - a v neexistující cache pro MyISAM - vážně, MyISAM nemá vlastní cache - takže nested loop nad trochu většíma tabulkama dokáže zavařit systém, bo neustále dochází k opakovanému kopírování dat mezi systémem a MySQL.
-
Třeba na co jsme narazili - identifikovali jsme problémy s MyISAM - ale přechod na InnoDB nebyl možný, protože aplikace (z důvodu chybějících transakcí MyISAM) prováděla určité operace s tabulkami, které na InnoDB byly pomalé - a úprava aplikace by byla značná. Takže v okamžiku, kdy zjistíte, že MyISAM je problém, tak na InnoDB nemusíte jednoduše přejít (v závislosti na aplikaci).
Problém je v tom, že hromada programátorů, kteří to nějak pytlíkují vůbec netuší, že InnoDB existuje, a netuší, že MyISAM je pro většinu běžných úloh nevhodný engine. A to je chybou MySQL - že své uživatele nekultivuje - dodatečně jasně neupozorňuje na rizika. Ústa si pak rozbije až uživatel.
-
Je divný, že sám velký Orákulum na webu vychvaloval MySQL jak je to superrychlá databáze vhodná na realtime aplikace.
Stejně tak je podivné, její masivní nasazení u firem, které rozhodně nezaměstnávají průměrné programátory, ale špičku.
Všichni jsou zřejmě velmi hloupí :-) a naprosto nechápou jak moc je to špatné. -
Oracle, coby vlastník MySQL, asi těžko bude hanit vlastní produkt, zvlášť když minimálně několik dalších let musí jej plně podporovat - chca nechca - a přiznejme, že MySQL je značka, kterou znají všude a která je nezaměnitelná.
Je celá řada použití, kde si MySQL vede perfektně, neboť je pro ně skoro 20 let optimalizován - a pak celá řada použití, kde si tak perfektně nevede - jak ukázal nástup NoSQL db, který šel primárně na úkor MySQL. Jinak ovšem až od verzí 5.6 umí MySQL základy jako je hash join nebo optimalizace poddotazů. Vyhození výjimky je až v 5.6 a třeba blokování triggerů MySQL neumí.
Samozřejmě, že vývojáři, kteří používají MySQL se s tím naučili žít a ještě hlasitě všem tvrdili, že nic z toho, co MySQL nepodporuje není potřeba. Typicky např. uložené procedury - a v okamžiku, kdy se v MySQL objevily, tak se jim náramně hodily - super článek na tohle téma má Jakub Vrána http://php.vrana.cz/co-nefunguje-v-mysql-a-jak-to-obejit.php
ČLÁNKY DO MAILU