7 твърди истини за революцията NoSQL

Ключовата дума на NoSQL метастазира от няколко години. Вълнението от тези бързи хранилища на данни е опияняващо и ние сме виновни като всеки друг, че видяхме новаторската привлекателност на NoSQL. И все пак меденият месец е към своя край и е време да започнем да балансираме ентусиазма си с някои твърди истини с кимлетски очи.

Не ни разбирайте погрешно. Все още работим, за да опитаме най-новия експеримент за изграждане на прост механизъм за съхранение на данни. Все още намираме дълбока стойност в MongoDB, CouchDB, Cassandra, Riak и други NoSQL. Все още планираме да хвърляме някои от най-надеждните ни данни в тези стекове код, защото те растат по-добре и са по-тествани всеки ден.

[Също на: NoSQL standouts: Нови бази данни за нови приложения | Първи поглед: Oracle NoSQL база данни | Получавайте обобщение на ключовите истории всеки ден в бюлетина Daily. ]

Но започваме да усещаме раздразненията, тъй като системите NoSQL далеч не са идеално пригодени и често се търкат по грешен начин. Най-умните разработчици знаеха това от самото начало. Те не изгориха ръководствата за SQL и не изпратиха настиграми до търговския отдел на техния отдаден SQL доставчик. Не, интелигентните разработчици на NoSQL просто отбелязаха, че NoSQL означава „Не само SQL“. Ако масите погрешно интерпретираха съкращението, това беше техният проблем.

По този начин този списък с пречки, големи и малки, е опит за документиране на този факт и за изчистване на въздуха. Целта е да се оправят нещата сега, за да можем по-добре да разберем компромисите и компромисите.

NoSQL твърда истина № 1: JOINs означава последователност

Един от първите проблеми, които хората имат за SQL системите, са изчислителните разходи за изпълнение на JOIN между две таблици. Идеята е да съхранявате данните на едно и само едно място. Ако поддържате списък с клиенти, поставяте техните улични адреси в една таблица и използвате техните клиентски идентификатори във всяка друга таблица. Когато изтеглите данните, JOIN свързва идентификаторите с адресите и всичко остава последователно.

Проблемът е, че JOINs могат да бъдат скъпи и някои DBA са измислили сложни JOIN команди, които затрупват съзнанието, превръщайки дори най-бързия хардуер в шлам. Не беше изненада, че разработчиците на NoSQL превърнаха липсата си на JOINs във функция: Нека просто запазим адреса на клиента в същата таблица като всичко останало! Начинът NoSQL е да съхранява двойки ключ-стойност за всеки човек. Когато му дойде времето, извличате всички.

Уви, хората, които искат техните таблици да бъдат последователни, все още се нуждаят от ПРИСЪЕДИНЕНИЯ. След като започнете да съхранявате адресите на клиентите с всичко останало за тях, често получавате множество копия на тези адреси във всяка таблица. И когато имате няколко копия, трябва да ги актуализирате всички едновременно. Понякога това работи, но когато не стане, NoSQL не е готов да помогне при транзакции.

Изчакайте, казвате, защо да нямате отделна таблица с информация за клиента? По този начин ще има само един запис, който да се промени. Страхотна идея, но сега можете сами да напишете ПРИСЪЕДИНЯВАНЕ по вашата собствена логика.

NoSQL твърда истина № 2: Трудни транзакции

Да приемем, че сте добре да живеете без да се присъединявате към маси, защото искате скоростта. Това е приемлив компромис и понякога SQL DBA денормализират таблиците точно по тази причина.

Проблемът е, че NoSQL затруднява поддържането на последователността на различните записи. Често няма транзакции, които да гарантират, че промените в множество таблици се правят заедно. За това вие сте сами и сривът може да гарантира, че таблиците се превръщат в несъвместими.

Най-ранните внедрения на NoSQL са си палили носа при тези транзакции. Те биха предложили списъци с данни, които са последователни, освен когато не са били. С други думи, те се насочиха към данните с най-ниска стойност, където грешките не биха имали съществена разлика.

Сега някои внедрения на NoSQL предлагат нещо, което приближава транзакцията. Продуктът на Oracle NoSQL например предлага транзакционен контрол върху данните, записани в един възел, и ви позволява да изберете гъвкаво количество последователност между множество възли. Ако искате перфектна последователност, трябва да изчакате всеки запис да достигне до всички възли. Няколко други хранилища за данни NoSQL експериментират с добавяне на повече структура и защита като тази.

NoSQL твърда истина № 3: Базите данни могат да бъдат умни

Много програмисти на NoSQL обичат да се хвалят как техният лек код и опростен механизъм работят изключително бързо. Те обикновено са прави, когато задачите са толкова прости, колкото вътрешността на NoSQL, но това се променя, когато проблемите станат по-трудни.

