Dotaz: Mysql - konkurenční přístup

[lkl]

Dobrý den, v mysql db mám tabulku, která je potřeba každých 5 minut aktualizovat. Aktualizace jsou minimální a proto se nedějí serverovým způsobem, ale tak, že když s tabulkou pracuje klient ve webové aplikaci, tak se nejprve zaktualizuje (což zabere nanejvýš 2s) pokud uběhlo 5 a více minut. Celé je to transparentní ale ne zcela vyhovující a to z toho důvodu že nemám ošetřeny konkurenční přístupy: co kdyby 2 klienti ve stejný čas spustili aplikaci, tak je přece nesmysl aby se to 2x celé aktualizovalo. Napadlo mě řešit to tak, že ve speciální tabulce bude nějaký sloupec "jméno tabulky" a číslo a předtím než bude klient aktualizovat inkrementuje hodnotu o 1 a potom to přečte - pokud je hodnota 1 tak pokračuje, pokud je jiná tak zkončí a s ním i zbývající klienti pokoušející se o aktualizaci, počkají random sekund a pokusí se o to znova (něco jako CSMA/CD u sítí). Toto by bylo funkční ale říkám si že databáze by to měla umět ošéfovat i lépe, ale nevím jak. Poradí někdo?

Odpovědi

[YYY]

Coz si dat ten aktualizacni skript do crontabu a zrusit ty aktualizace ze strany uzivatelske aplikace.

[lkl]

To by asi bylo přidělávání zátěže. Pokud se do aplikace přihlašují lidé jen v určitý čas (který není periodicky se opakující) tak je zbytečné aby se to pořád aktualizovalo když se s tím nepracuje. Naopak někdy je tam zase těch lidí hodně.

[FooBar]

Pokud tech lidi bude hodne, tak se situace nemeni -- tak ci onak aktualizujes kazdych pet minut. Pokud system zatizeny neni, tak ti naopak provadeni aktualizaci nevadi.

Osobne bych volil cron z duvodu snazsi administrace.

[mfo]

a co takto locknut tu tabulku len pre jedneho usera? a na konci session ju unlock? Ak je tabulka loknuta ...exit.

[lkl]

Pokud ji locknu v nějakém spojení a to spojení spadne, zůstane zamčená nebo se automaticky odemkne?

[mfo]

no podla tohto: * When you lock a table, normally it is unlocked when the connection closes, but since persistent connections do not close, any tables you accidentally leave locked will remain locked, and the only way to unlock them is to wait for the connection to timeout or kill the process.

[Heron]

databáze by to měla umět ošéfovat i lépe, ale nevím jak

Transakce, transakční izolace.

[lkl]

Jak? Transakce přece nezabrání někomu jinému pracovat s tabulkou.

[Cynik]

A co jiného by tomu mělo zabránit? Proto tam ty funkce přeci jsou. (Mimochodem, ten popis problému je dost nejasný.)

[rADOn]

To zalezi na urovni izolace transakci. Vsechny lepsi databaze maji transakce izolovane, to znamena za dokud neprovedes commit, ostatni transakce vidi data nezmenena.

[lkl]

To neřeší můj problém. Je sice hezké že ostatní vidí data nezměněna, ale nic nebrání tomu aby X aplikací najednou začalo pracovat s tabulkou.

[Heron]

K čemu toto potřebujete? Zkuste více popsat problém, z prvního popisu toho moc neplyne.

Pokud se vám nelíbí transakce (čemuž nerozumím), tak stále můžete tabulku uzamknout (vřele nedoporučuji).

[rADOn]

Pokud je schema dobre navrzene a transakce dobre implementovane, konkurencni pristup vyresi docela dobre. Z popisu problemu nejsem moc moudry, ale jestli to dobre chapu, staci ve specialni tabulce drzet cas posledni aktualizace a ridit ho v ramci stejne transakce kterou se aktualizace provadi. Neco v nasledujicim smyslu (plusminus autobus, pisu to z hlavy):

BEGIN;
SELECT last_update, now() < last_update + timeout FROM sync FOR UPDATE;
-- pokud jsou data cerstva, rollback a konec

-- sync ...

UPDATE sync SET last_update = now();
COMMIT;

Zamykani stampu pres FOR UPDATE predpoklada ze synchronizace je relativne rychla a skonci driv nez transakce vyhnije. Dalsi instance aplikace bud zustane viset ma zamku nebo uvidi snapshot pred/po synchronizaci. Zmeny provadeny samotnou aplikaci musi byt samozrejme taky transakcne koser, jinak muzes sahnout na data ktery se ti meni pod rukama.

[Heron]

To nezáleží ani tak na kvalitě DB jako spíše na zvolené izolaci. SERIALIZABLE by mohli umět všechny (je to nejjednodušší).

[Radim Kolář]

No tak zrovna SERIALIZABLE tak jak je definovane v SQL standardu umi jen DB2, protoze umi zamykat i neexistujici radky (predicate locking). Ostatni se tomu jen blizi.

napriklad v PGSQL je SERIALIZABLE mimoradne spatne protoze neceka na zamky, ale hned rusi celou transakci kdyz nastane konflikt. Kdyby se pockalo tak by konflikt nemusel nastat.

Nejjednodusi implementace SERIALIZABLE pomoci table wide locku v produkci moc netahne. Prece jen obvykle s db pracuje vice nez jeden uzivatel.

[okbob]

V PostgreSQL se čeká 1 sec na zámcích než se spustí algoritmus pro detekci deadlocku - v def. konfiguraci.

[Radim Kolář]

Neceka (alespon v 8.3). V TPC-B v serializable nedobehne ani jedina transakce do konce. Kdyby se cekalo tak by dobehly vsechny, protoze jedna trva tak 1/500 sekundy, coz by melo s 1 sec waitem projit.

Takze problemy jsou dvoji:

1. neceka se na zamky

2. deadlock detekce je spatne, protoze vzdy vybere nahodnou transakci ktera vyhraje. Spravne se to ma delat tak ze se vybere jedna a ta se pak vzdy pri konfliktu necha vyhrat aby alespon nejaka dobehla do konce.

[okbob]

To, že serializable transakce nedoběhne do konce nemusí znamenat, že se nečeká na zámky a že se chybně řeší deadlock. Osobně si myslím, že dojde ke kolizi a po commitu je jedna transakce přerušena - přičemž následující způsobí přerušení prvé, atd atd. Teoreticky by v režimu serializable podle novějšího výkladu nemělo dojít ke kolizi, což pg negarantuje neb je režim serializable interpretován ve smyslu ANSI SQL 92 - tj. nesmí docházet k fantomům.

Vzhledem k tomu, že se pracuje na moderní implementaci režimu serializable, tak se dělají testy - a nevzpomínám si, že by někdo zmiňoval jako problém aktuální řešení deadlocku viz http://wiki.postgresql.org/wiki/Serializable

[Radim Kolář]

Old scale factor is 10, wanted 5
Truncating TPC-B tables.
start load 500000 test rows Thu Dec 02 19:37:04 CET 2010
done loading test data Thu Dec 02 19:38:22 CET 2010
Vacuum prepared data.
Benchmarking Postgresql 8.4
411.13 tps, 24668 good, 10945 failed, 90 percentile 0.016 s. tpsB=-1.0

Asi 50% transakci zarve, coz nesplnuje tpc-b. Nicmene neni pravda ze se ceka 1 sekundu, protoze tenhle test bezel jen jednu minutu a kdyby se cekalo 1 sekund predtim nez to zarve tak by to nestacilo zdeadlockovat 10k transakci. Ovsem nerikejte mi ze lepsim deadlock algoritmem by neslo snizit pocet transakci co zarvaly.

Jinak mne prekvapilo ze chteji u pgsql implementovat predicate locking, to se bude hodit pro oltp.

[okbob]

Vy nečtete, co píšu :). V pg v serializable mohou transakce být zrušeny i z jiných důvodů než je deadlock. Pg vyhodí výjimku, že transakce nelze serializovat - a aplikace by měla být schopna transakci zopakovat. To, že ji nezopakuje, ale nahlásí jako neproveditelnou je "chybou" u tpc-b testu, který nerespektuje zákládní doporučení, jak psát aplikace pro režim serializable. Teď to nemyslím nijak útočně. Prostě v serializable módu může dojít ke kolizím - a tudíž aplikace by měla být schopná zopakovat transakci - protože se minimalizuje použití zámků - je to takový optimistický režim. Reálnou aplikaci byste tak jako máte TPC-B test nepostavil. Vliv kolizí by se neměl projevit na funkci aplikace - jen na rychlosti. Čím mám víc kolizí, tím více musím opakovat operací. Zde zopakuji Pg se nesnaží v úrovni serializable zabránit kolizím. To co řeší je neexistence fantomových řádků. Proč je v testu TPC-B takový výskyt kolizí netuším - možná, že je to právě tak navržený, aby kolize vyvolával.

[Radim Kolář]

