Moje odkazy
Humbuk kolem „noSQL“ databází
vydáno: 1. 4. 2010 15:00, aktualizováno: 11. 12. 2013 17:31
Poslední dobou se často diskutuje o tzv. noSQL databázích. Jedná se o hodně široký pojem, který zastřešuje v podstatě všechny databáze kromě SQL – většinou se ale pod tímto pojmem v diskusích rozumí užší skupina databází typu CouchDB, MongoDB nebo Redis. Proč by nás takové databáze měly zajímat? Předpoklad je jednoduchý: omezíme funkcionalitu databáze a tím získáme lepší výkon. Funguje to – naměřené čtecí/zapisovací operace za vteřinu jsou skutečně úctyhodné. Ale…
Jelikož tyto databázové systémy nemusí řešit věci jako ACID (spolehlivé transakce), referenční integritu, uživatelská oprávnění atd., jejich hrubý výkon je skutečně výrazně lepší než u robustních relačních databázích. Je ale potřeba vyvarovat se srovnávání nesrovnatelného.
Nepotřebná funkcionalita?
Otázkou ale je, zda funkcionalita, kterou tyto databáze vypustily, je skutečně nepotřebná, nebo zda se pouze přesune na úroveň aplikace. Bohužel to často dopadne tak, že vývojáři z prvotního nadšení vystřízliví ve chvíli, kdy zjistí, že tuto chybějící funkcionalitu budou muset suplovat v kódu své aplikace.
Potíž není jen v tom, že znovu vynalézáme kolo – což nás stojí čas a peníze (např. píšeme v aplikaci kód pro ošetření atomicity určitých operací, místo abychom jednoduše použili kód obsažený v relačním SŘBD, který za nás napsal někdo jiný). Potíž je i v kvalitě výsledného produktu – databázové systémy vyvíjejí ti nejlepší programátoři desítky let a tyto systémy se důkladně testují – zatímco aplikaci vyvíjejí průměrní programátoři třeba půl roku. V rámci běžného projektu je potřeba stíhat termíny a vejít se do ceny – není zde příliš prostoru pro vymýšlení úžasných nových řešení, psaní vlastních transakčních monitorů atd. V případě, že chybějící funkcionalitu musíme suplovat v aplikaci to většinou dopadne špatně – kvalita takového aplikačního kódu je řádově horší než kvalita kódu vyspělých relačních databází – tím pádem zabijeme i ten skvělý výkon, protože noSQL databáze je sice rychlá, ale naše aplikace je pomalá, neefektivní. Výsledek je tedy horší než při použití „pomalé“ relační databáze a tenké aplikace, která řeší jen obchodní logiku a ty „servisní“ věci nechává na databázi nebo aplikačním serveru. Ze stejných důvodů si obvykle nepíšeme vlastní operační nebo souborové systémy.
Paralela s assemblerem
Od příznivců noSQL často uslyšíte argument jako je tento:
„Úhel pohledu se asi změní s velikostí projektu. Představte si, že píšete třebas twitter, FB nebo google.“
A v tom je zakopaný pes – kdo z diskutujících bude psát aplikaci jako je Twitter? Jen pro představu: Twitter dnes obsahuje přes 11 miliard zpráv (tzv. tweetů), tudíž 11 miliard záznamů v nějaké databázi. Slovy neoblíbeného politika: Dámy a pánové, nechci se vás dotknout, ale kdo z vás to má? :-) Troufám si tvrdit, že nikdo z účastníků těchto diskusí nepíše takové aplikace – což jim ale nebrání v tom, do krve se hádat.
Tyhle úžasně rychlé databázové systémy jsou něco jako assembler – ten je taky úžasně rychlý a nenese s sebou žádnou „zbytečnou“ režii jako třeba C, C++ nebo nedejbože Java. Ale kdo z nás používá assembler? Kdo píše např. kodeky nebo vysoce optimalizované implementace šifrovacích algoritmů? Assembler má svoje opodstatnění a smysluplné využití – stejně jako ho mají noSQL databáze – s tím nemá cenu polemizovat. Nicméně se jedná o okrajovou záležitost. A nemyslím okrajovou ve smyslu významu nebo snad ve smyslu platového ohodnocení takových programátorů – ale okrajovou ve smyslu četnosti výskytů smysluplného využití.
Rozdíl mezi assemblerem a noSQL je v tom, že assembler je už vyčpělé téma, o kterém nemá příliš cenu psát články do časopisů, zatímco noSQL je relativně novinka, která navíc přitáhne čtenáře (provokativní téma budící emoce), tudíž psát o něm články smysl má (návštěvnost se počítá). Čtenář by se ale neměl nechat zmást a měl by si být vědom toho, že prostor věnovaný noSQL v médiích a diskusích je nepoměrně vyšší než odpovídá reálnému využití těchto technologií.
Odkazy a zdroje:
- noSQL vs. SQL – diskuse na Zdroják.Root.cz
- Lehký úvod do CouchDB – článek na ABC Linuxu
- How Fast is Redis? – hrubý výkon: cca 110 000 SET a 81 000 GET operací za vteřinu
- noSQL – Wikipedia
- ACID – Wikipedia
- SQL Výuka – program na výuku jazyka SQL
- eXist – dost zajímavá noSQL databáze – XML databáze
Témata: [databáze]
Komentáře čtenářů
noSQL databáze se často vyznačují tím, že jsou tzv. bezschémové, což znamená, že není definované databázové schéma (model) a jsou pouze data. Přidám tedy jeden svůj starší komentář k této věci:
Docela by mne zajímal scénář zaškolení nového kolegy nad danou bezschémovou databází (nebo co bude dělat stávající programátor, když byl pár měsíců mimo projekt a teď v něm má v programu něco předělat). V případě relační databáze dostane nováček ER diagram nebo nějaký jiný pěkný obrázek, pochopí a brzo se může zapojit do pracovního procesu (což je žádoucí – žádná firma nechce platit lidi, kteří se musí dlouho rozkoukávat a neprodukují žádnou hodnotu). V horším případě, pokud model nijak zachycený nemáme, nebo je zastaralý, nováček se podívá na relační databázi v nějakém chytřejším klientovi, zjistí, jaké tam jsou tabulky, z popisů (které by tam měly být) zjistí, co znamenají, z cizích klíčů zjistí vazby mezi nimi… V případě bezschémové databáze bude dělat co? Má si nastudovat zdrojáky a z nich se snažit vydedukovat strukturu databáze? Nebo se podívat přímo na data, kde ale platí, že:
With CouchDB, no schema is enforced, so new document types with new meaning can be safely added alongside the old.
takže tam bude asi pěkný guláš a moc z toho nevykouká. Leda že by si projel všechny dokumenty a zjistil, které jsou „new“ a které „old“ případně nějaké úplně jiné, rozdělil si je ve své hlavě na nějaké skupiny a snažil se zachytit jejich struktury.
Přijde mi, že si tu někdo pod snadností úprav představuje jen úpravy měřené počtem řádků případně absenci nutnosti měnit schéma. Jenže snadnost úprav je něco víc – nejdřív totiž musíme nějak přijít na to, jaké řádky kódu a jak budeme měnit. A tenhle proces může být daleko zdlouhavější, než samotné napsání té pár řádkové úpravy. Je to podobné jako opravování chyb – samotná oprava chyby je často triviální, ale přijít na to, kde ta chyba je, to je skutečná práce.
Mezi noSQL databáze patří i XML databáze. Ty sice nejsou klasické relační, nepoužívá se v nich SQL, ale přesto umožňují mít v datech daleko lepší řád než databáze typu klíč-hodnota. Jelikož se používá XML a ne třeba nějaký primitivní JSON, můžeme využít řadu vyspělých technologií – validace proti Schématu, DTD…, dotazování pomocí XPath, XQuery, transformace pomocí XSLT, formuláře XForms atd. Doporučuji se podívat na výše zmíněnou eXist databázi.
Na druhou stranu ale dochází i k začleňování XML technologií do klasických relačních databází – např. PosgreSQL (ale i DB/2, Oracle a další).
Jak to dopadne se teprve uvidí – bude zajímavé sledovat, zda se více prosadí čistě XML databáze (jako eXist), nebo spíš hybridní databáze (tzn. relační obohacené o XML). Jaký je váš tip? Resp. kdy byste kterou použili?
Jelikož se používá XML a ne třeba nějaký primitivní JSON, můžeme využít řadu vyspělých technologií – validace proti Schématu, DTD…
To lze i u JSONu. Nakonec není problém si napsat vlastní validátor.
(Trofám -> Troufám)
Napsat si člověk může kde co, ale vtip je v tom, že pro XML jsou tyhle „nadstavby“ už hotové a odladěné. Ono je ve skutečnosti celkem jeno, jestli člověk píše ty závorky ostré nebo složené, o tom to není… síla XML je právě v těch technologiích nad ním.
P.S. „trofám“ opraveno, díky.
síla XML je právě v těch technologiích nad ním
S tím lze částečně souhlasit. Na druhou stranu implementace těchto technologií jsou dost často v žalostném stavu. Například knihovny pro XQuery jsou velice pomalé a mají velkou spotřebu paměti. Pro validaci vůči schématům se většinou používají algoritmy, které v nejhorším případě provedou exponenciální počet kroků, takže "vhodně" vytvořené schéma může některé validátory dostat do kolen.
- A je potřeba ty validace provádět tak často, aby se ta údajná pomalost nějak projevila? Tedy reálný dopoad, který uvidí uživatel,
- Jak by na tom byl s výkonem nějaký narychlo zbastlený validátor JSONu? Má JSON nějaké zvláštní předpoklady, aby software nad ním napsaný byl rychlejší nebo jinak lepší?
A je potřeba ty validace provádět tak často, aby se ta údajná pomalost nějak projevila? Tedy reálný dopad, který uvidí uživatel
Problém je v tom, že jedna validace může trvat i více než několik hodin.
Jak by na tom byl s výkonem nějaký narychlo zbastlený validátor JSONu? Má JSON nějaké zvláštní předpoklady, aby software nad ním napsaný byl rychlejší nebo jinak lepší?
Pokud nebude podporovat vše, co umí např. RELAX NG, tak je šance, že bude rychlejší než validátory RELAX NG. Na tom, jestli to je JSON či XML či něco jiného nezáleží.
Častý problém standardů (nejen kolem XML) je, že jsou příliš komplexní, a tudíž je dost obtížné udělat dobrou implementace.
OMG, několika hodinová validace? Něco je asi špatně :-)
(a nemyslím tím tu XML implementaci)
Například, pokud při validaci pomocí XML Schema nastavíte ve schématu maxOccurs na 10^9 a implementace si pro celé schéma staví konečný automat (mám na mysli klasický DFA nebo NFA), tak se asi nedočkáte, než ho vybuduje.
Neznám validátor pro XML Schema, který by pracoval v polynomiálním čase.
V Čechách nemáme Twitter a Facebook. Máme tu ale menší aplikace, které nejedou na tak velkých clusterech jako právě Twitter a Facebook.
V Čechách pak situace vypadá tak, že máme relativně hodně navštěvovanou službu s velkým vnitřním provozem, několika databázovými servery a potřebujeme mít rychlý jednolitý databázový cluster, který má být snadný na správu. V ideálním případě by měl mít všechny uzly rovnocenné (mm tím na mysli multimaster replikaci). Zároveň u této vrstvy nepotřebujeme stoprocentní stabilitu, protože za touhle vrstvou leží ACID databáze.
K tomuhle scénáři se není problém dopracovat po pár měsících šlapající služby a je vždy dobré s tím počítat od začátku. Z tohoto důvodu jsem velice rád, za NoSQL databáze.
Nicméně souhlasím, že je třeba si napřed pořádně nastudovat, co jsou ty NoSQL databáze zač, protože heslo "Rok 2010 bude rokem NoSQL databází." zní sice hezky, ale utopený čas přepisem do technologie, kterou vlastně nechcete, vám nevrátí. Takže hezky pozvolna.
Díky za článek, je třeba, aby se o tématu ještě dlouho psalo, abychom si ho dostatečně osahali.
Ja bych se na tu absenci ACIDu teda moc nevymlouval. NoSQL je pojem relativne moderni, ackoliv do nej spadaji i databaze, ktere jsou jeste starsi nez nejake RDBMS a s vyhodou se nasazuji v mission-critical prostredi. V takovych DB je naopak na podporu transakci kladen maximalni duraz.
Je pravda, ze nad takovou DB muze byt jeste nejaka dalsi vrstva, ktera muze umoznit napr. treba i SQL pristup, ale vim o systemech, kde je i pres tohle vsechno performance radove lepsi, nez nad nativnim SQL. Je otazka, jak byl dany benchmark delany, a jak byl ten ci onen system nastaveny, ale napr. v komunite kolem technologie M je dobre znamo, ze spatne nastaveny M system bez potizi prevalcuje dobre nastavenou SQL databazi.
Abych nemluvil porad o jedne technologii, tak si myslim, ze treba Erlangovska Mnesia na tom taky nebude az tak spatne. Ale tu az tak dobre neznam.
Spoustu lidi rika, ze by veci mely byt modularni, ale kdyz dojde na databazi, tak vsichni poskakuji kolem RDBMS mamuta, ktery dela tisic veci a nakonec pak pulku z tech veci stejne clovek musi dualne ohlidat i v te aplikaci, protoze uzivateli na spatny vstup nelze odpovedet nicnerikajici databazovou chybou ve stylu "ORA-1234 error." ;-)
Kdyz uz SQL, tak preferuji PostgreSQL, ale i tam -- zkouseli jste si nekdy zprovoznit nejakou seriozni replikaci? Je na to hromada projektu, ale ani jeden z nich mi neprisel uspokojivy a kdyz uz na to vypadal, tak nebyl hotovy. Treab v pripade GT.M, nebo rekneme i te Mnesie, to je zakladni vybaveni systemu. Proste ty systemy s velkym nasazenim uz pocitaji, neni to tam dobastlene dodatecne.
Je to slozite, ale ve vysledku stejne vsechna rozhodovani odrazeji dulezitost a typ aplikace.
Mimochodem, kdyz uz padla rec na FaceBook, Twitter a spol., tak je sice pekne, ze ty backendy pracuji s >11 miliardami zaznamu, ale taky je potreba se ptat, co se stane, kdyz se nejaky z tech tweetu "rozbije." Maximalne se muze stat, ze ten chudak jedinec utrpi psychickou ujmu, protoze se cely svet nedozvi, ze zrovna nastoupil do autobusu cislo 147, ale to je asi tak vsechno. Tyhle sluzby jsou, pokud vim, zdarma a uz jen to samo o sobe znamena, ze ti lide nemaji zadnou garanci, ze zitra nekdo tech 11 miliard zaznamu nevypraskne a ten byznys nezabali, nebo neproda nekomu jinemu. Jedine, o co by v techto systemech melo jit, je ochrana soukromi a tedy zabezpeceni DB. To ale zrovna v pripade FaceBooku moc dobre (evidentne zamerne) nefunguje.
To uz jsme ale trosku OT...
možná bych doplnil, že noSQL neznamené ne-SQL, ale not-only-SQL (nejen SQL, případně SQL+něco navíc). noSQL databaze muze klidne mit SQL interface.
---
Zaškolení nováčka do schema free? Asi stejně težké jako vysvětlit libovolné jiné API. Mám objekt, ve kterém jsou proměnné a další vychytávky co zrovna daný jazyk umožňuje. Tento objekt ukládám do databáze a načítám z databáze. Případně mohou být v objektu reference na jiné objekty.
Celé to jde zakreslit do grafu stejně hezky jako každá jiná databáze. prostě máš místo řádků v databázi objekty a místo sloupců máš proměnné. klíč databáze je jenom jeden (samozřejmě do něj můžeme spojit více proměnných).
Je to mnohem pohodlnější, než si vyzobávat nějaké řetězce ze SQL odpovedi a pak je stejně ukládat do nějakého použitelného tvaru.
Je špátné myslet si, že schema-free databáze nemají žádné schéma. spíše by se mělo říkat free-schema. to znamená, že programátor se může rozhodnout bezbolestně některým položkám přidat pár proměnných, které se mu tam zrovna hodí (aniž by databáze alkovala místo těmto proměnným i u všech ostatních položek) a nebo naopak někde proměnnou vynechat. Schema se tedy může vyvíjet současně s aplikací a je snadné zaručit zpětnou i dopřednou kompatibilitu s položkami, které byly do databáze uložené dříve. Změna schématu SQL databáze může být opravdu problémová.
---
"Jelikož se používá XML a ne třeba nějaký primitivní JSON, můžeme využít řadu vyspělých technologií – validace proti Schématu, DTD…, dotazování pomocí XPath, XQuery, transformace pomocí XSLT, formuláře XForms atd."
XML neumí nic, co by se pomocí JSONu nedalo udělat. XML je akorát upovídanější, líbí se html "programátorům" a zbytečně žere místo...
možná bych doplnil, že noSQL neznamené ne-SQL, ale not-only-SQL
Tohle tu někteří propagují, ale původní myšlenka opravdu bylo odmítnutí SQL a relačního modelu. Dneska už zastánci noSQL trochu vyměkli a říkají tomu not-only… ale ne vždy tomu tak bylo.
noSQL databaze muze klidne mit SQL interface
To může. Protože se ukazuje, že SQL je prostě fajn, lidi ho umí, je jednoduché, má logiku, skvěle se v něm píší dotazy atd.
Mám objekt, ve kterém jsou proměnné a další vychytávky co zrovna daný jazyk umožňuje. … Celé to jde zakreslit do grafu stejně hezky jako každá jiná databáze. prostě máš místo řádků v databázi objekty a místo sloupců máš proměnné.
Není to totéž – v relačním modelu máš relace, tabulky s předem danou strukturou. Tabulka je něco jako třída v OOP, vzor objektu. Tzn. seznámíš se s třídou a víš, co můžeš čekat od těch objektů. V bezschémových databázích máš jen ty objekty, bez nějakého zobecnění, každý objekt je „individuum“ , každý může mít jiné vlasntnosti (tím nemyslím jejich hodnoty, ale jejich názvy). Na jednu stranu je to flexibilní, na druhou stranu to ztěžuje orientaci v modelu – nestačí prozkoumat třídy/tabulky, ale musíš prozkoumat všechny objekty/záznamy, aby ses zorientoval.
XML neumí nic, co by se pomocí JSONu nedalo udělat.
Rozdíl je právě v tom, že XML ty nadstavbové technologie už má hotové a odladěné, zatímco v JSONu „by to šlo udělat“ – jistě, udělat jde vše a všude, otázka je, kolik to dá práce a kolik si toho člověk musí napsat sám, vynalézat kolo – v XML je to kolo už vynalezené a hotové. I v JSONu existují pokusy o schéma nebo transformace, ale XML je v tomhle napřed a až se JSON pracně dohrabe tam, kde je dneska XML, ukáže se, že používáním složených závorek místo ostrých jsme si vlastně vůbec nepomohli, že je z toho stejně složitá věc jako je XML, ne-li složitější a horší, protože XML za sebou mělo (a má) lepší zázemí a podmínky.
SQL je prostě fajn, lidi ho umí, je jednoduché, má logiku,...
SQL je nevhodné pro distribuované databáze (neumí Map/Reduce dotazy) a je zbytečně složité (ve srovnání s key-value přístupem, kde je dotaz třeba jen jediné slovo nebo číslo)...
SQL je navíc náchylné na SQL injekci, protože programátor musí sám vše správně oescapovat a spojit (i když to je jen minoritní problém).
Ale jsou noSQL databáze, které používají SQL databázi jako backend a poskytují mnohem vyšší úroveň abstrakce při práci s daty v této databázi.
musíš prozkoumat všechny objekty/záznamy, aby ses zorientoval.
ve skutečnosti stačí si přečíst kód aplikace, v jejímž vývoji se chystáš pokračovat. a NAVÍC nemusíš znát schéma celé, tobě stačí znát jen proměnné/featurky, které použiješ ty. jak se bude nakládat s těma ostatníma to je věc programátorů, kteří si je do databáze uložili (nebo je načítají). musí být připraveni na to, že tam požadovaná proměnná chybí.
XML ty nadstavbové technologie už má hotové a odladěné
S JSONem se dá dělat vše co s objektem nebo polem a takové technologie jsou součástí přímo programovacího jazyka který používáš, takže dost věcí ani nepotřebuje knihovnu.
Ale rád bych poznamenal, že pokud je někdo XML fetišista, tak mezi oběma formáty se dá snadno převádět (za dodržení určitých předpokladů) a pak je jediný rozdíl v tom který z formátů zabírá kolik místa. Možná by se kvůli další úspoře ještě dalo doporučit používat plaintextový JSON na vývojových serverech a binární BSON na produkčních.
---
BTW se muzete podivat na poznatky nasich vyvojaru o nosql: http://wiki.kyberia.cz/doku.php?id=netabulkove_databaze_nosql
a je zbytečně složité (ve srovnání s key-value přístupem, kde je dotaz třeba jen jediné slovo nebo číslo)...
S tou složitostí je to relativní – naučit se základy SQL není nic těžkého. I když samozřejmě nepopírám, že SELECT * FROM tabulka WHERE klíč = 'abc'; je „složitější“ než get("abc");. A jestli je zbytečně složité? Záleží, co od databáze odčekáváš, většinou ta „složitost“ zbytečná není. Ona totiž jednoduchost (až primitivnost) u databází typu klíč-hodnota vede zákonitě ke složitosti na úrovni aplikace – aneb, co za mne neudělá databáze, musím udělat já v aplikaci. Je to podobné jako se souborovými systémy – pokud aplikaci předhodím celké blokové zařízení a ona na něj zapisuje přímo, odpadá ta „složitost“ ovladačů FS – ale zároveň stoupá složitost samotné aplikace (musí řešit to, o co se běžně stará souborový systém). Já dávám přednost znovupoužitelnému kódu – tzn. to, co je společné mnoha aplikacím, ať se naprogramuje jednou a pořádně (souborový systém, databáze, ovladače k hardwaru, obecně knihovny) a aplikace ať se těmito nízkoúrovňovými věcmi nezabývají a soustředí se na přidanou hodnotu.
SQL je navíc náchylné na SQL injekci, protože programátor musí sám vše správně oescapovat a spojit (i když to je jen minoritní problém).
Teď nevím, jestli si ze mě děláš legraci, nebo máš fakt fatální neznalosti programování a práce s databázemi. Existuje taková šikovná věc: parametrizované dotazy. Napíšeš třeba "SELECT * FROM tabulka WHERE id = ? AND jmeno = ?" a před voláním tohoto dotazu ho naparametrizuješ pomocí metody jako setInt(1, 123), nebo setString(2, "alice"). Typově bezpečné a nestane se ti, že by se parametr „rozlezl“ do zbytku dotazu a narušil ho. Lepit SQL dotazy pomocí spojování řetězců zásadně nedoporučuji. Escapování přenech na ovladači/knihovně k příslušné databázi.
ve skutečnosti stačí si přečíst kód aplikace, v jejímž vývoji se chystáš pokračovat.
Ještě lepší :-D Kód aplikace se průběžně vyvíjí, takže to abych si nastudoval celou jeho historii, abych chápal i data, která vznikla v jeho předešlých verzích. Data dokonce ani nemusela vzniknout v programu na základě jeho kódu, ale mohl je tam klidně někdo zadat ručně – pak si ty struktury z toho kódu už absolutně nemám šanci vycucat. Opravdu ti přijde jednodušší nastudovat tisíce řádků kódu (a ještě s nejistým výsledkem), než se podívat na tohle: Model databáze a hned vidět? Poznámka: ani u modelu databáze nemusíš studovat celý model a můžeš se kouknout jen na tabulky a sloupečky, které tě zajímají.
to je věc programátorů, kteří si je do databáze uložili
tzn. nejednotnost, roztříštěná datová základna, duplicity a konflikty v datech (jeden programátor si uložil A, druhý B a správně je co z toho?).
S JSONem se dá dělat vše co s objektem nebo polem
např. prostředky pro dotazováni nad objekty/poli nebývají tak bohaté jako možnosti dotazování v SQL nebo XQuery. Filtrování je na úrovni „full table scanů“, tzn. projet všechny objekty a porovnat, zda vyhovují podmínkám, v lepším případě hashmapy. Co se týče transformací dat – XSLT je znovupoužitelné, napíšu ho jednou, dám lidem k dispozici a oni si ho budou volat jednou z Javy, jindy z C++ nebo za jiného jazyka. Jak to uděláš v JSONu? Nebude tam náhodou potřeba implementovat danou logiku pro každý jazyk zvláť, vždy znovu a znovu?
BTW: co je kyberia zač? Kromě nějakých utopických vizí mi to přijde prostě jako nástroj pro sdílení znalostí, tzn. něco jako Wikipedia.
Kyberia je prave o tech utopickych vizich (a mimochodem kyberia neni o nejakem systemu, ten system spolu s poradnou databazi jen kyberii umoznuje se rozrustat), asi jsi jenom malo idealista na to abys to pochopil (takovych lidi je vice), prave proto se ted kyberia (ktera kdysi mozna o 5 let predstihla facebook, wikipedii a blogy) deli na nekolik skupin lidi, ja je v zasade delim "kyberiani" a "facebookari". prvni maji idealy, druzi chteji proste jen socialni sit (+ sluzby co poskytuje soucasna kyberie).
Rozhovor o databazich bych uzavrel s tim, ze na kazdou praci je potreba si vybrat spravne naradi, na kyberiu se SQL nehodi (coz se ukazalo na te soucasne, ve chvili, kdy nekolik databazovych serveru nezvlada tisice useru, protoze bottleneck SQL databaze je nutnost tahnout vse pres jediny master server a nemoznost pouzivat map/reduce dotazy. jde o to, ze kyberia potrebuje ukladat mnohem slozitejsi struktury, nez nejaka databaze zamestnancu, blog nebo facebook). kdybych psal blog, tak si mozna zvolim jinou databazi (i kdyz nevim), protoze SQL by bylo mnohem vhodnejsi pro vybrani 10ti nejnovejsich prispevku (ze 700 celkovych) serazenych podle datumu, nez pro rekurzivni vybrani pozadovane casti cyklickeho orientovaneho hypergrafu s 53941410 uzly a nekolikanasobnymi hranami tak, aby byly potlaceny duplicity (a tim zamrznuti databaze). (coz je mimochodem problem, ktery skutecne resime)
tady je par linku do zacatku, ale upozornuji, ze to byl jen pocatecni impulz, neda se tvrdit, ze by ta kniha nejak vysvetlovala neco ohledne pozdejsiho vyvoje samotne kyberie: http://www.rushkoff.com/downloadables/cyberiabook/ http://wiki.kyberia.cz/doku.php?id=description_of_cyberia http://wiki.kyberia.cz/doku.php?id=lidsky_faktor
Jinak json transformaci umi a dost elegantne (pomoci JSONT) a mnohem mene upovidane nez xml, mrkni na ten odkaz dole, co sem posilal.
taky bych doporučil tohle: http://www.slideshare.net/guestfd7d7c/advanced-json