Учтивото тълкуване на "NoSQL" се превърна в Not Only SQL . Ако имате данни, които наистина са релационни, или ако функционалността ви зависи от неща като присъединяване и ACIDity, тогава трябва да съхранявате тези данни по релационен начин. В тази публикация ще обясня как използвам MySQL заедно с две NoSQL хранилища за данни. Съвременното съхранение на данни в уеб мащаб е свързано с разбирането как да изберете най-добрия инструмент(и) за работата(ите).
Въпреки това, NoSQL наистина е реакция на факта, че релационният метод и начин на мислене са били приложени към проблеми, където всъщност не е много подходящ (обикновено огромни таблици с десетки милиони редове или повече). След като таблиците станат толкова големи, типичната "най-добра практика" на SQL е ръчно шардиране данните - тоест поставяне на записи от 1 до 10 000 000 в таблица А, 10 000 001 до 20 000 001 в таблица Б и т.н. След това, обикновено в слоя на модела на приложението, търсенията се извършват по тази схема. Това е, което се нарича application-aware мащабиране. Отнема много време и е склонен към грешки, но за да увеличите нещо, като същевременно поддържате MySQL за магазина за дълги таблици, се превърна в повече или по-малко стандартен MO. NoSQL за мен представлява application-unaware алтернатива.
Ключ-стойност
Когато прототипът на MySQL започна да става твърде голям за негово добро, аз лично преместих възможно най-много данни в светкавичния Membase , което превъзхожда Memcached и добавя постоянство. Membase е разпределен магазин за ключ-стойност, който се мащабира повече или по-малко линейно (Zynga го използва, за да обработва половин милион операции в секунда, например) чрез добавяне на повече сървъри за стоки в клъстер – следователно е страхотно em> подходящ за облачната епоха на Amazon EC2 , Joyent и др.
Добре известно е, че разпределените магазини на ключ-стойност са най-добрият начин да получите огромен, линеен мащаб. Слабостта на ключ-стойност е възможността за запитване и индексиране. Но дори и в релационния свят, най-добрата практика за мащабируемост е да се разтоварят възможно най-много усилия върху сървърите на приложения, като се правят обединявания в паметта на сървъри за стандартни приложения, вместо да се иска централният RDB клъстер да се справи с цялата тази логика. Тъй като simple select плюс application logic са наистина най-добрият начин за постигане на огромен мащаб дори на MySQL, преходът към нещо като Membase (или неговите конкуренти като Riak
) не е много лошо.
Магазини за документи
Понякога – макар че бих спорил по-рядко, отколкото мнозина си мислят – дизайнът на приложението по своята същност изисква вторични индекси, възможност за заявка за диапазон и т.н. Подходът на NoSQL към това е чрез document store като MongoDB
. Подобно на Membase, Mongo е много добър в някои области, където релационните бази данни са особено слаби, като application-unaware мащабиране, auto-sharding и maintaining flat response times even as dataset size balloons . Той е значително по-бавен от Membase и малко по-труден за извършване на чисто хоризонтално мащабиране, но предимството е, че е много по-запитваем. Можете да правите заявки за параметри и диапазони в реално време или можете да използвате Map/Reduce за извършване на сложни пакетни операции върху наистина огромни набори от данни.
В същия проект, който споменах по-горе, който използва Membase за обслужване на тонове данни за играчи на живо, ние използваме MongoDB за съхраняване на данни от анализи/метрики, което наистина е мястото, където MongoDB блести.
Защо да съхранявате нещата в SQL
Засегнах накратко факта, че „наистина релационната“ информация трябва да остане в релационни бази данни. Както посочва коментаторът Дан К., пропуснах частта, в която обсъждам недостатъците на напускането на RDBMS или поне на пълното напускане.
Първо, има самия SQL. SQL е добре известен и е индустриален стандарт от дълго време. Някои бази данни "NoSQL", като App Engine
на Google Datastore (изграден върху Big Table) внедряват свой собствен език, подобен на SQL (на Google се нарича сладко GQL за Google Query Language ). MongoDB използва нов подход към проблема със заявките със своите възхитителни JSON обекти на заявки
. И все пак самият SQL е мощен инструмент за извличане на информация от данни, което често е целта на базите данни като начало.
Най-важната причина да останете с RDBMS е ACID
, или Atomicity, Consistency, Isolation, Durability . Няма да хеширам повторно състоянието на Acid-NoSQL, тъй като е добре адресирано в тази публикация
на SO. Достатъчно е да се каже, че има рационална причина RDBMS на Oracle
има толкова огромен пазар, който не отива никъде:някои данни се нуждаят от чисто съответствие с ACID . Ако вашите данни го правят (а ако е така, вероятно сте добре наясно с този факт), тогава също така и вашата база данни. Запазете това pH
ниско!
Редактиране: Вижте публикацията на Aaronaught тук. Той представя перспективата бизнес-бизнес много по-добре от мен, отчасти защото прекарах цялата си кариера в потребителското пространство.