Jenomze mit optimisticky serializable a tudiz minimalizovat mnozstvi zamku je missdesign, protoze to maximalizuje pocet tansakci ktere jdou do haje. Vemte si ze by transakce trvala nejakou delsi dobu - rekneme tak 10 minut a vy byste ji musel neustale opakovat z duvodu ze ji nejaka mini transakce neustale leze do cesty. Ta by realisticky proste nedobehla nikdy, pokud si nedate pred jejim zacatkem table-wide locky.

Vsechny ostatni databaze naopak maximalizuji pocet zamku aby minimalizovaly pocty transakci ktere bude nutne zrusit, protoze ne kazdy program umi opakovat transakce pri chybe. Vsimnete si ze u TPC-B nezarve u ostatnich databazi ani jedna, protoze jelikoz updatuji tabulky ve stejnem poradi tak se hezky seradi za sebe a neudelaji deadlock. Musite uznat ze jejich pristup k problematice je rozhodne pro prakticke nasazeni lepsi nez optimisticky pojaty serializable rezim u pgsql, coz je docela unikatni koncept.

[okbob]

Pokud je příliš velký počet transakcí zahozen - pak chca nechca musíte zamykat - v postgresu jsou např. k dispozici aplikační zámky - tudíž nemusíte zamykat tabulky. Ten design je navržen v jiné době pro jiné programátory a pro jiný hw, přičemž uznávám, že dnes, kdy už je k dispozici dostatek paměti, lze úroveň serializable řešit sofistikovaněji.

Určitě s Vámi nesouhlasím v tom, že by program mohl neumět opakovat transakci. Pak je to špatně napsaný program, neb COMMIT z principu může skončit chybou a vždy je riziko deadlocku. TPC-B test je postavený jinak, ale je to to instantní test. Nikoliv reálná aplikace.

Pozn. Výhrady k Pg na základě TPC-B testu nejsou úplně košer - Jak Oracle, tak DB2 mají v sobě optimalizace pro TPC-B test - což pg vzhledem k tomu, že se jedná o nekomerční sw nemá. Praxe je něco jiného než TPC-B test. Navíc třeba tak, jak jste jej použil, tak byl jak Oracle tak PG v jisté nevýhodě. V podmínkách testu je minimální doba běhu a minímální objem dat, který má několikanásobně převyšovat dostupnou operační paměť.

[Kit]

Domnívám se, že mám velmi podobný problém jako lkl a proto ho připojuji. Třeba má specifikace problému pomůže vyřešit i problém původní.

Udělal jsem si na webu RSS čtečku z více zdrojů. Klient aktualizuje stránku každých 5 minut. Dokud je jen jeden, je to OK. Když jich bude víc, tak by mi stačila aktualizace čtečky každých 5 minut. Když nebude žádný, aktualizaci potřebuji až s připojením prvního.

Obsah ze zdrojů RSS ukládám do databáze, která mi vlasně slouží jako cache. Jak vyřešit, aby 2 klienti nespustili současně proces aktualizace cache?

[Radim Kolář]

lock tables t1xx write;

aktualizovat;

unlock tables; !! <-- DULEZITE !!

[lkl]

No pokud se přeruší spojení mezi lock a unlock tables nebo se proces zasekne, tak aktualizace pujdou do kytek ...

[Radim Kolář]

No co cekate od mysql - nejhorsi databaze ktera kdy byla napsana?

Ta je urcena pro uzivatele kteri tyto problemy neresi, protoze ani nevedi ze mohou nastat. Proste coby, restartne se apache.

[Kit]

Řešení zamykáním tabulek vypadá sympaticky. Dalo by se to elegantně vyřešit i bez databáze a zamykání tabulek? Na úrovni souborového systému?

Občas mi totiž připadá, že používáme databáze i tam, kde by to mohly zvládnout pokročilejší souborové systémy. Někdy i lépe. Obvykle to v takovém případě sice znamená použití více menších souborů, ale do určitého rozsahu může být taková databáze na FS velmi výhodná.

[Heron]

Obvykle to v takovém případě sice znamená použití více menších souborů, ale do určitého rozsahu může být taková databáze na FS velmi výhodná.

Do určitého rozsahu. Pak se na to zapomene, ten rozsah je náhle 1000x větší a je problém. Já jsem pro to napsat dobře pro DB (DB ti k tomu poskytuje mnoho prostředků, které jsou ověřené časem a dostatečně výkonné) a nebude s tím problém.

[rADOn]

Můžeš dát příklad nějakého „problému“ který nepořeší vyladění nebo změna FS? Já mám totiž spíš opačnou zkušenost – pokud nejde o úlohu která vysloveně stojí a padá na tabulkách a indexech tak je relační databáze spíš neohrabaná a špatně se škáluje.

[Heron]

Můžeš dát příklad nějakého „problému“ který nepořeší vyladění nebo změna FS?

Počet záznamů. Pokud se DB schéma dobře navrhne, tak i 1000x zvýšení počtu záznamů nepředstavuje problém (protože B-stromy a operace složitosti log_n(x)). Zkus na FS zvýšit počet souborů z několika set tisíc na několik set milionů a uvidíš co se stane.

Úložný prostor. Velikost záznamu je typicky pár bajtů, což na FS vždy zabere celý blok (typicky 4kB), tedy velmi nehospodárné (režie na diskový prostor jsou stovky procent). Případně (abych se vyhnul hádce ohledně Raisera) lze zapnout tailing a výkon ještě více snížit. DB to ukládá efektivně a ještě to i (za určitých okolností) komprimuje.

S předchozími body souvisí i využití cache a rychlost. Databázi se na jednu stránku vleze velké množství malých záznamů, tedy se po chvilce provozu nejpoužívanější stránky (tj spousta záznamů) nastěhují do RAM (buď cache DB, nebo cache OS) a je to rychlé jak jen to jde. Ještě je zde readahead datových souborů. U souborů na FS ten OS prostě nemůže vědět, jaké další soubory (jednotlivé záznamy) má přednačíst a tedy to bude dost pomalé.

je relační databáze spíš neohrabaná a špatně se škáluje

Já jsem se také pojmu relační záměrně vyhnul. Pro key-value typ dat bych to strčil do Berkeley DB a byl by klid. Pro relační data je samozřejmě vždy lepší použít relační SQL DB. Začátečníkovi bych rozhodně doporučoval se nejdřív naučit relace a normální formy a nějakou opensource SQL DB (PostgreSQL) a až pak případně šaškovat s něčím jiným (až bude vědět proč a na co).

[pavlix]

Zkus na FS zvýšit počet souborů z několika set tisíc na několik set milionů a uvidíš co se stane.

Takže žádný FS se stromy není? :)

Velikost záznamu je typicky pár bajtů

Mám trošku jinou představu o významu slovního spojení pár bajtů.

což na FS vždy zabere celý blok (typicky 4kB)

Tak to může a nemusí být implementováno.

Já jsem se také pojmu relační záměrně vyhnul.

Tady bude asi to hlavní nedorozumění. Nazývat či nenazývat hromadu dat databází jenom na základě způsobu uložení, je podle mě nesmysl.

Je mnoho různých implementací formátů databází i způsobů přístupu k nim. Kombinace nějakého dialektu SQL a síťového serveru je jen jednou z mnoha možností, jak může být databáze uložena a zpřístupněna.

Začátečníkovi bych rozhodně doporučoval se nejdřív naučit relace a normální formy a nějakou opensource SQL DB (PostgreSQL)

Normální formy jsem se naučil dodatečně :), a musím říct, že aplikace této teorie neměla na návrh mých tabulek žádný vliv. Přesněji řečeno, dokud jsem neznal normální formy, tak jsem se na to díval striktně z pohledu redundance a anomálií (ač jsem zpočátku nevěděl, že se tomu tak říká).

Já bych začátečníkovi prvně doporučil, ať se naučí pracovat se soubory... i za cenu, že se zprvu vykašle na škálovatelnost u projektů s max desítkami záznamů.

Naopak bych začátečníkovi doporučil se hodně rychle přístup k datům naučit dobře abstrahovat. Přepsat jen backend pro ukládání dat pak není tak pracné.

Mezi náma, předpoklady velikosti tabulek se neškálují o několik řádů zase tak často, tak proč nezvolit easy řešení, které na desítky záznamů funguje perfektně.

Pravda, sám jsem teprv dodatečně zjistil, že u jednoduchých projektů síťová SQL databáze často zbytečně zdržuje nejen návrh a implementaci, ale dokonce i běh programu.

[okbob]

Kdekoliv, kde se řeší víceuživatelský přístup, kdekoliv, kde se data nevejdou do filesystem cache, kdekoliv kde je potřeba řešit integritu dat. Pro jednouživatelské netransakční aplikace db nepřinese vyšší výkon, na druhou stranu programátor nemusí řešit low level přístup ke zdrojům, nemusí řešit úklid, atd.

[Heron]

Někteří to neradi vidí, ale já se rozhodně nebráním použití SQL DB jako storage (i kdyby to měla být jediná fce, jako že nikdy není). Připadá mi to naopak jako nejlepší řešení v případě, že v budoucnu těch dat bude víc a ještě budou propojená s dalšími záznamy. Například fotogalerie. Je hloupé mít informace o fotkách, uživatelích apod v DB a mít pak odkaz na soubor na FS. Ten pak někdo smaže, přejmenuje, změní a integrita je v troskách. Ta fotka může být v DB klidně taky. Navíc se zálohují pouze jedny data a to ještě třebas inkrementálně pomocí transakčních logů.