Помислете за старото предизвикателство на JOIN. След като NoSQL програмистите започнат да генерират свои собствени JOIN команди в собствената си логика, те започват да се опитват да направят това ефективно. Разработчиците на SQL прекараха десетилетия в разработването на усъвършенствани двигатели, за да се справят с JOIN командите възможно най-ефективно. Един разработчик на SQL ми каза, че се опитва да синхронизира кода си с въртящия се твърд диск, така че да иска данни само когато главата е точно над правилното място. Това може да изглежда крайно, но разработчиците на SQL работят по подобни хакове от десетилетия.

Няма съмнение, че програмистите прекарват дни да скубят косите си, опитвайки се да структурират своите SQL заявки, за да се възползват от цялата тази скрита интелигентност. Може да не е лесно да докоснете, но когато програмистът го разбере, базите данни наистина могат да пеят.

Изтънчен език за заявки като SQL винаги има потенциал да засенчи неизискан език за заявки като тези, намерени в NoSQL. Може да няма значение за простите резултати, но когато действието стане сложно, SQL се изпълнява на машината точно до данните. Той има малко режийни извличане на данни и извършване на работата. Сървърът NoSQL обикновено трябва да изпраща данните до мястото, където отиват.

NoSQL твърда истина № 4: Твърде много модели за достъп

На теория се предполага, че SQL е стандартен език. Ако използвате SQL за една база данни, трябва да можете да изпълните същата заявка в друга съвместима версия. Това твърдение може да работи с няколко прости заявки, но всеки DBA знае, че може да отнеме години, за да научи идиосинкразиите на SQL за различни версии на една и съща база данни. Ключовите думи са предефинирани и заявките, които са работили върху една версия, няма да работят с друга.

NoSQL е още по-тайнствен. Това е като Вавилонската кула. От самото начало разработчиците на NoSQL се опитват да си представят възможно най-добрия език, но имат много различни представи. Това огнище на експериментиране е добро - докато не се опитате да прескачате между инструментите. Заявка за CouchDB се изразява като двойка JavaScript функции за картографиране и намаляване. Ранните версии на Cassandra използваха суров API на ниско ниво, наречен Thrift; по-новите версии предлагат CQL, подобен на SQL език за заявки, който трябва да бъде анализиран и разбран от сървъра. Всеки е различен по свой начин.

Всеки инструмент не просто има свои собствени особености, той има напълно различна философия и начин на изразяване. Няма лесни начини да превключвате между хранилищата с данни и често оставате да пишете тонове код за лепило, само за да си дадете възможност за превключване в бъдеще. Това може да не е твърде трудно, когато натъпквате двойки ключове и стойности в системата, но може да нараства все повече, влошавайки по-сложността, която въвеждате.

NoSQL твърда истина № 5: Гъвкавостта на схемата е проблем, който чака да се случи

Една от страхотните идеи от модела NoSQL не изисква схема. С други думи, програмистите не трябва да решават предварително кои колони ще бъдат достъпни за всеки ред в таблица. Един запис може да има 20 низа, прикрепени към него, друг може да има 12 цели числа, а друг може да е напълно празен. Програмистите могат да вземат решение, когато имат нужда да съхраняват нещо. Не е нужно да искат разрешение от DBA и не е необходимо да попълват всички документи, за да добавят нова колона.

Цялата тази свобода звучи опияняващо и в правилните ръце може да ускори развитието. Но наистина ли е добра идея за база данни, която може да преживее три екипа от разработчици? Възможно ли е изобщо да работи за база данни, която може да продължи повече от шест месеца?

С други думи, разработчиците може да искат свободата да хвърлят всяка стара двойка в база данни, но искате ли да сте петият разработчик, който се появи, след като четири са избрали свои ключове? Лесно е да си представим разнообразие от представяния на „рожден ден“, като всеки разработчик избира собственото си представяне като ключ, когато добавя рожден ден на потребител към запис. Екип от разработчици може да си представи почти всичко: "bday", "b-day", "birthday".

Структурата NoSQL не предлага поддръжка за ограничаване на този проблем, защото това би означавало преиздаване на схемата. Той не иска да се сурови с мекотата на напълно готините разработчици. Схема ще попречи.

Факт е, че добавянето на колона към таблица не е голяма работа и дисциплината всъщност може да е добра за разработчика. Точно както помага да се принудят разработчиците да определят типове променливи, така също помага да се принуди разработчиците да определят типа данни, прикачени към колона. Да, DBA може да принуди разработчика да попълни формуляр в три екземпляра, преди да прикачи тази колона, но това не е толкова лошо, колкото да се занимавате с половин дузина различни ключове, създадени в движение от програмист.

