Vlákno názorů k článku
Odlehčené MySQL
od Ondřej Tůma - Jak nemam rad takove ty reci jak toho...
-
Jak nemam rad takove ty reci jak toho mysql moc neumi a jak db neni jen uloziste dat a pod.. tak ted se musim rict ze v podstate to co z mysql dela rozumnou db, to z ni odstrani ... i kdyz, nastesti jde jen o fork a jako takovy urcite najde sve uplatneni, nicmene na web-hostingovych serverech to asi nebude :) -
Franta Kučera (neregistrovaný)
Tam je zbytečný mít nějakej obří databázovej systém.
A ty takové věci provozuješ na nějakých 486 počítačích nebo jiných šunkách, že potřebuješ něco extra light? Mně spíš přijde zbytečné se rozčilovat s MySQL, když můžu nasadit něco robustnějšího (a stále open source) s větší rozšiřitelností do budoucna. Protože výkon ušetřený odlehčenou DB je na dnešním železe zanedbatelný. -
Franta Kučera (neregistrovaný)no, přečti si, na co jsem reagoval:
databází, která běží na nějakým intranetu, má 5 tabulek a nad sebou webovou aplikaci, kterou navštíví pár desítek lidí denně. Tam je zbytečný mít nějakej obří databázovej systém.
Jasně, že se najdou případy, kdy je potřeba šetřit každou desetinu procenta výkonu, pak si třeba napíšeš/přepíšeš vlastní DBMS. Ale ve většině případů (jako např. ten, na který reaguji) není výkon to nejdůležitější (železo je levné a předimenzované) a klade se větší důraz na funkcionalitu, bezpečnost, dostupnost, rozšiřitelnost v budoucnu, cenu vývoje (drahá práce programátorů)... IMHO všelijaká odlehčená řešení přinesou z dlouhodobějšího hlediska víc škody než užitku. -
janforman.com (neregistrovaný)To je relativní já se raději přehrabuji v odlehčeném řešení než v tom co je nainstalovaný na jedno kliknutí. V tom univerzálním chaosu se špatně hledá. Tudíž pro mě je odlehčené řešení mnohem užitečnější. To jako "jednodušší řešení" je ve výsledku pro mě postupem času mnohem větší problém a starost. Všechno to jednodušší vypadalo vždycky strašně hezky, ale pak jsem potřeboval tohle a tamto a najednou jsem zjistil že trávím čas tím že ladím to "jednodušší" řešení přitom "složitějš" to šlo mnohem rychleji.
-
anonymní"Všechno to jednodušší vypadalo vždycky strašně hezky, ale pak jsem potřeboval tohle a tamto a najednou jsem zjistil že trávím čas tím že ladím to "jednodušší" řešení přitom "složitějš" to šlo mnohem rychleji."
pripisal by som to nedostatocnym skusenostiam. Ako dlhorocny vyvojar viem, ze odlahcene verzie su nanic. Pocase zistis, ze ti nieco chyba a co musis ? No predsa zmenit software. Naco veci robit na dva krat ked sa to da naraz ? Triggre, pohlady, ulozne procedury, funkcie, vsetko su to veci velmi uzitocne pokial stavas nieco co ma viac ako 20 tabuliek 8-) (samozrejme podobne veci sa daju vyuzit aj ovela mensich projektoch a tym odlahcit aplikacnu logiku na uroven databazovej) -
Rejpal (neregistrovaný)
Pro Vás jsou všechny databáze relační servery? Usuzuji tak ze zmínky o triggerech, pohledech, uložených procedurách a funkcích, které jsou třeba u embedded aplikací no-brainer, protože pak ta data prostě máte při ruce a všechny jmenované věci máte v dolní vrstvě aplikačního kódu.
Píšete, že jste dlouholetý vývojář. Dělal jste někdy více, než jednoduché aplikace. :-) Nemám na mysli velké versus malé, spíš jednoduché versus složité. Pak byste zjistil, že třeba databáze pro EDA software, storage adresářové služby, storage pro search engine a podobné věci mají úplně jiné nároky. V tu chvíli Vám žádný Oracle nepomůže.
Dlouholetí vývojáři některých typů aplikací zase "vědí", že "relační databáze jsou na nic". Samozřejmě že to není pravda a relační databáze na něco jsou. Jsou na spoustu věcí, dokonce bych řekl, že takových devadesát procent aplikací se do nich bez problémů narve. Jenže ty vlastnosti, jaké mají, mají jen díky hloupoučkému datovému modelu. (Nebo spíš metamodelu? :-)) Ten když člověku vystačí, tak nemusí sahat jinam, ale když se do něj nevejde, a potřebuje takové věci, jako složitější algoritmy (stromy, grafy...) nebo vysoký výkon, tak opravdu nemá smysl lámat data přes koleno a cpát je do tabulek. Případně je tu zase ta oblast "jednoduché a malé" a pak ten MetaKit nebo Tokyo Cabinet pořád bude jednodušší řešení, protože se kvůli tomu nemusí instalovat server, a je to v daném režimu i rychlejší. Někdo holt patří do těch deseti procent.
-
Rejpal (neregistrovaný)
Dokumentace k Interbase 6 tvrdí, že Interbase 6 je na stroji třídy Pentium Pro použitelná pro zhruba sto padesát uživatelů používajících "běžné interaktivní aplikace" (asi aplikace typu POS a podobně). Nepředpokládám, že by výkon Firebirdu od té doby nějak výrazně poklesl. Sice tedy nějaké funkce přibyly, ale zase na druhou stranu vylepšili optimalizátor, takže by to mohlo být tak nějak nastejno. Aspoň pár uživatelů by určitě na 486ce mohl zvládnout. :-)
Jinak, pokud jde o "odlehčené databáze" (asi to mělo být spíš "specializované"?), věřím, že určitě smysl mají. Ale musíte vědět, co potřebujete a proč to tak děláte. :-) Jinak můžete třeba při nevhodném použití DataDraw nebo Tokyo Cabinetu místo SQL databáze pohořet úplně stejně, jako když u jiných aplikací zase místo DataDraw nebo Tokyo Cabinetu použijete SQL databázi. :-)
-
Mard (neregistrovaný)Tady nejde ani tak o jednoduchost databáze jako o režii zpracování. Když jde o webový server, který má hodně "databázových" aplikací (typicky eshopy), tak je přínosem že databáze nebere drahocenný čas procesoru ve velké míře. Kdo by chtěl kupovat stále novou pamět a rychlejší CPU, že ano.
-
janforman.com (neregistrovaný)No on ten obří databázovej systém ani nemusí bejt o moc rychlejší. Používám ORACLE a nějak moc rychlé mi to teda nepřijde. Mnoho funkcí navíc to ano, určitě šikovných, ale že by to bylo rychlejší? Možná v clusteru... Co je velké množství dat? 1TB? Pár miliónů záznamů, to klidně MySQL zvládne. Horší asi bude používání JOIN apod. Jinak ORACLE se hodí tam kde je třeba 100% integrita dat (banky).
-
anonymníNejak nechapem tomu prispevku, SQLite sa uklada priamo na tvojom vyhradenom mieste na webovom serveri. Cize databaz mozes mat kolko len chces pod velkou hrbou rozdielnych uzivatelov :)
Ak si myslel Uzivatelske prava priamo na pristup do samotnej databazy, tak je rec o inom. Nebolo to jasne rozlisitelne co prave myslis :) -
Ne opravdu sem si nechtěl plivnout na SQLite a ani sem to neudelal. Ten projekt se me moc libi z mnoha duvodu, vedle rychlosti to jsou i moznosti, resp. mnozstvi veci co SQLite umi. Krouzim okolo nej jiz hodne dlouho. To kde je problem pro nasazeni je v podstate situace kdy do jedne db zapisuje třeba 10 uživatelů najednou a dalších 10 z ní čtou. I kdyby tato situace nikdy nenastala, musí se řešit cosi jako hlídaní kolizí. A všude sem se dočetl / bylo mě sděleno že na toto prostě není SQLite stavěnej.
To rozhodně nesnižuje jeho kvality - spíše asi naopak, ale musím říci, že pokud by existoval nějaký SQLite server - ve smyslu serverová nadstavba pro klient-serverový režim, myslím že by MySQL velmi rychle předběhla.
A to je na co sem narážel. A při tomto faktu si nedokážu pořádně představit jak se řeší přístup do jedné takové SQLite db ve webových aplikacích, protože právě tam k těm kolizím dochází.
PS: už několikrát sem řešil srozumitelný výstup z mnoha vláken do jednoho streamu tak aby se vlákna nepředháněli, proto mě zajíma jak na to... -
jenda (neregistrovaný)mate pravdu a je smutne, ze prave pan Ponkrac se nechal strhnout k takove trapne poznamce (asi skutecne nerozumi uplne vsemu). To co pisete je uplne opravnene, po celem svete se v diskuzich k tomuto tematu objevily poznamky v tom duchu, ze na to prece existuje sqlite a temto povrchnim kecalkum, kteri chteji proste jenom ukazat, ze take uz neco zaslechli, muselo byt vysvetleno ze:
- to s rychlosti neni tak ruzove
- v konkurencnim prostredi je mozno sqlite jedoduse zapomenout
Ja jsem sam sqlite testoval a zajimala me rychlost a vysledky byly, ze je to na tom samem stroji max. tak rychle jako mysql nebo postgresql.
Muzu vam poradit, nechte to byt. (to ani nemluvim o tom paskvilu, co se jmenuje sqlite-ODBC-Driver :-)) -
Omlouvám se, opravdu se omlouvám a sypu si popel na hlavu. Bohužel se vyskytuje hodně lidí, kteří leccos odsoudí, přesto to mojí ostrou reakci nikterak neomlouvá.
sqlite není jednouživatelský, on je jednoprocesový. Pouze jeden proces může zapisovat, více procesů číst. Na webu to ovšem nemusí vadit.
sqlite není velká databáze, původně je to jednoduchá souborová databáze, která díky promyšlené architektuře se stala velmi dobrou ve své třídě. a její obrovská přednost, které nemohou mysql ani postgresql konkurovat je také volnost a otevřenost licence sqlite
sqlite není porovnatelná rychlostně s jinými db už proto, že je dost zvláštní - viz třeba zbytečnost datových typů pro sloupce, apod.. Jinak podle benchmarků je pro jednoduché operace (tj. pro které byla sqlite stvořena) sqlite výrazně rychlejší, než postgresql, a mírně pomalejší, než mysql. sqlite výrazně dobře zachází s indexy, takže jednoduchý select/insert/update s indexy je rychlejší, než u mysql a postgresql. sqlite zpomaluje u dotazů typu join, kde sqlite verze 3 udělala obrovský rychlostní skok nahoru, nicméně je za mysql a postgresql.
Takže záleží co jste vlastně porovnával, protože říct, že je sqlite nějak rychle proti mysql, atd.. bez uvedení toho co jste testoval a jak jste testoval je k ničemu. Naprosto a totálně k ničemu - jen závadějící informace. -
:) Ok :)
Vyhody sqlite vidim hlavne v momente, kdy chci udelat nejakou jednouzivatelskou aplikaci a data nechci sdilet s ostatnimi - databaze kontaktu na pda a pod... ci jaka-koli jina db, ke ktere je zbytecne provozovat nejaky server a zaroven je skoda vymyslet nejaky format na ukladani tech dat, kdyz tu mame SQL.
Nicmene pouziti u webove aplikace me prijde podobne jako kdybych mel webovy server, ktery by dokazal obslouzit pouze jednoho uzivatele v jednom okamziku ( a vim ze to porovnani hodne pokulhava). -
Takže znovu: sqlite nedokáže obsloužit jenom jednoho uživatele. Dokáže pouze zapisovat z jednoho procesu, číst z mnoha. Zároveň je ale sqlite multithreadová, důsledky si dovodíte. Důsledky jsou ty, že sqlite dokáže obsloužit mnoho uživatelů naráz. Pokud máte třívrstvou aplikaci, pak často přistupuje k celé databázi jeden proces.
Jinak sqlite je embedded databáze, a v této kategorii tvrdě vyčuhuje jako špička. Tak byla dělaná, a i její monožsti konkurenčního přístupu v porovnání s jinými embedded jsou naprosto vysoce nadprůměrné - je v tomto suverénně nejlepší ze všech.
Jinak zvláštní, že sqlite se na webové projekty běžně používá, takže někde budete mít v úvahách asi chybu. -
Franta Kučera (neregistrovaný)
Pokud máte třívrstvou aplikaci, pak často přistupuje k celé databázi jeden proces. ... Jinak zvláštní, že sqlite se na webové projekty běžně používá, takže někde budete mít v úvahách asi chybu.
Zajímalo by mě, kde vidíš ten přínos* při tomto použití sqlite oproti "klasické" třívrstvé architektuře s běžnou serverovou relační databází (MySQL, PostgreSQL, Oracle...), kdy se použije connection pooling a nemusím řešit z kolika procesů kam přistupuji a jestli dělám zápis nebo "jenom" čtení a tohle všechno za mě řeší middleware a vyspělý SŘBD. Neříkám, že nejde napsat webovou aplikaci nad sqlite, ale nějak vidím jen ty nevýhody a přidělávání si práce, než nějaké přínosy. Snadl leda, že bych chtěl jako webový server použít PDA :-) *) pokud myslíš, že je to přínosné. -
"Zajímalo by mě, kde vidíš ten přínos* při tomto použití sqlite oproti "klasické" třívrstvé architektu..."
Takto položené dotazy neberu vážně. Už jen proto, že bez konkrétního popisu projektu mě přijdou podezřelí lidé, kteří přesně ví, co je VŽDY lepší. Ve skutečnosti je někdy lepší to, někdy je lepší pravý opak. Protože záleží na podmínkách. Jsou projekty, kde bude 1000x lepší a přínosnější sqlite, a jsou projekty, kde bude lépe na ní zapomenout. A to platí o každé technologii. -
Stačil by mi nějaký příklad, kdy by bylo lepší na webu použít sqlite místo klasiky MySQL/PostgreSQL. Mě napadají jen extrémní případy typu toho PDA nebo třeba nějakého routeru (běžícího na minimalistickém HW), ke kterému chci udělat webové rozhraní. Tak tam možná, ale pokud má člověk k dispozici normální železo (PC 1 GHz / 1 GB a více), tak si moc nedovedu představit, co by mi to sqlite přineslo. -
Tím, že využijete drobného rozdílu - sqlite je soubor, zatímco mysql/postgresql je služba.
Tím, že využijete drobného rozdílu, že sqlite je public domain - což znamená jeho využití i na projekty, kde MySQL je za předražené peníze, které je naprosto zbytečné platit. I licence sw je třeba sledovat a dělat projekty právnicky čisté - krást se nemá.
A PostgreSQL je mimo unix systémy v podstatě nepoužitelná (není tak dlouho co byla v menuálu PostgreSQL poznámka, že nehodlají pro Windows port ani hnout prstem, pokud to vůbec nějak, byť i chatrně chodí - ale tuto poznámku asi museli smáznout).
PostgreSQL je příliš zbytečný kanón pro spoustu projektů, a je zbytečné mít něco tak mohutného.
Na běžných hostinzích máte většinou v ceně MySQL a sqlite - PostgreSQL bývá ze hry. -
Jan Molič (neregistrovaný)Přesně tak. SQLite nebyla navržena, aby nahradila MySQL.
Je to souborová databáze. Její výhoda plyne právě z toho. Můžete ji libovolně kopírovat ze stroje na stroj (a to i emailem :-D ), což mnohem hůře uděláte s MySQL -> a o to jde.
Jakožto souborová databáze se hodí pro podobné účely, k nimž jsou navrženy jiné souborové databáze, například ty konstantní (CDB, TDB, GDBM, apod.) Sice není stejně rychlá, ALE umí SQL, a nejen jednoduché SQL -> a o to jde.
Využití proto vidím spíše v programech. Třeba Amarok ukládá do SQLite informace o vaší kolekci mp3. Sice poznáte rozdíl při aktualizaci kolekce (zápisu do db), pokud namísto SQLite začnete používat MySQL, ale při čtení je podobně rychlá. A hlavně, nejste se svým hudebním přehrávačem závislí na běhu MySQL - a o to taky jde :-) -
Franta Kučera (neregistrovaný)
To kde je problem pro nasazeni je v podstate situace kdy do jedne db zapisuje třeba 10 uživatelů najednou a dalších 10 z ní čtou. I kdyby tato situace nikdy nenastala, musí se řešit cosi jako hlídaní kolizí. A všude sem se dočetl / bylo mě sděleno že na toto prostě není SQLite stavěnej.
Nemá cenu vymýšlet nějaká obskurní řešení, na web prostě je potřeba SŘBD, který podporuje víceuživatelský přístup - tudíž o jednouživatelských, byť kvalitních, databázích nemá cenu uvažovat. Vraťme se ale k původnímu tématu: předpokládejme, že máme MySQL, nějaký průměrný dnešní HW a běžnou webovou aplikaci. Co nám přinese přechod na odlehčené MySQL, které je osekané o spoustu funkcí? IMHO prakticky nic. Naopak nám ještě omezí možnosti do budoucna, zkomplikuje další rozvoj aplikace. Pro další rozvoj bude potřeba změnit DBMS, místo aby stačilo připsat trigger, nebo využít jinou pokročilejší funkci databáze. Když už uvažovat o změně, tak spíš směrem nahoru - třeba PostgreSQL. Ale taky si může člověk naběhnout, jako se to stalo mně s Drupalem - musel jsem se vrátit k MySQL, protože PostgreSQL nebylo dostatečně kvalidně podporované (jádro trochu fungovalo, ale hodně důležitých modulů bylo ušitých na míru MySQL).To rozhodně nesnižuje jeho kvality - spíše asi naopak, ale musím říci, že pokud by existoval nějaký SQLite server - ve smyslu serverová nadstavba pro klient-serverový režim, myslím že by MySQL velmi rychle předběhla.
V čem by ho předběhla? Ve výkonu, který dnes kvůli předimenzovanému HW hraje často velmi malou roli? V kvalitě? Tam možná, ale přechod z MySQL na "SQLite Server" by většinou* znamenalo přepsat aplikaci - což je jednak hodně práce a jednak, když už to přepisuju, tak to můžu přepsat na jiný DBMS, který už teď existuje a je dostatečně prověřný praxí. *) pokud si autor nedal tu práci a nenapsal aplikaci přenositelnou, nepoužil něco jako JDBC případně nějaké ORM atd. (Na což velká část PHP kodérů dlabe a používají funkce specifické pro MySQL) -
"Ve výkonu, který dnes kvůli předimenzovanému HW hraje často velmi malou roli?"
Mezi námi, proč tedy se velice slušně uplatňuji při optimalizaci velmi přetížených databází, které spolu s velmi výkonným hw nestačí? Proč jsem si tímto vydělal slušné peníze?
"pokud si autor nedal tu práci a nenapsal aplikaci přenositelnou, nepoužil něco jako JDBC případně nějaké ORM atd."
Málokterý program, který skutečně databázi využívá (a tím spíš, pokud píšete triggery, které tu propagujete jako potřeba) je skutečně databázově přenositelný. Navíc přenositelnost a ORM jsou obrovské žrouty výkony a přes veškerou snahu špičkový výkon databáze házejí dost dolů a zátěž databáze a stroje hodně nahoru.
Je zbytečné v 99,99% případů vůbec psát projekt databázově přenositelný, protože to přinese spíš mínusy, než plusy. A pokud potřebujete špičkový výkon a vyždímat vše (což i u velkých webových projektů často honíte db na maximum), tak je to absolutní nesmysl. -
Mezi námi, proč tedy se velice slušně uplatňuji při optimalizaci velmi přetížených databází, které spolu s velmi výkonným hw nestačí?
Asi hlavně proto, že někdo neumí psát selekty, nebo ta databáze měla mizerného architekta, což znamená špatný návrh tabulek, chybějící nebo špatné indexy atd. Optimalizovat se dá kde co od sqlite po Oracle, ale změnou DBMS* se těžko ušetří tolik výkonu, jako změnou v datovém modelu a přístupu k datům (bez ohledu na DBMS). V tomhle jsou právě lepší ty vyspělejší SŘDB oproti těm odlehčeným, protože skýtají prostor pro pozdější zlepšování a optimalizace - funkce, které zpočátku vypadaly zbytečné se nám najednou mohou hodit. Zatímco u těch odlehčených SŘDB se člověk už na začátku pohybuje na hranici jejich možností. *) např. z MySQL na nějaké odlehčené MySQL očesané o potřebné funkce, nebo snad na sqlite -
Dobre konkretni pripady:
pocitani cisla v rade je na urovni db mnohem rychlejsi (rekeme takovy auto_increment, ale s nejakou logikou) - at uz procedura nebo trigger
pohledy pravda sem pouzil jen pro specialni ucely, neb sem nemoh poradne definovat join tabulek, a ona to nebyla tak docela web aplikace, jen spis web rozhrani k necemu jinemu.
Ale napisu to jeste jinak, prave ze u web aplikaci (ne jen insert a nasledny select) jde hodne o ulozeni aplikacni logiky v db, protoze pri vetsine aplikaci jde o jen php front-end, kterej toho sice muze umet dost, ale pokud jde o multi-uzivatelskou aplikaci hodne vytezovaneou (desitky pristupu v jeden okamzik), tak uz se pracuje s datama nejen v php preci jen podstatne hure.
ČLÁNKY DO MAILU