Já mám třeba v DB 300mil souborů. Zatím bez dalších atributů a nějakého integritního omezení. Důvod je ten, že to nikam jinam nejde uložit tak, aby se s tím ještě dalo pracovat. V DB to prostě je, časem ty soubory můžu zpracovat do jednotlivých atributů a vazeb. Ta hrubá data pak z DB smazat. Vše transakčně a kdybych chtěl, tak i replikovaně. Udělej to na FS.

[rADOn]

Ja verim ze ti to funguje, ale rec byla o skalovani, ale to co popisujes je IMO ukazkova cesta do pekel.

Jak to udelam na FS? Musim si sam resit integritu a zamykani. A ano – je to prace navic. Replikace to poresi jen do urcity miry, kdyz se ti dataset nevejde na jedno fyzicky zelezo, mas s SQL stejnej problem a musis resit shardovani. Coz je krome jineho zase integrita a zamykani. Na rozdeleni a replikaci miliardy fotek mezi masiny muzu pouzit nejakej distribuovanej filesystem nebo klidne jen par pitomych mountu. Dulezity je, ze pro aplikaci ktera k nim pristupuje jen jako k ceste ve filesystemu se nic nezmeni. Zatimco roz-shardovani sql databaze je AFAIK prakticky prepis vseho.

[Heron]

Zpět na zem. Nepředpokládám, že by původní tazatel dělal řešení o velikosti Seznamu. Tazatel vyrábí RSS čtečku, aby si každý user nemusel stahovat feed.xml ze zdrojového webu, ale měl to tady nacachované. Dobrá věc.

To co ty popisuješ skutečně nastává v gigantických případech (Seznam, Twitter, Flickr apod). Tam jsou ale experti, kteří vědí to "co a proč" (jak jsem psal). Že by se mi to nevlezlo na jeden HW uzel mi nehrozí a troufnu si říci, že ani tazateli a tobě. Stále trvám na tom co jsem psal. Naučit se relační SQL, pak lze vyrůst na bezchémové DB a distribuované FS a v podstatě si tvořit DB po vlastní ose. Ale ne naopak.

[rADOn]

Vsak ja taky neodpovidal puvodnimu tazateli, ale reagoval na jiny post. Nechci se hadat, naopak, delam v jednom "gigantickym pripade" takze me jakykoliv zkusenosti zajimaji. Data srovnatelny s velikosti shardovany sql databaze kterou mam ted pod rukama jsem nikdy po filesystemu nehonil, proto me zajimaji prakticky zkusenosti. A ten post nejaky naznacoval.

[Heron]

Aha, tak to jsem pochopil jinak. Mě jen přišlo divné jak jsi psal, že "relační databáze spíš neohrabaná a špatně se škáluje." Já jsem zase ještě neviděl FS, který by byl výkonnější než DB.

[rADOn]

Mno muj nazor je zhruba takovej ze dokud se dataset vejde na jedno zelezo a vetsinou se cte, staci pridavat otroky az do aleluja. Coz je shodou okolnosti vetsina webu a tim padem vetsina toho na co clovek narazi. Na tom se shodnou asi vsichni Co mi vadi je, ze kdyz clovek narazi na neco jinyho, tak zjisti ze jazyk SQL je v nekterych ohledech straslive neohrabanej.

Spatnym skalovanim jsem myslel prave to pridavani slave. Master-Master replikace je bezvadna vec ale krehka jako sklo a sposuta veci se musi prepsat. Distribuovany transakce, shardovani, proxovani… totez. Je to hezky, funguje to, ale uz to neni o tolik lepsi nez jiny zpusoby. Ted jsem zrovna nedavno mel primitivni, ale nehezkou situaci s MySQL – tabule s pulmiliardou radku sice neni problem a slape jako vino na relativne slabym zeleze, ale udelat alter se rovna odstaveni aplikace. Nakonec se to muselo resit na odpojenym slave a prohazovanim masteru za behu, na muj vkus bylo pridani jednoho blbyho sloupecku az moc jako prochazka po rozbitym skle.

[okbob]

Tady zaměňujete problémy relačních db za problémy MySQL :).

[Heron]

Mno muj nazor je zhruba takovej ze dokud se dataset vejde na jedno zelezo a vetsinou se cte, staci pridavat otroky az do aleluja.

Já bych tam ale nepřidával otroky pro práci, slave používám jenom na zálohování. Pro práci mám primární server s dostatkem paměti a pokud je to málo, tak pomůže cachování v app. Memcached jsem ještě neprosadil, ale pracuje se na tom (zatím stačí optimalizovaný master, jak píše Pavel).

Master-Master replikace je bezvadna vec ale krehka jako sklo a sposuta veci se musi prepsat.

To jsem u nás odmítl udělat, byl jsem k tomu donucen. Při první příležitosti se to rozpadlo a už je od toho pokoj. Master-Master na MySQL sice jde (bohužel) nastavit, ale použitelný to není.

ale udelat alter se rovna odstaveni aplikace

Ano, alter zamyká tabulku. Možná bys mi na to mohl odpovědět (je to totiž takový kolorit všech podobných diskusí o SQL vs něco jiného), proč se dělá alter nad produkční tabulkou? Trochy mi v hlavě vrtá červíček a křičí: špatný návrh.

Nakonec se to muselo resit na odpojenym slave a prohazovanim masteru za behu, na muj vkus bylo pridani jednoho blbyho sloupecku az moc jako prochazka po rozbitym skle.

No tomu rozumím, ale když je to tak super HA věc, máte tam shardy, replikace apod, tak proč nenachystat nový cluster, nepřipravit pro něj DB (ten alter), nepřeklopit data (to klidně může běžet týden) (dosynchronizovat, tj přepnout web do readonly na hoďku) pak to přepnout na nový cluster? Jo jako tohle mi fakt není jasné, podobné diskuse jsou plné shardů větší než zeměkoule; o SQL; které to údajně neumí; replikací; a pak se přijde na to, že to (alter) je potřeba dělat za provozu a na ostrých datech. Jde vám o ta data vůbec?

[rADOn]

Já bych tam ale nepřidával otroky pro práci, slave používám jenom na zálohování.

Jasně ale řeč byla kam a jak snadno je škálovat. Když se do toho vejdeš tak to ještě neznamená, že sql databáze unese cokoliv. A buď varován, replikace není dobrej způsob zálohování, může se ti lehce stát že skončís s dvěma perfektními kopiemi perfektně podělaných dat.

Možná bys mi na to mohl odpovědět (je to totiž takový kolorit všech podobných diskusí o SQL vs něco jiného), proč se dělá alter nad produkční tabulkou? Trochy mi v hlavě vrtá červíček a křičí: špatný návrh.

Protože když udělám alter nad testovací tabulkou, tak to k ničemu nebude? Protože někdy člověk prostě přijde ke špatně navrženýmu schematu a nadávání ho nevylepší? Protože občas se prostě vyskytne požadavek se kterým se nepočítalo? Kousek od všeho.

…proč nenachystat nový cluster, nepřipravit pro něj DB (ten alter), nepřeklopit data (to klidně může běžet týden) (dosynchronizovat, tj přepnout web do readonly na hoďku) pak to přepnout na nový cluster?…

Přesně tak se to nakonec udělalo, zároveň se konečně vyměnil etch za lennyho a všichni byli spokojení. Kdyby nebyla po ruce druhá sada železa, dalo by se to udělat na odpojeným slave kterej se pak povýší na mastera. Neříkám že to nejde udělat, ale že takový řešení je neúměrně složitý a nebezpečný a proto je to pro mě varovný znamení že tady už přestává být relační databáze to nejlepší řešení. Tenhle konkrétní problém se týká MySQL, ale AFAIK je replikace křehká hračka na všech databázích.

BTW neřekl jsem že mám největší shard na zeměkouli. Naopak, ve skutečnosti by se celkem v pohodě vešel na jedno železo, ale kdysi dávno někdo s vidinou velkého růstu nasadil shardování. Růst se nekonal, ale zase toho není tak málo aby to stálo za to spojovat. Takže si teď vychutnávám všechny radosti který to přináší aniž by to k něčemu bylo A můžu zodpovědně říct, že je to obezlička, ne řešení. Ano, pokud má někdo hromadu hotových dat v sql, může to být o hodně jednodušší cesta než všechno přepisovat na jinou technologii. Ale pokud člověk _plánuje_ mít víc než jeho sql unese, neměl by ji prostě vůbec použít a od začátku stavět na něčem vhodnějším. Můj soukromej názor - ber nebo sharduj.

[Heron]

Neříkám že to nejde udělat, ale že takový řešení je neúměrně složitý a nebezpečný a proto je to pro mě varovný znamení že tady už přestává být relační databáze to nejlepší řešení.