NoSQL твърда истина № 6: Без екстри

Да предположим, че не искате всички данни във всички редове и искате сумата от една колона. Потребителите на SQL могат да изпълнят заявка с операцията SUM и да ви изпратят един - само един - номер.

Потребителите на NoSQL получават обратно всички данни, които им се изпращат и след това могат сами да извършат добавянето. Добавянето не е проблем, тъй като отнема приблизително същото време, за да съберете числата на която и да е машина. Въпреки това, доставката на данните наоколо е бавна и честотната лента, необходима за изпращане на всички тези данни, може да бъде скъпа.

Има малко екстри в базите данни NoSQL. Ако искате да направите нещо друго, освен да съхранявате и извличате данни, вероятно ще го направите сами. В много случаи ще го направите на различна машина с пълно копие на данните. Истинският проблем е, че често може да бъде полезно да се направят всички изчисления на машината, която държи данните, тъй като изпращането на данните отнема време. Но трудно за теб.

Появяват се решения NoSQL. Структурата на заявката Map and Reduce от MongoDB ви дава произволна JavaScript структура за сваляне на данните. Hadoop е мощен механизъм за разпределение на изчисленията в стека от машини, който също съхранява данните. Това е бързо развиваща се структура, която предлага бързо подобряващи се инструменти за изграждане на сложен анализ. Много е готино, но все пак ново. И технически Hadoop е съвсем различна модна дума от NoSQL, въпреки че разликата между тях избледнява.

NoSQL твърда истина № 7: По-малко инструменти

Разбира се, можете да стартирате и стартирате вашия NoSQL на вашия сървър. Разбира се, можете да напишете свой собствен потребителски код, за да изтласкате и изтеглите данните си от стека. Но какво, ако искате да направите повече? Какво ще стане, ако искате да закупите един от тези изискани пакети за отчитане? Или графичен пакет? Или да изтеглите някои инструменти с отворен код за създаване на диаграми?

За съжаление повечето инструменти са написани за бази данни на SQL. Ако искате да генерирате отчети, да създавате графики или да правите нещо с всички данни във вашия стек NoSQL, ще трябва да започнете да кодирате. Стандартните инструменти са готови за извличане на данни от Oracle, Microsoft SQL, MySQL и Postgres. Вашите данни са в NoSQL? Те работят по него.

И те ще работят върху него за малко. Дори да прескочат всички обръчи, за да стартират и работят с една от базите данни NoSQL, ще трябва да започнат всичко отначало, за да се справят със следващата система. Има повече от 20 различни избора на NoSQL, като всички те имат своя собствена философия и собствен начин на работа с данните. Достатъчно трудно беше производителите на инструменти да подкрепят идиосинкразиите и несъответствията в SQL, но е още по-сложно да накараме инструментите да работят с всеки NoSQL подход.

Това е проблем, който бавно ще изчезне. Разработчиците могат да усетят вълнението в NoSQL и ще модифицират инструментите си за работа с тези системи, но това ще отнеме време. Може би тогава те ще стартират на MongoDB, което няма да ви помогне, защото управлявате Cassandra. Стандартите помагат в ситуации като тази, а NoSQL не е голям за стандартите.

NoSQL недостатъци накратко

Всички тези недостатъци на NoSQL могат да бъдат сведени до едно просто твърдение: NoSQL изхвърля функционалността за бързина. Ако не се нуждаете от функционалността, ще се оправите, но ако имате нужда от нея в бъдеще, ще съжалявате.

Революциите са ендемични за технологичната култура. Идва нова група и се чуди защо последното поколение е изградило нещо толкова сложно и те са тръгнали да събарят старите институции. След малко те започват да осъзнават защо всички стари институции са били толкова сложни и започват да прилагат функциите отново.

Виждаме това в света на NoSQL, тъй като някои от проектите започват да добавят обратно неща, които приличат на транзакции, схеми и стандарти. Това е естеството на напредъка. Ние събаряме нещата само за да ги изградим отново. NoSQL приключи с първата фаза на революцията и сега е време за втората. Кралят е мъртъв. Да живее царят.

Свързани статии

  • NoSQL открояващи се: Нови бази данни за нови приложения
  • Първи поглед: Oracle NoSQL база данни
  • Flexing NoSQL: MongoDB в преглед
  • 10 основни съвета за производителност за MySQL
  • 10 основни MySQL инструмента за администратори
  • Овладейте MySQL в облака на Amazon
  • Времето за стандартите NoSQL е сега

Тази история, „7 твърди истини за революцията NoSQL“, първоначално беше публикувана в .com. Следете най-новите разработки в управлението на данни в .com. За най-новите разработки в новините за бизнес технологии, следвайте .com в Twitter.