Názory k článku Databáze MariaDB válcuje MySQL
-
on je problém i ten standard, který v podstatě nic neřeší, podobně jako C :-). Já ale narážel spíš na featury typu chování group by (select columnA, columnC from table group by columnA) nebo kdy se při neplatné hodnotě (myslím, že to dělalo třeba pro neplatné datumy) zapíše null klidně i do not-null sloupce. Takové chování je myslím unikátní a nikde jinde se to tak debilně nechová. Jde to snad i přepnout do trochu víc standardního módu.
Problém ale je, že spousta lidí začíná na tomhle bastlu a když pak zkusí ty svoje dotazy pustit na normální databázi, tak se diví, proč jim ty jejich dotazy nefungují, když na mysql to fungovalo. Že ty dotazy nedávají smysl jim vůbec nedojde.
-
smal (neregistrovaný)
Ja jsem zatim delal na MySQL, Sybase o Oracle, a i u poslednich dvou zminovanych jsem uz nasel spoustu nesmyslnych blbosti - takze mi tahle diskuze nedava smysl. Navic, jak uz tu prede mnou nekdo zminil, oni si ti vyrobci (Sybase, Oracle) vazne s nejakyma standardama hlavu nelamou - pro ne jsou dulezitejsi vlastni "standardy", ktere si samozrejme patentujou, hlavne aby klient nemohl jednoduse prechazet na jinou databazi.
-
Mike (neregistrovaný)
Ono to je to i občas k lepšímu, standard není dogma. Třeba když jsem měl dělat různé věci v MSSQL, tak jsem nadával, protože některé věci jdou v MySQL snadno, ale v MSSQL oklikou (třeba i obyčejný LIMIT). Standard je jedna věc, ale pokud nerespektuje požadavky, tak je takový standard k ničemu.
Na druhou stranu, Microsoft dělá to samé a taky mu to prochází.
-
Něco jako limit jde na MSSQL od 2005 dělat taky celkem použitelně, i když v oracle nebo mysql to je jednodušší. U databází je ten standard ale v podstatě na nic, protože skoro nic neřeší, takže si to každá db řeší po svém (třeba ten limit). Důsledek je, že existuje standard a stejně je v tom chaos a co se člověk naučí na jedné db, tak na jiné nefunguje.
Nevím, co myslíš tím, že "Microsoft dělá to samé a taky mu to prochází." Pokud by MySQL byl normální prg jazyk, tak tím svým chováním v group by umožňuje něco jako
int i;
int[] pole = {1,2,3,4,5};
i = pole;To prostě nedává smysl a nikdo jiný takový zápis neumožňuje.
-
Copak jazyk - i velká trojka postupně konverguje k ANSI SQL 200x, někdo rychleji, někdo pomaleji - (vyjma uložených procedur, tam o konvergenci nemůže být řeč). Co je ovšem pro přenositelnost aplikací důležitější, jsou rozdíly v implementaci optimalizace dotazu a transakcí - případně datových typů (a jejich existence nebo neexistence).
-
rebus (neregistrovaný)
Konecne muzu uvazovat o pouzivani teto databaze. Nesnasim zvyk z pocatku tisicileti pojmenovavat vsechno My...... - MyDocuments, MyVideo, MyHome, MySpodky MySvrsky my ... kdo jinej by ty dokumenty mel asi vlastnit, kdyz je mam na desktopu ve svem home, to je prece naprosto redundantni a navic nejednoznacna informace. Stejne jako A:"Halo, kdo tam?" B:"Ja".
Rozhodnuti prejmenovat na MariaDB tleskam - konecne to neco rika.
Mik
-
Monte Olrac (neregistrovaný)
Ad 2) Zřejmě jste nikdy nebyl přítomen rozhodovacím procesům ve větších organizacích. Nemusí to být zrovna hlavní kritérium, ale významné kritérium to být může.
A nemusíme ani chodit do velkých organizací. Pamatuji si jako student, že někteří muslimští studenti měli veliké problémy s unixovými systémy, protože tam byli démoni. Windows měly služby, ty byly v pořádku.
-
Program (neregistrovaný)
Ono studentské projekty jsou k praxi často na hony vzdálené.
Nic méně právě u takových rozhodovacích procesů právě přítomen jsem a krom takových těch reklamních slůvek, jako "enterprise" atp. jsem se naštěstí nesetkal s tím, že by rozhodoval název. Ono dovedu si představit, jak dlouho by u firmy pracoval člověk, který by protestoval proti jinak vyhovujícímu systému pro jeho název nebo název jeho součásti.
-
Monte Olrac (neregistrovaný)
Když se účastníte rozhodovacích procesů, tak víte, že často se nějaké vhodné řešení odmítne ze zcela bagatelních důvodů. A ten, kdo vhodnému řešení sebere spoustu "bodů" kvůli jménu, může být třeba majitel. Anebo dost vysoce postavený člověk, aby neměl žádného šéfa, který tomu technicky rozumí a který by mu to vytkl.
Já nepsal nic o studentských projektech. Já psal o muslimských studentech. Fakt myslíte, že pokud je nějaký muslim tak zbožný, že odmítá něco, co se jmenuje démoni, že ho to přejde, až nebude student a bude v rozhodovací pozici?
Velké korporace všechny názvy produktů volí velmi obezřetně, nechají si dělat drahé studie, jestli to slovo nemá v nějakém důležitém jazyce/kultuře nějaký problematický kontext. Nedělají to proto, že na názvu nezáleží a nedělají to pouze u věcí, které se prodávají normálním lidem.
-
Program (neregistrovaný)
Tak ono když se dostane blb na vedoucí pozici, tak je to vždy problém. Ale musí se tam nějakým způsobem dostat a studentík, který dělá problémy kvůli své víře se tam asi jen tak snadno nedostane.
Navíc, pro průměrně inteligentní management by byl asi problém název ve smyslu "YourBossIsIdiot", ale určitě ne prefix, jako "My".
Co se názvů týče, to jsou právě ty reklamní slůvka, která můžou pomoci, ale názor: "Tohle nechci, protože je tam My" se těžko dočká uplatnění.
-
> Velké korporace všechny názvy produktů volí velmi obezřetně, nechají si dělat
> drahé studie, jestli to slovo nemá v nějakém důležitém jazyce/kultuře nějaký
> problematický kontext. Nedělají to proto, že na názvu nezáleží a nedělají to
> pouze u věcí, které se prodávají normálním lidem.třeba Beefy Miracle
-
Lael Ophir (neregistrovaný)
Unixy vznikaly ve specifickém prostředí. Zákazníkům IT nic neříká (a proč by mělo - v technologii služebních aut se management také nevrtá), a dotazy typu "why there are daemons and dead children in our server" jsou svým způsobem pochopitelné. Proto má MS a řada dalších firem v oboru jiné názvosloví.
-
faha42 (neregistrovaný)
Mate nekdo informace jak vypada zarazeni MariaDB do repositaru hlavnich distribuci debian, RHEL, ... ?
Po novem roce bych chtel stavet nove stroje pro webhosting (3x web server, 2x sql server), tak jestli MySQL konci tak zrejme nahradit ji MariaDB, pripadne zvazit prechod ne Postgres?
Provozujete MariaDB jiz nekdo na ostrem stroji?
-
Josef Moravek (neregistrovaný)
My standardne pridavame repozitare
deb http://mirror2.hs-esslingen.de/mariadb/repo/5.5/debian squeeze main
deb-src http://mirror2.hs-esslingen.de/mariadb/repo/5.5/debian squeeze mainMariaDB pouzivame ostre napriklad na bydleni.cz
prechod je hladky, clustrovani bin logem MySQL -> MariaDB bez problemu,
vyvojari casto ani nezaznamenaji, kde je MySQL a kde MariaDB.Jedna z dalsich vyhod MariaDB je engine SPHINX primo v distribuci.
Prechod neni tak zasadnim krokem, jak by se mohlo zdat ze clanku a mnohe firmy to nejspis ani nebudou vybubnovavat.
-
masi (neregistrovaný)
Ja cca pred mesicem nasadil na par serveru percona mysql http://www.percona.com/downloads/, jde take o fork a naprosta spokojenost, Instaloval jsem to na centos6 a vcera i na debian stable bez potizi, zadny zakaznik si toho nevsiml, jen jeden mi o vikendu behem rozhovoru rekl, ze ma ted pocit, ze je nejaky jeho eshop podstatne sviznejsi a jestli sem upgradoval HW...
Je to pry take binarne kompatibilni, ale jelikoz sem prechazel z mysql 5.2 na percona 5.5 udelal jsem to prez dump.
Cili spokojenost a rozhodne doporucuji....
-
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
-
Pomocí foreign tables není problém takový typ storage nasimulovat. Nicméně bez zásadního přepracování executoru a optimalizátoru to pravděpodobně nic nepřinese. Hrdlem bude CPU a rychlost RAM. PostgreSQL je jen o málo pomalejší než LucidDB, což je sloupcová databáze, která data ukládá do sloupců (a komprimuje), ale jinak postrádá specifickou podporu pro execuci a optimalizaci.
Když nad tím tak přemýšlím, tak do jisté míry má PostgreSQL něco, co by se dalo přirovnat k MySQL storage systému - a pokrývá to určitou funkcionalitu MySQL storages. A tím je rozšiřitelný několika úrovňový systém pro podporu dalších typů indexů. Skrz tento systém se do pg dostávají hash, GiST, GIN indexy.
-
Abych byl trochu konkrétnější - a omlouvám se za offtopic - jedná se o index access methods http://www.postgresql.org/docs/9.0/static/indexam.html, pomocí čehož by bylo možné implementovat např. fraktálový index - viz http://www.tokutek.com/2012/01/fractal-tree-indexes-and-mead-mysql-meetup/ což je v MySQL implementováno Storage enginem TokuDB.
-
„Pokud bych si na běžnou webovou aplikaci (kde se moc často nezapisuje) měl vybrat mezi MySQL, MariaDB a PostgreSQL, vybral bych si asi SQLite.“
Upřímnou soustrast.
Autor sqlite přepíše cca 2 × do roka. Některé fungují, některé zlobí. Některé verze (označené samozřejmě za absolutně stable) klidně i samovolně ztrácejí data.
Kromě toho výkon sqlite je nula nula nic.
-
Monte Olrac (neregistrovaný)
To myslíte vážně? Někdo si stěžuje na stabilitu něčeho a vy mu odpovíte, že u vás to nepadá, že dělá něco špatně?
Provozujete tisíce instancí v nejrůznějších režimech a zátěžích na různých platformách a serverech a běží vám na tom pestrá škála aplikací, takže můžete říct, že je použita velká část funkcionalit?
Pak by měla vaše informace "my problémy se stabilitou nemáme" nějakou váhu. -
Kit (neregistrovaný)
Kdybys měl databázi MySQL na sdíleném úložišti, tak bys dopadl stejně mizerně. Na něčem podobném pohořel i centrální registr vozidel.
V manuálu SQLite je jasně napsáno, že se na sdíleném úložišti používat nemá. Většinou není problém tuto podmínku splnit. V ostatních případech je nutné zvolit jinou databázi.
-
Monte Olrac (neregistrovaný)
Já nemám žádné interní informace o problémech centrálního registru vozidel nemám, takže to nemohu komentovat.
Centrální registr jede na MySQL? Měl jsem zato, že to je aplikace postavená na .NET a běžící na windows server. Takže jsem překvapen, že v tom případě nepoužili nejlogičtější volbu - MSSQL.Problémy se stabilitou MySQL při sdílených úložištích neznám. Tedy ne větší problémy, než to má v některých verzích normálně. Ale MySQL není těžiště mé práce, takže se mohu mýlit.
-
Kit (neregistrovaný)
Pokud vím, centrální registr vozidel běží na MSSQL, ale také se mohu mýlit.
Pokud k jednomu sdílenému úložišti přistupuje z vnějšku více DB serverů, je to vždy problém. Netýká se jen MSSQL nebo MySQL, ale všech databází. Záleží pak na správném nastavení. V SQLite se to sice dá nastavit také, ale má to drastický dopad na výkon i stabilitu. Proto se použití SQLite tímto způsobem nedoporučuje.
Obvykle je nejjednodušší, pokud je DB server na stejném stroji, jako jeho datové úložiště. To bývá u většiny nasazení MSSQL, MySQL či PostgreSQL splněno. Pokud se však někdo snaží provozovat SQLite přes NFS či Sambu, splněno to není.
-
Monte Olrac (neregistrovaný)
Tak klíčová je asi tak věta - "záleží pak na správném nastavení". S MSSQL mám dost zkušeností, ale jako vývojář datové vrstvy aplikace, nejsem DB natož MSSQL specialista. Problémy se stabilitou (nemluvím o jiných problémech) kvůli sdílenému úložišti nikdy nebyly. Možná jsem měl štěstí na lidi, co to uměli na ostrých serverech nastavit :-)
-
Program (neregistrovaný)
No, já teda taky neznám interní věci centrálního registru, ale silně pochybuji, že MSSQL může mít víc instancí serveru nad jednou instancí dat. Jestli tohle něco zvládne, tak právě SQLite z lokálního disku, FirebirdSQL classic, popř. BSDDB a jiné dětičky DBM, ale určitě ne MySQL a pochybuji, že MSSQL.
-
Program (neregistrovaný)
No, jestli jediný to nevím, replikace je podle mě mnohem lepší. Ale podle mě to ani nejde. To by ty instance MSSQL musely buď neustále flushovat data a používat file-based lock (alá Firebird Classic, taky pomalé), nebo neustále syncrhonizovat data mezi sebou (což je ve výsledku víceméně stejné jako log shipping replikace). Jako nevím o tom, že by MSSQL cokoli z toho umělo. Možná se mýlím, ale podle mě je to blbost.
-
Kit (neregistrovaný)
Replikace se hodí spíš pro NoSQL, pro relační databáze je vhodnější partitioning.
Nevím, co všechno MSSQL umí, nedělám s ním. Možná v nějaké verzi Enterprise zvládá i tohle, pokud to zvládá jeho administrátor :-)
Některá disková pole umí zamykat na úrovni clusterů. Možná se toho snažili využít.
-
Cohen (neregistrovaný)
Nevite - to celou debatu pomerne pekne vystihuje. Windows Server nezna bez vyuziti nastroju tretich stran zadny sdileny souborovy system, MSSQL nepodporuje zadny jiny FS nez NTFS. Dale nelze MSSQL provozovat na sdilenem ulozisti, tj. mapovanem disku. Netusim tedy, jak by bylo mozne zprovoznit pristup vice MSSQL k jednomu FS.
Na diskovem poli skutecne probiha zamykani na urovni clusteru, tj. k FS muze pristupovat pouze jeden clen clusteru. Mozna jste mel clusterem na mysli neco jineho, ale je to nesmysl ;-). Bloky na diskovem poli zamyka OS, nikoliv diskove pole jako takove.
-
v.sp (neregistrovaný)
Tohle je u Oracle klasický RAC (Real Application Cluster) - víc instancí nad sdílenou storage.
To to opravdu nikdo jiný neumí? Vždyť Oracle s tím začal 1988...Synchronizace jde především po vyhrazené síti (obvykle gigabitový Ethernet či Infiniband), na disk se zapisuje pro zachování konzistence (aby nedošlo při pádu nodu ke ztrátě dat).
-
Ivan (neregistrovaný)
Ona to neni zadna sranda. Ten SW ne nesmirne slozitej a Oracle mel dlouho problemy se stabilitou. Jak-takz stabilni verze byla az verze 9.2.0.8, pak dlouho nic pak az 10.2.0.4. Ve verzi 11gR2 kompletne zahodili cely clusterware a napsali novy. RAC kombinuje system zamykani pomoci zamku se zasilanim zprav, nektere aplikace na tom bezi bez problemu, a jine vubec.
Jednodussi ulohu resi MySQL NDBD cluster - storage nody maji vsechno v RAM.
Anebo je tu jeste Hadoop HDFS.PS: Lamportuv(bakery) algoritmus byl publikovan uz v roce 1973.
-
v.sp (neregistrovaný)
To já souhlasím, že to není žádná sranda. Dodnes je nejlepší doporučení dělat workload partitioning, tj. na každém node dělat jinou část práce, aby se toho po síti posílalo co nejmíň. Postupně se s verzemi vylepšoval způsob přenosů bloků/zámků mezi nody - OPS s pingem před disk, pak 9i RAC s Fusion Cache, pak remastering - ale pořád je nejjednodušší to prostě neposílat vůbec. (I když se mnou marketing Oraclu asi moc souhlasit nebude:-)
11gR2 má sice nový clusterware - tj. to co běží pod rootem. Ale nejsem si zrovna jist, že má zase tolik změn v kódu pro RAC (LMON, LMS, LMD atd.) Ale přiznám se, zas tak moc jsem si s RACem na 11.2 nehrál.
Ale pořád se divím, že je tedy Oracle jediný, kdo něco takového má.
-
Je otázkou, kolik zákazníků dokáže tohle zaplatit - rozjet a udržet v provozu?
Replikací můžete dosáhnout podobných výsledků - výrazně jednodušeji - a tudíž i levněji. Kde si dovedu představit smysluplnost je provoz na drahém hw (mainfraimy) nebo extrémně velkých databází, kde už musíte řešit problém s duplikací dat.
-
v.sp (neregistrovaný)
Překvapivě hodně zákazníků.
Na velké stroje (včetně těch mainframů) to moc není, to jsou velké SMP boxy a tedy obvykle stačí jeden velký stroj. Oracle to cílí naopak na komoditní hardware, tj. "malé" linuxy. I když to malé je jen v uvozovkách, ta jejich Exadata (X3-8) má 8CPU x 10jader v každém ze dvou db nodů.Ta možnost nahradit to replikací je zajímavá, ale znamená to a) přepsat aplikace tak, aby s ní počítaly (jako např. řešit konflikty) b) vzdát se Oraclu, tj. i některých jeho pokročilých funkcí c) sehnat lidi, kteří se o to budou starat. Což všechno jde, ale ne každému se do toho chce a ne každý dodavatel je toho schopen. A pak je to i politika, bankovní systém na Oraclu (když už tedy ne na OS390/AS400) zní ještě pořád lépe než na PostgreSQL.
-
Chtít od dodavatelů, aby dobrovolně dodávali levnější technologii nebo levnější konfiguraci, je stejně bláhové jako chtít od poslanců, aby si odhlasovali menší platy. Ale i pro RAC musí být psaná aplikace - navíc synchronizace uzlů si vezme dost výkonu, takže nevyužíváte možnosti daného hw, a do třetice, kolik lidí v republice umí RAC dát dohromady, když se rozpadne (viz třeba výpadek Škodovky)?
Samozřejmě, že jde o politiku - řada interních procesů, testů a auditů je napsaná pro Oracle - a tudíž se banky nemohou jednoduše zbavit Oracle i kdyby chtěly - podobně jako se nemohou zbavit cobolovských aplikací. Že to nejde jednoduše ale neznamená, že to nejde. Některé firmy update svých aplikací spojí s migrací na Postgres. I tady v ČR vím o fabrice, kde se PostgreSQL bude nasazovat na řízení výrobní linky místo Oracle, a vím i několika bankách, které testují Postgres, jakkoliv případný přechod je v horizontu pětiletky.
Svůj předchozí příspěvek jsem ani neadresoval coby propagaci Postgresu - ale spíš jako otázku, zda-li není design a implementace RACu a podobných technologií zastaralá a zbytečně složitá, jejíž reálné nasazení jde na úkor spolehlivosti a efektivity.
-
Petr Bravenec (neregistrovaný)
Ač primárně používám Postgresql, s sqlite mám velmi dobré zkušenosti. Nasazoval jsem to na několika desítkách instalací jako embedded databázi po velmi špatných zkušenostech s MySql. V jedné konkrétní primitivní aplikaci jsem se nedokázal zbavit v MySql dvou problémů:
- Table 'tabulka' is marked as crashed and should be repaired (v tom množství instalací to bylo nutné řešit jednou až dvakrát za týden)
- Mnohem horší závada se vyskytla, když MySql neprovedla update nad některými řádky. Vše se tvářilo OK, pouze data byla stará a jen na obsluze záleželo, jak rychle dokázala problém identifikovat a odstranit (frekvence cca jdenou za měsíc nebo dva). Něco takového mi hlava nebere.Aplikace byla dodaná od externisty, který zjevně žádnou jinou databázi neviděl (programátor v MySql se lehce pozná podle nesmyslných groupby a někdy i podle neochoty to akceptovat jako závadu a opravit).
Aplikaci jsme po roce používání-nepoužívání kompletně přepsali, jako podklad jsme použili sqlite. Po zkušenostech s MySql jsme napsali celé vytvoření databázové struktury do aplikace, takže stačí aplikaci nastartovat a databázi si to vytvoří samo. Při problémech s databází ji prostě smažeme a restartujeme aplikaci (ale to zatím nikdy nebylo potřeba).
Jediný problém s databází se za půl roku provozu objevil jediný:
Při násilném restartu počítače (o restarty není nouze) se v jenom případě aplikace startovala asi půl hodiny (cca 2GB velká databáze), protože databáze dělala něco se žurnálem.
Na druhou stranu:
Dělal jsem v sqlite nějakou složitější desktopovou aplikaci a později jsem byl nucen ji přenést na postgresql. Protože sqlite je jednoduchá a dovolí programátorovi kde co, i věci nezamýšlené, byl přechod na Postgresql dost problematický kvůli chybám v sql kodu. Po přenesení databáze se však vyřešily některé nechutné a neidentifikovatelné chyby způsobené pitomými překlepy v sql, které si sqlite nechala líbit (a stejné překlepy si nechá líbit i mysql!!!).
-
Petr Bravenec (neregistrovaný)
Mně to jako uživateli databáze MySql bylo vždy úplně jedno. Jestli MyIsam neumí dělat updaty, pak se to má opravit, nebo vyhodit a nahradit InnoDB. Ale proč je tam něco, co nefunguje? Zjevně na to nenarážím sám, naznačujete to i vy: "od doby, co to nepoužívám, nemám problém".
-
Petr Bravenec (neregistrovaný)
Já s tou databází nikdy nic nedělal. Já se té databázi vyhýbám, jak jen můžu - na server dávám PostgreSQL, do ebedded aplikací SQLite. Moje špatné zkušenosti s MySql jsou s aplikacemi, které jsem musel provozovat. Nevím, jestli to byla smůla na při výběru aplikace nebo dodavatele, ale podpora nikdy nebyla, jak bych si představoval - řekl bych, že se na tom podepsal jev, který tady popsal už někdo přede mnou: programátor, který začal s MySql, nemá úplně správnou představu o tom, jak by měla databáze fungovat, vytváří si špatné návyky a nedělá aplikace dobře.
-
Pozor na to - MyISAM je rychlejší jen při malé zátěži nebo jen tehdy, když se z ní čte. V okamžiku, kdy dochází k UPDATE, tak se umí ve špičkách parádně kousnout - a než se nadějete, tak máte dole celý server - a pěti minutový výpadek - teď před vánoci to už dostalo několikrát několik eshopů. MyISAM bych dnes doporučil jen pro dávkové úlohy jako cache, kdy se mi data nevejdou do RAM nebo pro nezatížené aplikace. Pro zatížené eshopy, pokud nechcete mít problémy v předvánoční špičce, jedině InnoDB.
-
Petr Bravenec (neregistrovaný)
Já nevím, co se v té aplikaci dělo. Za prvé to psalo prase, které mohlo s tou databází udělat cokoliv. Ale ne tak velké prase, aby se to po něm nedalo přečíst - v cyklu přepisoval nějakých 70 záznamů v jedné tabulce pořád dokola (aktuální status sedmdesáti zařízení). Při tom se občas přihodilo, že update nefungoval - jak v aplikaci, tak ručně. Když jsem ručně zadal do databáze update nad postiženým řádkem, tvářilo se to, že OK, jenom data zůstala stará. Nikdy jsem nedokázal vysledovat, kdy se to děje, nebylo to ani příliš často, ale už jen fakt, že se něco takového může přihodit, mě od MySql hodně odrazuje.
Kdyby to byl jediný problém s tou aplikací, asi bych řešil databázi. Ale těch problémů tam bylo víc, řešil jsem to přepsaním celé aplikace.
-
Petr Bravenec (neregistrovaný)
MySql zjevně nemusí ani spadnout, aby se samovolně rozpadla tabulka:
http://www.wikiporno.xxx/wiki/Special:Search?search=jjj&go=Go
Celá wiki funguje, mimo vyhledávání. Odhaduji, že provozovatel o problému ví a řeší to v cronu, protože za chvíli to zase pojede.
-
"Table 'tabulka' is marked as crashed and should be repaired (v tom množství instalací to bylo nutné řešit jednou až dvakrát za týden)"
S tímhle se setkávám též pravidelně a ještě jsem nepřišel na důvod (kromě toho, že jde o vlastnost MySQL). Proč si "sama na sebe" nezavolá REPAIR TABLE (nejspíše se nic jiného stejně nedá dělat) nevím. Jako daleko větší problém vidím to, že každá operace nad takovou tabulkou je extrémně pomalá a velmi náročná na IO, což při této zátěži efektivně položí celý server (a tedy i db se zdravými tabulkami).
-
Petr Bravenec (neregistrovaný)
Rozhodit databázi na více disků nemusí být od věci. Už jen přestěhování wal na jiný disk dokáže databázi značně urychlit. Momentálně mám trochu výkonnostní problémy s jednou dost rozsáhlou databází - bobužel tabulky jsou na jednom disku spolu s indexy. Uvažuji přestěhovat některé indexy na jiný tablespace, čímž bych mohl některé výběry dost urychlit.
-
Na takhle neurčitě položenou otázku nelze konkrétně odpovědět. Odpovědi se budou lišit podle toho jestli se bavíme o read-only nebo read-write zátěže, jestli se data vejdou do paměti nebo ne, jestli chcete škálovat na mnoho paralelních dotazů nebo jeden dotaz na mnoho CPU apod. Část z toho PostgreSQL zvládá výborně, část z toho hůř.
-
backup (neregistrovaný)
ne, postgresql stale jeste nic nevalcuje. Ten duvod je jednoduchy.
Napr. v roce 2066 uzavrel nejvetsi evropsky vyrobce podnikoveho softwaru pro male a stredni firmy (SAGE) ramcovou dohodu s mysql a od roku 2008 je to software dodavano s mysql databazi. Jedna se o desetitisice instalaci.
Jestlize by ti lide ze SAGE chteli uzavrit takovou dohodu pro databazi postgresql, s kym by asi jednali. S panem Stehule nebo s panem Vondrou? Nebo s nejakou z tech par firem o max. 5. zamestnancich, co nabizi support pro postgresql?
-
2066 ?? :)
Dnes by už mohli jednat s EnterpriseDB - což je dost velká firma, aby s ní jednala IBM a nechala si od nich dodat subsystém do svého produktu. Případný support by asi byl schopný poskytnout i RedHat.
Nicméně, pokud firmy nasazují Pg, tak k tomu dohody nepotřebují - díky BSD nemusí řešit licence - Cisco nebo Apple dodává Postgres ve svých produktech a nemají sebemenší problém. Vývoj Postgresu je absolutně otevřený - v podstatě není nic, co by si libovolná firma mohla koupit a co by kdokoliv jiný neměl zadarmo.
Takže určitě tu není žádný velký partner - na druhou stranu je nemožné, aby se změnila licence Postgresu nebo aby se změnila dostupnost některé části kódu
-
Podle toho co vím tak primárním cílem dohody mezi SAGE a MySQL bylo vyřešit licenční otázky při začleňování MySQL do produktů SAGE. SAGE evidentně nechtěli používat GPL, takže si vyjednali výhodné podmínky při licencování a jinou licenci.
To ale u PostgreSQL samozřejmě není potřeba, protože je licencován pod BSD licencí, takže si ho klidně můžete vzít a šířit ho dál v komerčním balíku.
Pokud je součástí dohody i nějaký extended support (což se mi dohledat nepodařilo ale předpokládám že ano), tak samozřejmě dostatečně velké firmy existují i pro PostgreSQL - např. již Pavlem zmíněná EnterpriseDB, ale našlo by se jich i víc. V roce 2006 byla samozřejmě situace jiná, to je pravda.
-
Odkaz na Drizzle vede na mrholení (anglicky drizzle). Odkaz má vést na http://en.wikipedia.org/wiki/Drizzle_(database_server).
-
backup (neregistrovaný)
Susanne Ebrecht (to je ta jedina zena v nasem planetarnim systemu, ktere byl prijat patch do postgresql) na svem blogu v serii clanku srovnala MariaDB a postgresql a dosla k zaveru, ze obe databaze jsou vice mene rovnocene.
To jsem proste musel jeste rict, za par minut zacinaji ty svatky miru a klidu, takze tedy :-)
ČLÁNKY DO MAILU