Složitý a nebezpečný? Máš data na starém funkčním systému, na nový si je naimportuješ, otestuješ a obenchmarkuješ a pak to případně překlopíš trvale. Mě to přijde daleko bezpečnější (v jedné chvíli jsou dvě kopie dat, přičemž se to testuje na neveřejné kopii), než to dělat na živém systému.

Ale pokud člověk _plánuje_ mít víc než jeho sql unese, neměl by ji prostě vůbec použít a od začátku stavět na něčem vhodnějším.

Můžu se zeptat, ať kolem toho nechodíme jako okolo horké kaše, co plánuješ tak gigantického, že to SQL neunese? Jak moc o ta data jde?

V SQL světě, za těch několik desítek let, šlo a jde především o data a jejich ochranu. V NoSQL mi přijde, že jde o rychlost za každou cenu (i za cenu ztráty integrity dat). Na jedný konferenci o MongoDB jsem se ptal, jestli to umí alespoň transakce. Bylo mi řečeno, že web transakce nepotřebuje. A opravdu. Youtube, twitter, facebook a podobné "výstavní skříně" noSQL řešení by ode mě v oblasti ochrany a synchronizace dat dostaly čistou 5. Pokud jde o nějaký fotoblog (vysvětlovali proč se pár set milionů obrázků nevejde na filesystém) a je jedno, že se sem tam nějaká data ztratí, tak si s tím dělejte co chcete. Já si to dovolit nemohu a nechci.

[rADOn]

Složitý a nebezpečný? Máš data na starém funkčním systému, na nový si je naimportuješ, otestuješ a obenchmarkuješ a pak to případně překlopíš trvale. Mě to přijde daleko bezpečnější (v jedné chvíli jsou dvě kopie dat, přičemž se to testuje na neveřejné kopii), než to dělat na živém systému.

Ano, v ramci idiosinkrazii relacni databaze je to nejlepsi zpusob. Proto (prekvapko) jsme to tak delali

Můžu se zeptat, ať kolem toho nechodíme jako okolo horké kaše, co plánuješ tak gigantického, že to SQL neunese? Jak moc o ta data jde?

Ja neplanuju nic. Jen se snazim na praktickem prikladu vyvratit mytus ze relacni databaze jsou alfa a omega a jdou skalovat do nekonecna.

…a je jedno, že se sem tam nějaká data ztratí…

Odkud beres tuhle pevnou viru ze cokoliv neni v databazi se „ztratí“? Mam tady kolem terrabajty dukazu ze to neni pravda Koneckoncu databaze je taky objekt ve filesystemu, takze jestli veris na ztraceni souboru tak ulozenim do databaze jenom zvysujes riziko ze prijdes o vsechno.

[Heron]

idiosinkrazii

Tak tohle jsem si už musel najít ve slovníku

Ja neplanuju nic. Jen se snazim na praktickem prikladu vyvratit mytus ze relacni databaze jsou alfa a omega a jdou skalovat do nekonecna.

Jo, takže čistě teoretická diskuse (bez praxe) ...

Odkud beres tuhle pevnou viru ze cokoliv neni v databazi se „ztratí“? Mam tady kolem terrabajty dukazu ze to neni pravda Koneckoncu databaze je taky objekt ve filesystemu, takze jestli veris na ztraceni souboru tak ulozenim do databaze jenom zvysujes riziko ze prijdes o vsechno.

...která už mě přestává bavit. Z FS se může ztratit cokoliv. Pokud sletí FS, tak jsou data v hajzlu v každém případě. O tom tu řeč není. Z praktických zkušeností vím (to není víra), že co v SQL, na to se můžu spolehnout daleko více, než na nějaký bastl systém nad FS. Jak jsem psal, nesychronizované nody (standardní jev) u soc služeb jsou toho jasným důkazem. Můžeme se samozřejmě také bavit o tom, kolik by stál plně synchronní provoz o stejném výkonu a jestli je vůbec potřeba. Ale to je diskuse na zcela jiné téma.

je taky objekt ve filesystemu

To je, souhlasím. Ale z tohoto objektu můžu ve kteroukoliv chvíli (za provozu) vytáhnout dump potvrzených transakcí (mám konzistentní data v určený bod v čase). Říká se tomu záloha. U FS tohle neudělám (asi přes snapshoty), protože FS neposkytuje aplikacím transakční přístup. Dump FS pořízený za provozu aplikací na něm bude vždy do jisté míry nekonzistentní.

[rADOn]

Dump FS pořízený za provozu aplikací na něm bude vždy do jisté míry nekonzistentní.

Nikdy jsem netvrdil opak. Jen te upozornuju ze kdyz/az narazis na limity skalovatelonosti relacni databaze a zacnes si hrat se shardovanim, distribuovanyma transkakcema a podobnyma volovinama, veci prestanou byt tak jednoduchy jako napsat COMMIT a "nějaký bastl systém" z toho bude tak jako tak.

A pro data typu ulozenyho obrazku to ani nemusi dojit tak daleko aby filesystem zacal byt lepsi volba - ulozit novy obrazek atomickou operaci je trivialni uloha a zadny jiny vyhody v tomto pripade u databaze nevidim. Logicky - kdyz mezi hroudou obrazku nejsou zadny vztahy, takze mi relacni databaze nema moc co nabidnout. Kdyz bych chtel drzet nejaky dalsi metadata, tak to samozrejme bude neco jineho, pro jakykoliv rozumny objem bude sql server idealni.

(A pro "nerozumne" objemy bych sahnul po nejake NoSQL - pokud je mozne chybejici metadata kdykoliv doplnit z existujiciho souboru, staci tenky wrapper nad cimkoliv co umi atomicke operace. Oni ti silenci z facebooku mozna nejsou uplni silenci, ale proste jen maji data spravnyho typu.)

[Heron]

Jen te upozornuju ze kdyz/az narazis na limity skalovatelonosti relacni databaze a zacnes si hrat se shardovanim, distribuovanyma transkakcema a podobnyma volovinama, veci prestanou byt tak jednoduchy jako napsat COMMIT a "nějaký bastl systém" z toho bude tak jako tak.

Jen by mě opravdu zajímalo, kolik setin procenta je projektů tak velkých. Prostě akademická diskuse, sorry.

Kdyz bych chtel drzet nejaky dalsi metadata

Což je ale typický příklad (a to i třebas pro uživatelské fotky někde na desktopu, také je chce třídit, označovat lidi apod.). Žádná mutlimediální data nežijí jen tak ve vakuu a ke všem je hodně metadat.

Oni ti silenci z facebooku mozna nejsou uplni silenci, ale proste jen maji data spravnyho typu.

Nejsou. To jsou experti, kteří vědí co a jak. Začátečník, amatér, při vší úctě neví co a jak.

[rADOn]

Jen by mě opravdu zajímalo, kolik setin procenta je projektů tak velkých. Prostě akademická diskuse, sorry.

Coz je jen jinymi slovy to co jsi uz rekl nekolikrat - ze TY to nepotrebujes. To neni argument, jen popis stavu kterej se muze zmenit. A jestli opravdu futrujes vetsi pocet obrazku do blobu v mysql tak to muze nastav driv nez si myslis

Žádná mutlimediální data nežijí jen tak ve vakuu…

Jiste, proto jsem to taky uvedl jako priklad kde se relacni databaze hodi. Ale taky existuje spousta dat ktere jsou jen haldy bitu. A filesystem je v praci s haldami bitu (prekvapive) efektivni, zatimco databaze jen pridava rezii

[Heron]

Nepochopil jsi, co jsem tím myslel. To není o tom, že já to nepotřebuju. Vůbec ne. To je o tom, že řešení, která ty naznačuješ, jsou potřeba pouze výjimečně. Rozhodně mi nepřijde správné (a to už se opravdu opakuji) doporučovat začátečníkům (kteří tvoří RSS čtečku) tvořit nějaká vlastní řešení nad soubory z důvodů: "to muze nastav driv nez si myslis" a teď co vlastně?

Na desktop bez problémů za běžné peníze (tím myslím +/- průměrný plat), dostaneš 16TB storage. Na server opět bez problémů 128TB. Jako to není nic proti tobě, třeba opravdu pracuješ s datasety o velikosti 100TB. Já jsem se ve své praxi setkal s DB o velikostech do 10GB (pouze výjimečně více), o které jejich majitelé říkali "fakt velká" (s max jednotkami mil. záznamů). Pavel Stěhule, český vývojář PostgreSQL, zde uvedl, že i ten nejvytíženejší server se vleze na jedno železo. Doma mám testovací DB (MySQL + PostgreSQL, protože v práci mám na starostí obé) okolo 300GB (zatím tam tedy nejsou ty obrázky) s cca 500M záznamy. A to mám prosím 3 roky starý komp s 3TB storage.

Takže co se musí stát, aby člověk musel řešit, co to ty naznačuješ?

[Heron]

Jinak, abych nebyl takový negativista, pokud opravdu pracuješ na projektu, který se plánuje nevejít na jeden HW server, tak sem s tím, opravdu rád bych si o tom přečetl něco relevantnějšího. (Zatím je web bohužel plný jen hype kolem NoSQL a lidí, kteří neumí ani pořádně napsat select -- a to ani v té jejich vysněné nosql variantě).

