Vlákno názorů k článku Databáze MariaDB válcuje MySQL od Kit - Pokud bych si na běžnou webovou aplikaci (kde...

na cem se ale zde nemuzeme porad dohodnout je, co je mala a co je velka DB.

Většina webových databází nedosahuje ani 1 GB, což je stále malá databáze. Writelock je zpravidla nezajímavý, pokud typická webová aplikace z 99 % pouze data čte, ale nezapisuje. Během zápisu jednoho procesu mohou ostatní nerušeně číst.

Proč by během zápisu z jedné aplikace nemohla jiná aplikace nerušeně číst? Koukněte se někdy na úrovně izolace u dospělých DB. BTW jak se vaši zákazníci tváří, když v tom 1% případů mají nekonzistentní data?

Do ukončení zapisovací transakce čtenáři vidí původní data. Data tedy zůstávají konzistentní. Spokojen?

To je zajímavá filozofická otázka, jestli je to chyba uživatele, že ji používal špatně. Nebo jestli je to chyba databáze, že je nestabilní v situacích, když se používá způsobem, který jiným databázím nezpůsobuje problémy se stabilitou.

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.

Bavíme se o výkonu, nebo o stabilitě? Já o stabilitě.

Na tom centrálním registru vozidel byl přece problém se stabilitou, pokud k jednomu úložišti přistupovalo více DB serverů. Bavíme se tedy o stabilitě.

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.

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

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 :-)

Je otázkou, jestli jste skutečně měli jedno datové úložiště a více DB serverů, které přistupovaly ke stejným datům v úložišti. Vím, že i to se nastavit dá, ale u toho registru vozidel na to jaksi zapomněli.

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.

Jenže tohle je asi jediný použitelný způsob, jak horizontálně škálovat relační databázi. Osobně si však myslím, že v případě registru vozidel bylo škálování databáze zbytečné.

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.

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.

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.

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

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.

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

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.

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

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.

MyISAM se používá, protože je rychlejší než InnoDB a umí navíc fulltext. Pochybuji, že by MyISAM nezvládal updaty, to by byl docela závažný bug. Spíš si myslím, že to nezvládl programátor aplikace.

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.

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.

ja pernamentne narazel u Mysql pokud jsem vytvoril nejake slozitejsi db mechanizmy. Hlavne kontrola integrity funkci atd. to byly kolapsy. Hlavne vse se tvarilo ok, jen se neco neprovedlo:) standardni problem a vidim ze tu nejsem sam.

To mohla způsobit i HW chyba, chybný způsob zálohování, cokoliv.