Zdvořilý výklad "NoSQL" se stal Not Only SQL . Pokud máte data, která jsou skutečně relační, nebo pokud vaše funkce závisí na věcech, jako jsou spojení a ACIDity, měli byste tato data ukládat relačním způsobem. V tomto příspěvku vysvětlím, jak používám MySQL vedle dvou Datová úložiště NoSQL. Moderní úložiště dat ve webovém měřítku je o pochopení toho, jak vybrat nejlepší nástroj (nástroje) pro danou úlohu.
To znamená, že NoSQL je ve skutečnosti reakcí na skutečnost, že relační metoda a způsob myšlení byly aplikovány na problémy, kde ve skutečnosti nejsou příliš vhodné (typicky obrovské tabulky s desítkami milionů řádků nebo více). Jakmile jsou tabulky tak velké, typickým „nejlepším postupem“ SQL je ruční úlomek data -- to znamená umístění záznamů 1 až 10 000 000 do tabulky A, 10 000 001 až 20 000 001 do tabulky B a tak dále. Poté, typicky ve vrstvě aplikačního modelu, jsou vyhledávání prováděna podle tohoto schématu. Tomu se říká application-aware škálování. Je to časově náročné a náchylné k chybám, ale aby se něco škálovalo při zachování MySQL pro úložiště dlouhých tabulek, stalo se to víceméně standardní MO. NoSQL pro mě představuje application-unaware alternativa.
Klíč–hodnota
Když jsem měl prototyp MySQL začal být příliš velký pro své vlastní dobro, osobně jsem přesunul co nejvíce dat do bleskově rychlé Membase , který překonává Memcached a přidává vytrvalost. Membase je distribuovaný obchod klíč–hodnota, který se škáluje víceméně lineárně (například Zynga ho používá ke zpracování půl milionu operací za sekundu) přidáváním dalších komoditních serverů do clusteru – je to tedy skvělé vhodné pro cloudovou éru Amazon EC2 , Joyent , atd.
Je dobře známo, že distribuované obchody s páry klíč–hodnota jsou nejlepším způsobem, jak získat obrovské lineární měřítko. Slabinou páru klíč-hodnota je dotazovatelnost a indexování. Ale i v relačním světě je nejlepším postupem pro škálovatelnost přesunout co nejvíce úsilí na aplikační servery, provádět spojení v paměti na aplikačních serverech s komoditami, místo aby se o veškerou tuto logiku žádal centrální cluster RDB. Protože simple select plus application logic jsou skutečně nejlepším způsobem, jak dosáhnout masivního rozsahu i na MySQL, přechod na něco jako Membase (nebo jeho konkurenty jako Riak
) není opravdu špatné.
Dokumenty
Někdy – i když bych tvrdil méně často, než si mnozí myslí – návrh aplikace ze své podstaty vyžaduje sekundární indexy, dotazovatelnost rozsahu atd. Přístup NoSQL k tomu je prostřednictvím document store jako MongoDB
. Stejně jako Membase je Mongo velmi dobré v některých oblastech, kde jsou relační databáze obzvláště slabé, jako je application-unaware škálování, auto-sharding a maintaining flat response times even as dataset size balloons . Je výrazně pomalejší než Membase a trochu složitější při provádění čistě horizontálního měřítka, ale výhodou je, že je vysoce dotazovatelné. Můžete se dotazovat na parametry a rozsahy v reálném čase, nebo můžete použít Map/Reduce k provádění složitých dávkových operací na skutečně obrovských souborech dat.
Ve stejném projektu, který jsem zmínil výše a který používá Membase k poskytování tuny živých dat hráčů, používáme MongoDB k ukládání analytických/metrických dat, což je skutečně místo, kde MongoDB září.
Proč uchovávat věci v SQL
Krátce jsem se dotkl skutečnosti, že „skutečně relační“ informace by měly zůstat v relačních databázích. Jak podotýká komentátor Dan K., unikla mi část, kde se zabývám nevýhodami opuštění RDBMS, nebo alespoň úplného opuštění.
Zaprvé je tu samotný SQL. SQL je dobře známý a již dlouhou dobu je průmyslovým standardem. Některé databáze „NoSQL“, jako je App Engine
společnosti Google Datastore (postaveno na Big Table) implementuje svůj vlastní jazyk podobný SQL (Google se nazývá, roztomile, GQL pro Google Query Language ). MongoDB zaujímá nový přístup k problému dotazování pomocí svých nádherných objektů dotazů JSON
. Přesto je SQL sám o sobě mocným nástrojem pro získávání informací z dat, což je často hlavní smysl databází.
Nejdůležitějším důvodem, proč zůstat u RDBMS, je ACID
nebo Atomicity, Consistency, Isolation, Durability . Nebudu znovu hašovat stav Acid-NoSQL, protože je dobře popsán v tento příspěvek
na SO. Stačí říci, že existuje racionální důvod RDBMS společnosti Oracle
má tak obrovský trh, který nikam nevede:některá data vyžadují čistou shodu s ACID . Pokud vaše data ano (a pokud ano, pravděpodobně si to dobře uvědomujete), pak to platí i pro vaši databázi. Udržujte toto pH
nízká!
Upravit: Podívejte se na Aaronaughtův příspěvek zde . Představuje perspektivu business-to-business mnohem lépe než já, částečně proto, že jsem celou svou kariéru strávil ve spotřebitelském prostoru.