[Kit]

Zatím je web bohužel plný jen hype kolem NoSQL a lidí, kteří neumí ani pořádně napsat select -- a to ani v té jejich vysněné nosql variantě.

Tak to je velmi výstižné. Občas dělám v MySQL a nesnažím se příliš normalizovat, aby ty dotazy nebyly moc složité. Vyzkoušel jsem SQLite i NoSQL databáze Redis, Tokyo Cabinet, MongoDB, CouchDB,... abych nakonec zjistil, že pro primitivní aplikace mi bohatě stačí filesystém a sada unixových filtrů. Pro složitější aplikaci si vyberu to, co bude nejlépe vyhovovat datovému modelu.

Jiný případ: Co byste třeba vybrali, pokud by databáze měla cca 5000 řádek a 150 polí (řídkých), když si ministerstvo zítra může vymyslet další položku pro evidování (týká se 3 záznamů z oněch 5000) a k tomu číselník? To jen taková poznámka k pochybnosti o potřebě ALTER u dobře navržené databáze.

[Heron]

Co byste třeba vybrali, pokud by databáze měla cca 5000 řádek a 150 polí (řídkých) ... ministerstvo zítra může vymyslet další položku

Excel

On to bohužel až takový vtip není. Každý den bych mohl napsat další slovník nových vulgarismů jen na základě komunikace s jistým úřadem státní správy (a co je ještě horší, má v názvu slovo vzdělávání). A to jim nedělám DB, ale jen certifikáty. Jiné úřady se nejsou schopni shodnout na datech (natož pak na jejich typu, nedejbože významu), přidávají a odebírají atributy podle aktuální nálady personálu apod. Vím o čem mluvíš . Na druhou stranu je zase co dělat a oni na rozdíl od jiných platí.

[Kit]

Co byste třeba vybrali, pokud by databáze měla cca 5000 řádek a 150 polí (řídkých) ... ministerstvo zítra může vymyslet další položku

Excel

On to bohužel až takový vtip není.

Opět trefa do černého. Dalo by se také říct, že Excel je asi nejpoužívanější NoSQL databáze. Zejména na ministerstvech.

Použití Excelu by zas taková výhra nebyla, protože data jsou agregována ze 44 zdrojů, které si do těch dat nesmí vzájemně vidět a přitom je nutné respektovat historii. V případě Excelu téměř neproveditelné.

Pak se někdo diví, proč místo po SQL šilhám po NoSQL řešení, které je pro řídké tabulky jak dělané. Chybí sloupec? Dodělám ho do aplikace, však ta databáze si s tím nějak poradí.

[okbob]

Pro uložení semistrukturovaných dat lze v pg použít datový typ hstore - doplněk hstore. Lze pak ukládat pole dvojic [klíč, hodnota]. Toto pole lze indexovat. Určitě bych preferoval normalizaci vždy kdy je to jen trochu možné, nicméně občas to možné není, a hstore je menší zlo než EAV tabulky.

[Kit]

Já jsem zase ještě neviděl FS, který by byl výkonnější než DB.

Viděl jsem tady dohady kolem půl miliardy řádek. Asi je vám jasné, že na FS bych se to napasovat nesnažil a rovnou sáhl po vhodné databázi. Zajímalo mne řešení pro desítky až tisíce záznamů.

Když se budu pokoušet cachovat RSS 20 webů, tak udělám 20 souborů ve FS, které budu aktualizovat třeba i s pomocí tempu při vytváření a následným přejmenováním (kvůli atomicitě operace). Snaha o nacpání všech 20 záznamů do jednoho souboru může být za určitých okolností vhodná, za jiných nevhodná (random access). Když už to budu chtít do jednoho souboru, tak asi do databáze.

Udělal jsem si primitivní benchmark: 300k souborů v jednom adresáři na ext3 vytvořených rychlostí 3000 souborů/s. Na podobné úlohy do 1000 záznamů (resp. souborů) to vidím úplně v pohodě, zejména u FS založených na B-tree.

FS bych přirovnal k jednoduché bezschémové databázi key->value. Na jednoduché úlohy se to určitě použít dá. Možná i s lepším výsledkem, než s DB.

Díky všem za názory. Řešení nevidím jako jednoznačná, vždy bude záležet na množství a struktuře vstupních i výstupních dat a dalších požadavcích na zpracování.

[rADOn]

300k souborů v jednom adresáři na ext3 vytvořených rychlostí 3000 souborů/s.

No a to je celá diskuze o použitím filesystému v kostce - nakonec se vždycky ukáže že skalní fandové databází srovnávají svoje vyladěný konfigurace s defaultním nastavením nejblbějšího možnýho filesystému. Když mi kolegové v práci vysvětlovali proč se pár set milionů obrázků nevejde na filesystém, vypadlo z nich že ani neví co je tune2fs, natož aby se obtěžovali zkusit blbýho reisera

[Heron]

Na obé je jednoduchá reakce. Těch 3000 souborů / s je vytvoření. To jde sekvenčně, to jsou metadata. Ptám se, je to commitnuté na disk (fsync)? A co takhle s tím pracovat? Náhodně přidávat a mazat, editovat. To už taková legrace není. Benchmarkovat vytvoření souborů ve write cache nic neukáže.

Ad blbý FS v defaultu. Ono to sice nějak vyladit jde, ale nelze od toho čekat zázraky. K tomu reiseru (vidím, že se tomu bohužel nevyhneme), v (jediném) enterprise distru (RHEL) mám na výběr ext2 a ext3. Teprve jeden měsíc je k disposici i ext4 a xfs. Takže tak .

[Kit]

Proto jsem napsal "primitivní benchmark". Jen jsem si chtěl ověřit, co udělá 300k záznamů v jednom adresáři bez jakékoli optimalizace. Nic víc. Zkusím ještě náhodně přidávat a mazat. V každém případě očekávám na ext3 lepší výsledky než na FAT a horší než na BtrFS.

Proč se vlastně dělají souborové systémy? Proč nejsou nahrazeny databází? Proč aplikace ukládají svá data do souborů a ty teprve do souborových systémů? Proč se vlastně dokumenty a tabulky neukládají _po nodech_ do databáze nahrazující FS?

Vím, že přecházím z extrému do extrému, ale chci prijít na podstatu současného stavu. FS používáme z historických důvodů, databáze také. Přitom se v obou případech jedná o databáze s různými nároky na ACID. Proč se používají FS, když ACID nevyhovují a ani nejsou výkonnější? Proč je nezahodíme a nenahradíme všechny FS databází?

[Heron]

Vím, že přecházím z extrému do extrému, ale chci prijít na podstatu současného stavu. FS používáme z historických důvodů, databáze také. Přitom se v obou případech jedná o databáze s různými nároky na ACID. Proč se používají FS, když ACID nevyhovují a ani nejsou výkonnější? Proč je nezahodíme a nenahradíme všechny FS databází?

Jsou to dva různé způsoby ukládání dat. Oba (FS a DB) poskytují zcela jiné služby a mají jiné použití, výhody a nevýhody.

FS poskytuje blok dat (adresovaný od 0 do filesize, přístup blokově a nebo streamem) a nezajímají ho ta data samotná (nerozumí obsahu souboru a ani se o to nesnaží). Je to nejrychlejší možný způsob (tedy kromě RAW přístupu k disku, který se také používá na ukládání dat, klidně svá data můžeš ukládat jako jednotlivé sektory disku a fakticky si tak vytvořit vlastní FS, jde to) přístupu k datům. Proč se používá je jednoduché. Pokud má program data v nějaké struktuře v bloku paměti, tak jednoduše ten blok vysype do souboru. Staré 8bit, DOSové hry takto měli řešení ukládání herních pozic a některé programy to tak používají dodnes. Na velká sekvenční data (multimediální soubory například) je to ideální způsob uložení (i když by video šlo logicky rozdělit na jednotlivé framy a ty uložit pod nějakým pořadovým číslem do DB, tak toto by nepřineslo vůbec žádné výhody; najít ve velkém souboru konkrétní frame se umí i jinak a efektivněji).

FS také řeší rychlost přístupu k datům (velkých objemů) snižováním fragmentace a také snižováním seeků (pohyb hlaviček) u rotujících disků (u SSD toto odpadne, tam se budou řešit jiné problémy).

Toto byly výhody FS. Nevýhodou je adresace záznamu (souboru) pouze pomocí primárního klíče (plná cesta), malý počet souborů a neefektivní ukládání malých souborů (vždy jeden blok). Což ale všechno plyne z toho, co má FS být. FS prostě poskytuje blok dat adresovaný jedním primárním klíčem (jménem souboru) a offsetem (pozicí v souboru). Nic víc (pokud vynecháme metadata, ale o tom tu řeč není).

FS nemá nic jako transakce. Má jisté atomické operace (například přejmenování), pomocí kterých jde něčeho jako transakčního chování dosáhnout. Maildir například má adresář cur (new) a tmp. Soubor emailu si připravuje v tmp a až je celý hotový, tak jej atomicky přesune (přejmenuje) do adresáře cur (nový tedy do new). To už je takové drbání se levou nohou za pravým uchem. Šlo by to zobecnit samozřejmě i pro více záznamů (souborů) tak, že se vytvoří adresář někde bokem a pak se tento adresář přesune do "ostré" stromové struktury. Nevím, jestli tuhle šílenost někdo používá.

Další nevýhoda FS je drahá operace sync, kterou se mnozí programátoři snažili různě obcházet (jednoznačně jejich chyba a neznalost, šlo to udělat jinak) až se z toho nakonec stal patch do ext4 (který jinak ztrácel data při pádu stroje), který má za úkol se pro některé aplikace chovat stejně jako ext3 (default commit po 5s). DB ti to commitne bezpečně na disk bez většího výkonového dopadu na další operace.

Opačným extrémem je relační SQL DB. Jako mezi tím jsou ještě keyvalue (velmi vhodné pro jistá data), readonly archivy (takto některé programy obcházejí přílišný počet souborů, mají zip archiv a v tom adresářový strom s mnoha soubory, je to rychlé, protože readahead OS postupně načte tento zip celý do RAM a navíc se nemusí seekovat po jednotlivých souborech na FS, je to jen v jednom) a další způsoby ukládání dat, které lze zvolit pro řešení problému, není nutné a ani vhodné se při výběru přepínat jen mezi FS a SQL.

Relační DB potřebuje rozumět ukládaným datům (je velmi důležité správně zvolit datový typ a neodpustím si poznámku: fakt mi vstávají vlasy hrůzou, když někde vidí IPv4 uloženou jako VARCHAR (15), tedy 15B+značka velikosti na místo 32b INTu, 4B), umí záznam velice rychle adresovat i pomocí dalších klíčů (z klíčů vytvořených na základě obsahu dat, to FS vůbec neumí), umí efektivně (z hlediska rychlosti i z hlediska efektivity uložení) pracovat s velkým množstvím záznamů, umí transakční zpracování přes širokou řadu úkonů a s různými počty záznamů apod.

Databáze řeší konkurenční přístup (DB od svého vzniku musí řešit přístup a operace stovek klientů nad jedněmi daty, to se na FS většinou řeší pomocí zámků nebo pomocí šíleností jako jsou ta přejmenování z dočasného adresáře), práva (ale to i ten FS), garantované sekvence napříč klienty.

a ani nejsou výkonnější

To chce trochu upřesnit. FS je rozhodně rychlejší pro (střední a velká) sekvenční data. 1GB soubor se přečte rychlostí HW (disku, případně RAM), s tím bude mít DB (která to bude mít interně v 2kB blocích) trošku problém (ale zvládne to). Ale o tom se tu až tak moc nebavíme. FS není vůbec výkonnější při nevhodném použití jako DB (a to ani jako primitivní keyvalue). Například vyhledat všechny záznamy, ve kterých jsou data "Nick: Kit" DB zvládne levou zadní (pokud někdo nezprasil schéma), pro FS to bude znamenat progrepovat všechny soubory (čímž se zahodí původní stránky v IO cache (naplní se novými daty) a pak se další souboru budou muset číst opět z disku). Vůbec ta cache je hlavní devízou DB systémů.

Vždy záleží na konkrétním použití a konkrétním typu dat. Já nejsem přítelem různých adresářových stromů s tisíci soubory (jako je například i ten maildir), na toto FS ani není určený. A pokud se někdo chce vyhnout tomuto stromu a řešit si to sám v nějakých vlastních datových souborech, mno, to už je lepší využít 30let zkušeností špičkových světových programátorů a fakt to vrznout do DB.

---

Výběr vhodné technologie je těžká věc. Já jsem se (a klidně to přiznám) možná dostal do stavu, kdy mám v ruce kladivo (DB) a všude kolem vidím hřebíky. Na druhou stranu mi DB poskytuje výhody, které FS nikdy nenabídne, a vývoj (i FS, či spíše nástaveb) směřuje spíše k té DB. Souboru už máš dneska otagované (ten jeden přimární klíč už fakt pro uživatelskou práci nestačí), indexované podle obsahu (což je přesně to, co dělá každá pořádná DB) pro vyhledávání, různé media-library ti nabízí mnoho pohledů na jedna data apod.

[Kit]

FS poskytuje blok dat (adresovaný od 0 do filesize, přístup blokově a nebo streamem) a nezajímají ho ta data samotná (nerozumí obsahu souboru a ani se o to nesnaží). Je to nejrychlejší možný způsob,

Pokud má program data v nějaké struktuře v bloku paměti, tak jednoduše ten blok vysype do souboru. Staré 8bit, DOSové hry takto měli řešení ukládání herních pozic a některé programy to tak používají dodnes. Na velká sekvenční data (multimediální soubory například) je to ideální způsob uložení (i když by video šlo logicky rozdělit na jednotlivé framy a ty uložit pod nějakým pořadovým číslem do DB, tak toto by nepřineslo vůbec žádné výhody; najít ve velkém souboru konkrétní frame se umí i jinak a efektivněji).

FS také řeší rychlost přístupu k datům (velkých objemů) snižováním fragmentace a také snižováním seeků (pohyb hlaviček) u rotujících disků.

FS je rozhodně rychlejší pro (střední a velká) sekvenční data. 1GB soubor se přečte rychlostí HW (disku, případně RAM), s tím bude mít DB (která to bude mít interně v 2kB blocích) trošku problém (ale zvládne to). Ale o tom se tu až tak moc nebavíme. FS není vůbec výkonnější při nevhodném použití jako DB (a to ani jako primitivní keyvalue).

Připadá mi to jako hodně málo argumentů ve prospěch FS.

Když vezmu téměř libovolný větší soubor, tak vevnitř najdu databázi. Buď přímo jako databázový soubor, anebo serializovanou. Když nad serializovanou databází typu video chci provést střih, musím ji deserializovat, provést sloučení a výstup zase serializovat do nového souboru. Pokud do původního (přepisem - bez tempu), tak v určitém okamžiku mohu o data přijít. V případě databáze by se změnilo pár indexů k framům, vytvořily by se nové framy v místě nelineárního střihu a bylo by hotovo. Vše by se dalo udělat transakčně.

V praxi by se každý vkládaný soubor musel deserializovat, při jeho analýze by se zároveň udělala jeho případná indexace. Při exportu obráceně.

Výsledkem by mohl být systém, který by jako celek možná nebyl tak výkonný, ale při interaktivní činnosti by měl kratší odezvy. Také by mu stačilo méně RAM, protože by tam byla pouze data, která aktuálně potřebujeme.

Tuším, že v některých embedded systémech jsou podobné principy použity. Tedy jediná databáze, ve které jsou uloženy všechny informace v potřebné struktuře a tím je setřen rozdíl mezi FS a databází.

[pavlix]

Když nad serializovanou databází typu video chci provést střih, musím ji deserializovat, provést sloučení a výstup zase serializovat do nového souboru.

Dejme tomu, že i to video se dá tak v širším smyslu brát. Ale typicky se databáze vždy říkalo různým seznamům datových položek, přičemž video je spíš příklad streamu, datového proudu.

Důkaz hledej v použití (stejného) videoformátu na nonstop streaming, který už se ani vzdáleně databázi nepodobá.

Pokud do původního (přepisem - bez tempu), tak v určitém okamžiku mohu o data přijít.

Tady jste ale právě narazil na vlastnost, kde se databáze i soubor shodují (z důvodu toho, že databáze je uložena v souboru (případně oddílu, ale to je stejné).

Když přepíšete záznam v databázi (kusu souboru) in-place, bez dočasného úložiště (tempu), můžete o data přijít.

Takže tady máte ve srovnání chybku.

Tedy jediná databáze, ve které jsou uloženy všechny informace v potřebné struktuře a tím je setřen rozdíl mezi FS a databází.

Vzhledem k tomu, že se na FS dá nahlížet jako na databázi souborů a adresářů, a databáze se ukládá na FS v podobě souboru nebo na oddíl v podobě nějakého formátu, tak ve výsledu musí být úložné možnosti FS a DB nutně ekvivalentní.

[Kit]

Dejme tomu, že i to video se dá tak v širším smyslu brát. Ale typicky se databáze vždy říkalo různým seznamům datových položek, přičemž video je spíš příklad streamu, datového proudu.

Důkaz hledej v použití (stejného) videoformátu na nonstop streaming, který už se ani vzdáleně databázi nepodobá.

Stream má také nějakou strukturu, kterou je nutné při čtení parsovat. Databáze by tuto potřebu (z pohledu aplikace) odstranila.

Pokud do původního (přepisem - bez tempu), tak v určitém okamžiku mohu o data přijít.

Tady jste ale právě narazil na vlastnost, kde se databáze i soubor shodují (z důvodu toho, že databáze je uložena v souboru (případně oddílu, ale to je stejné).

Když přepíšete záznam v databázi (kusu souboru) in-place, bez dočasného úložiště (tempu), můžete o data přijít. Takže tady máte ve srovnání chybku.

Nesouhlasím. Většina databází má tuto vlastnost ošetřenu transakcí. Z pohledu aplikace je uložena buď stará, anebo nová hodnota.

Vzhledem k tomu, že se na FS dá nahlížet jako na databázi souborů a adresářů, a databáze se ukládá na FS v podobě souboru nebo na oddíl v podobě nějakého formátu, tak ve výsledu musí být úložné možnosti FS a DB nutně ekvivalentní.

A tady je ta má úvaha, zda má smysl vyvíjet nejrůznější datové kontejnery nebo by bylo lepší data ukládat rovnou jako relativně malé bloky dat (nody) do databáze a s těmi průběžně pracovat. Databáze by poskytla prostor i pro jejich strukturu.

[pavlix]

Stream má také nějakou strukturu, kterou je nutné při čtení parsovat. Databáze by tuto potřebu (z pohledu aplikace) odstranila.

Databázová knihovna by jistě neposkytla lepší rozhraní než knihovna pro daný formát.

Nesouhlasím.

To jistě můžeš, jen jestli bude tvůj nesouhlas dávat vůbec nějaký smysl.

Většina databází má tuto vlastnost ošetřenu transakcí.

Tak na to zkusíme důkaz sporem :). Shrneme si vaše tvrzení:

a) "Nesouhlasím"... interpretuju tak, že podle vás nelze ve filesystému použít transakce.

b) "Většina databází má tuto vlastnost ošetřenu transakcí."... omezíme se tedy na ty, které to umí.

A přidám jeden známý fakt:

c) Velká část těchto transakčních databází je implementována pomocí souborů ve filesystému.

Spor je doufám zřejmý.

A tady je ta má úvaha, zda má smysl vyvíjet nejrůznější datové kontejnery nebo by bylo lepší data ukládat rovnou jako relativně malé bloky dat (nody) do databáze a s těmi průběžně pracovat. Databáze by poskytla prostor i pro jejich strukturu.

Tedy celá otázka se od DB versus FS přesouvá k otázce granularity a datového formátu. Podle toho má pak smysl vybírat způsob uložení, ale šířeji než jen otázkou typu "FS nebo DB", která nedává bez bližší specifikace valný smysl.

[Kit]

Spor je doufám zřejmý.

Když aplikaci killnu mezi fopen se zkrácením souboru a printf, soubor bude prázdný nebo neúplný. Když ji odstřelím v průběhu databázového dotazu, transakce se provede nebo ne, ale data budou konzistentní.

[Heron]

Pavlix tě sice nachytal na logické chybě, ale pravdu máte v podstatě oba

FS sice neposkytuje transakce v DB slova smyslu, to je (tvoje) pravda, ale DB běží nad FS (to je pavlixova pravda). Takže DB musí využívat atomických (a synchronizačních) operací FS, aby byla schopna dosáhnout plně ACID chování.

Pochopitelně zcela totéž co DB může s FS dělat samotný program, takže o data nepřijdeš.

[pavlix]

Díky.

[pavlix]

Když aplikaci killnu mezi fopen se zkrácením souboru a printf, soubor bude prázdný nebo neúplný. Když ji odstřelím v průběhu databázového dotazu, transakce se provede nebo ne, ale data budou konzistentní.

Ani jednu z těchto vět ti nevyvracím, když porovnáš špatnou aplikaci (nebo špatný filesystém, to už je jedno) s dobrou databází, tak tvůj závěr nedává tak úplně smysl.

[Heron]

A tady je ta má úvaha, zda má smysl vyvíjet nejrůznější datové kontejnery nebo by bylo lepší data ukládat rovnou jako relativně malé bloky dat (nody) do databáze a s těmi průběžně pracovat. Databáze by poskytla prostor i pro jejich strukturu.

Toto mi už zase přijde jako extrém. Ta data mají nějaké využití a pro to využití je v drtivé většině případů čistě sekvenční přístup. A případné operace se také dějí s celými sekvencemi dat a nikoliv jen s několika (náhodnými) jednotlivými framy.

A je potřeba co nejvyšší sekvenční rychlost a v tom DB zrovna nevyniká. Takže takový databázový stroj by byl sice (uznávám) velmi univerzální, ale také velmi drahý (aby dosáhl stejného výkonu jako sekvenční soubor).

[Heron]

rec byla o skalovani

Ještě jsem si vzpomněl, pro pobavení, nechci nikoho urazit: Web Scale

[okbob]

I v takovém objemu existují úspěšná řešení postavená nad db - např. Skype a jeho design založení na plproxy a cca 300 nezávislých PostgreSQL serverů.

Co se tak pohybuji mezi vývojáři v ČR, tak jsem ještě nenarazil na situaci, kdyby tak masivní škálování bylo nutné. Z historických dob dokáží db relativně dobře obcházet limity filesystémů. I relativně velké nasazení db např. na zabezpečení sociálního systému FR se obešlo bez nějaké masivní replikace.

Tady v ČR vím o několika extrémně zatížených webových aplikacích běžících na jednom db serveru s replikou sloužící jako záloha. A běží bez problémů. V podstatě mne nenapadá jediná aplikace, zde v ČR, provozovaná, která by se nedala utáhnout relační db. Přičemž netvrdím, že relační db je na všechno ten nejlepší nástroj. Na řadu web aplikací, kde jsou izolované entity a kde se neprovozují komplexní datově analytické operace jsou NoSQL db vynikající věc. A na krátkodobá data je tu memcached.

Jinak samosebou, celé je to o tom, mít rozumně napsanou aplikaci.

[jkb]

u nas vzdy kdyz se strhne nejaka takova diskuze pgsql versus mysql, tak se vpodstate uvadi misto argumentu uz jen komentar kristiana köhntoppa - to je takovy nemecky guru v teto problematice. ( http://www.heise.de/ix/news/foren/S-Re-Kann-MySQL-eigentlich-irgendetwas/forum-188566/msg-19386125/read/ ).

V tom nemeckem textu je shrnuto, proc je pro masivni webove aplikace jeste porad potreba nasadit mysql. Kristian pracuje vlastne uz 10 let u firem, ktere prave nevystaci s jednim servrem - jeho soucasny zamestnavatel (booking.com) provozuje 87 slave a 1 master a tvrdi, ze by to s pgsql proste neslo.

Argumenty jsou:

- connect je laciny (mysql 200 kB, napr. oracle 5 MB) a neni nutne pouzivat Connection Pools a vystaci se s 2-Tier architekturou (Apache + mod_neco na MySQL)

- mysql skaluje read access horizontalne, t.zn. ze se jen pridavaji slaves pricemz replikace je defaultne asynchronni a v aplikace je ale mozno pres master_pos_wait() synchronni replikaci vynutit - coz se vyuziva tak, ze do te doby nez zakznik v shopu neco objednava se replikuje asynchronne a teprve v okmaziku objednavky se zapne synchronni replikace.

- dal je tam jeste asi 10 dalsich duvodu, kterym uprimne receno nerozumin.

Na zaver ale pise: Mysql neni hezka databaze, ale pracuje v tomto segmentu spolehlive a zejmena jednoduse , vyrozumnel jsem z toho, ze pro vyvoj se vystaci s 'prumerne' nadanymi vyvojari.

Za ty leta, co ctu ty jeho prispevky jsem nabyl dojmu, ze pro takove aplikace vpodstate neexistuje alternativa.

V cem s vami souhlasim, ze takove pripady patrne bude vicemene rarita. jestlize je v nemecku takovych pripadu 10-20, tak to muzete mit klidne pravdu, ze v CR by se nenasla jedina (vysvetloval bych si to velikosti trhu)

[Radim Kolář]

MySQL je ale pro OLTP ponekud pomale. Krom toho velke databaze Oracle a DB2 umi obsluhovat vice uzivatelu na 1 connection (Oracle shared server), vyrazne to zlepsuje odezvu serveru pri hodne uzivatelich.

[okbob]

Na dnešním hw (a cca pět let starém) lze napsat cokoliv. Alespoň to je moje zkušenost. Pokud se jedná o dedikované servery. Situace se lepší, ale pořád tu je ohromné množství špatně napsaných aplikací, kde neproběhla základní optimalizace. Já mám takovou zkušenost, že obyčejně není celá aplikace napsaná špatně - stačí odstranit několik málo hrdel a rozběhne se, problém je, že se o to málokdo snaží. Stále má řada aplikací ohromné rezervy ve výkonu, neb se nepoužívají prepared statements, málo kdo si udělá analýzu pomalých dotazů.

Ono i s PostgreSQL lze pracovat jednoduše. Možná jednodušeji než s MySQL. V tom problém není a nikdy nebyl. Zásadním faktorem byla neexistence komerční firmy, která by z PostgreSQL profitovala. Díky tomu existoval PostgreSQL pro řadu Unixů, BeOS, Novel ale dlouho neexistovala verze pro MS Windows. Zrovna tak replikační řešení, které existovaly bylo pouze externí. Chyběla propagace. Cílem komunity byl jiný segment než aplikace pro internet a také cílem není (i když to třeba někteří lidé nechápou) obsazovat, zabírat prostor - PostgreSQL bez problémů může koexistovat dohromady s MySQL, Firebirdem nebo SQLite. Pro pg je primárním cílem spolehlivost a úplnost podpory SQL, tak pro MySQL je tím primárním cílem rychlost. A cca před verzí 8.1 byl Postgres znatelně pomalejší než MySQL.

[Radim Kolář]

Spis je to otazka proc firmy prakticky neprodavaji support PGSQL, zatimco MySQL prodava kde kdo a navic je na to vice toolu. A kdyz neni support tak si to moc zakazniku nenasadi.

Interni nebo externi replikace, to je v zasade jedno. Technicky vzato DB2 ma 2 druhy externi replikace (MQ, ASN) a 1 interni (HADR). Problem je spis v nizke kvalite replikaci pro PGSQL, jsou to nedodelky. Co ja se se slony1 a skype replikaci natrapil. To slony1 je neuveritelne citlive na timing pri admin prikazech a kdyz se rozbije tak ze musi opravovat aktualizaci systemovych tablic neni mozne ho uz jakymkoliv prikazem dat doporadku snad s vyjimkou force uninstall

Ja navrhoval slony teamu aby se obslehla ASN replikace z DB2, ktera je velmi jednoduse navrzena (slovy 12 systemovych tablic) ve srovnani se slony1 a umi async multimaster a ostatni dulezite featury jako napriklad si vybrat pomoci WHERE ktere radky vlastne chci replikovat, transformovat replikovana data, replikovat views, replikovat LOB, jedna tabulka se muze replikovat vicekrat, neni potreba vytvaret rucne cilove tabulky, neni potreba obousmerne spojeni u serveru proste klasika navazovani spojeni cil -> zdroj. Ovsem priorita vyvoje slony1 neni udelat funkcni reseni ale zjevne vyblbnout se pri kodovani, takze prece nebudeme kopirovat deset let funkcni design, nakodime si slony 2.0 s minimalnim redesignem enginu, mozna to vyjde tentokrat, ze? Budto jsou to nekompetentni vyvojari kteri nedokazi poznat ze vysledek prace za moc nestoji nebo jim ego nedovoli obslehnout fungujici system. Smutny fakt je ze slony1 je stale nejlepsi replikace, ta z pg 9 je dost nestabilni, to snad netestoval nikdo.

MySQL pochopilo potreby LAMP uzivatelu, dalo jim to co potrebovali a proto se tak rozsirilo i pres svoji nekvalitu. Je to sice nekvalitni databaze, ale uspesne resi jejich problemy (napr. query cache je velmi dobra pro LAMP) a proto ji pouzivaji. Dostanou od ni to co ocekavaji.

PostgreSQL proste nedokaze vyresit problemy podnikovych uzivatelu a ani LAMP uzivatelu a proto se rozsiril do techto oblasti minimalne. Pravda pokusy tu byly - Great Bridge, Sunem podporovany Pgsql. Dnes tu mame EDB, ta ale tezi predevsim z Oracle kompatibility. Ty jejich add-on pro pgsql za ty penize co za ne chteji nestoji.

PGSQL team proste nechape pozadavky podnikovych uzivatelu. Vzhledem k tomu ze se jedna o OSS projekt tak oni je ani chapat nemusi protoze nejsou zavisli na financovani od nich. Dokud se nestane komercnim subjektem jako bylo mysql tak na pozadavky zakazniku bude vzdy kaslat.

1. User friendly administrace
2. prehledna dokumentace
3. kvalitni drivery
4. Knizky
5. Skoleni
6. Podpora od velke firmy
7. Kompatibilita s existujicimi SQL databazemi pokud je to mozne
8. Poradne udelana Replikace + Fulltext
9. Transakce ze stored procedur

[okbob]

Ona se dost těžko konkuruje cenou, když kvalitní podpora je gratis. Tudíž všechny pokusy o takovou podporu zkrachovaly. Můžu se vyjádřit jen k některým bodům - ještě bych váš seznam pojmenoval Kolářovy požadavky (nikoliv požadavky uživatelů). Sleduji konferenci, a na některých věcech i pracuji, takže mám docela přehled, co uživatelé chtějí. Jde spíš o zaměření - pg je pro uživatele, kteří chtějí funkční databázi, nikoliv pro DBA, kteří chtějí ohromovat svými znalostmi.

1. nekomerční pgAdmin, komerční EMS Admin

2. tak nevím, to je subjektivní, co Vám chybí v dokumentaci?

3. chybí dotažený driver pro Javu, .NET driver je kvalitní - nejsou kvalitní vývojáři v Javě, případně sponzoři

4. kvantita není kvalita - teď je k dispozici několik kvalitních knížek

5. školení je dost - tady v ČR: GOPAS, iinfo, já, rozhodně je to větší nabídka než pro DB2, plus tato školení jsou v rozumné cenové relaci.

6. Dnes EnterpriseDB, existuje několik menších firem, pro velké firmy je pg nezajímavý (minimálně český trh).

7. Jakou kompatibilitu nabízí MSSQL, Oracle, DB2? Cílem pg je podpora ANSI SQL

8. Fulltext funguje tak že se používá i na relativně komplexní vědecké projekty, replikace je na začátku (vestavěné řešení). Jinak replikace poskočila dál, běžně se používá.

9. Tu bych taky rád, nicméně nedaří se mi sehnat dostatečnou podporu ani pro procedury. Reálně, až na pár výjimek to nikdo nechce, a ti co by to chtěli nejsou schopni provést nebo zaplatit vývoj (je to cca 6měsíců na fulltime .. 300-400 tis). Navíc to lze snadno obejít aplikačním kódem.

[jkb]

no, ja bych pana Kolare doplnil o jednu praktickou zkusenost (ovsem z roku 2006 - ono se vse vyviji).

Muj byvaly kolega byl u migrace webu jednoho velkeho zasilkoveho obchodu (400 tisic navstevniku denne). Puvodni system bezel na SUN s 24 procesory a sybase. To fungovalo, ale sybase chtela udelat update, tak se rozhodli to vymnenit. Nabidky bylo i od oracle a ibm, ale nakonec vyhrala mysql. Na jednani prileteli 2 panove ze Svedska a uz cenove to nemohl nikdo odmitnout. Vykopli SUN a za ten mesicni pausal nakoupili 30 linux slaves a 1 poradny linux master a ty odpovidajici licence. Mysql s nima udelala 24/7 smlouvu vpodstate s okamzitou reakci.

Panove od mysql take skutecne u nekolika problemu museli zasahnout a dokonce udelali pro ten zasilkovy obchod nekolik specialnich zmen v kodu.

To vse svedci o tom, ze mysql v techto situacich dokaze udelat proste adekvatni nabidku i v konkurenci s temi velkymi a to je podle me ten rozdil proti pgsql. Vim, ze tenkrat jeste neexsitovala zadna verohodna firma, ktera by mohla nabidnout seriozne takovy servis. A myslim, ze dnes je to i nadale tak. Ono je sice dost mensich firem, ktere 'take' nabizeji podporu pro pgsql, ale tyto firmy jsou prilis male na to, aby to s nima nejaky vetsi zajemce risknul.

[okbob]

Tomu já docela rozumím, a jelikož si nemyslím, že dojde ke změně, tak mohu jedině se snažit popsat jak to chodí. Databáze jsou ohledně vývoje extrémně drahé a v podstatě už neexistují malé nebo středně velké firmy, které by vyvíjeli vlastní SQL databáze. MySQL a.b. byla jedna z posledních - a i při pokrytí, které měli, tak v podstatě museli skončit. Všimněte si, že žádná z firem, která ještě dodává db už nemá primární byznys vývoj db.

V PostgreSQL jsou tyto rizika a náklady rozložené. Díky tomu vývoj PostgreSQL pokračuje. Kdyby PostgreSQL mělo fungovat na tržních principech, tak už by vývoj dávno skončil. Tak jak skončila MySQL a.b. Z toho komunitního vývoje pak ale plynou určitá omezení. Chybí marketing. Je jasné, že core vývojáři nebudou předělávat PostgreSQL podle požadavků nějakého zákazníka. Vše co jde do jádra musí mít všeobecný přínos. Na druhou stranu je s tím počítáno jak licenčně tak interně. Není problém vzít pg, upravit jej a prodávat. Není problém vytvářet doplňky pro PostgreSQL - v pg je řada hooků, které umožňují s pg dělat psí kusy. Pg má nádherný interface pro vytváření doplňků. V pg docela příkladně funguje oprava chyb - opravdu není výjimkou, že je nahlášená chyba opravena do 48 hodin. K dispozici je fakt kvalitní dokumentace. A to je všechno zadarmo. Resp. náklady jsou rozpuštěny mezi cca stovkou firem a všechny ostatní používají pg grátis nebo téměř gratis. Je jasné, že tento model nemusí vyhovovat všem. Prostě tam nefunguje "mám peníze a chci tohle", nebo ještě lépe - "nemám peníze a chci tohle". I když pošlete kód, tak se ještě dlouho profiluje a dolaďuje.