MongoDB, Cassandra и HBase - трите бази данни NoSQL за гледане

Hadoop получава голяма част от кредита за големи данни, но реалността е, че базите данни NoSQL са далеч по-широко разгърнати и много по-широко развити. Всъщност, докато пазаруването на доставчик на Hadoop е относително просто, изборът на база данни NoSQL е всичко друго, но не и. В края на краищата има над 100 бази данни NoSQL, както показва класирането на популярността на базата данни DB-Engines.

Кой трябва да изберете?

Разглезени за избор

Защото изберете трябва. Колкото и да е хубаво да живеете в щастлива утопия на така наречената постоянство на полиглоти, „където всяко прилично предприятие ще има разнообразие от различни технологии за съхранение на данни за различни видове данни“, както твърди Мартин Фаулър, реалността е не можете да си позволите да инвестирате в учене повече от няколко.

За щастие изборът става все по-лесен, тъй като пазарът се обединява около три доминиращи бази данни NoSQL: MongoDB (подкрепена от бившия ми работодател), Cassandra (разработена основно от DataStax, макар и излюпена във Facebook) и HBase (тясно свързана с Hadoop и разработена от същата общност).

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

Данните на LinkedIn от 451 Research показват как пазарът гравитира към MongoDB, Cassandra и HBase:

Това са данните в профила на LinkedIn. По-пълен изглед е DB-Engines, който обединява работни места, търсене и други данни, за да разбере популярността на базата данни. Докато Oracle, SQL Server и MySQL царуват върховно, MongoDB (№ 5), Cassandra (№ 9) и HBase (№ 15) им пускат пари за парите си.

Въпреки че е твърде рано да наричаме всяка друга база данни NoSQL грешка при закръгляване, ние бързо достигаме тази точка, точно както се случи на пазара на релационни бази данни.

За да разбера по-добре защо тези три бази данни блестят, помолих представители на всяка от тях да идентифицират ключови атрибути за техния успех: Кели Стирман, директор на продукти в MongoDB; Патрик Макфадин, главен евангелист на Касандра в DataStax; и Джъстин Кестелин, старши директор по връзки с разработчиците в Cloudera.

Но първо трябва да разберем защо NoSQL има значение.

Свят, изграден с неструктурирани данни

Все повече живеем в свят, в който данните не се вписват добре в подредените редове и колони на RDBMS. Мобилните, социалните и облачните изчисления породиха масивен поток от данни. Според различни оценки 90 процента от световните данни са създадени през последните две години, като Gartner фиксира 80 процента от всички корпоративни данни като неструктурирани. Нещо повече, неструктурираните данни нарастват с двойно по-голяма скорост от структурираните данни.

Тъй като светът се променя, изискванията за управление на данните надхвърлят ефективния обхват на традиционните релационни бази данни. Първите организации, които забелязват необходимостта от алтернативни решения, са пионери в мрежата, държавни агенции и компании, специализирани в информационните услуги.

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

MongoDB: От разработчиците, за разработчиците

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

MongoDB често е първият разработчик на база данни NoSQL, който ще опита, защото е толкова лесен за научаване. Уил Шулман, главен изпълнителен директор на MongoLab (доставчик на услуги като MongoDB), казва това по следния начин:

Непропорционалният успех на MongoDB до голяма степен се основава на нейната иновация като хранилище за структура на данни, което ни позволява по-лесно и изразително да моделираме „нещата“ в основата на нашите приложения ....

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

За отбелязване е, че MongoDB, подобно на останалите бази данни в този списък, не е едно трик пони. Предприятията, които учат MongoDB, „могат да амортизират инвестициите си в MongoDB в много, много проекти, което го прави един от краткия списък на стандартите, на които разчитат при управлението на всички данни“, както ми каза Щирман.

Разбира се, както всяка технология, MongoDB има своите силни и слаби страни. MongoDB е предназначен за OLTP натоварвания. Той може да прави сложни заявки, но не е непременно най-подходящ за натоварвания в стил отчитане. Или ако имате нужда от сложни транзакции, това няма да е добър избор. Простотата на MongoDB обаче го прави чудесно място за начало.

Касандра: Безопасно бягане в мащаб

Има поне два вида простота на базата данни: простота на разработка и оперативна простота. Докато MongoDB с основание получава кредит за лесно изживяване, Cassandra печели пълни оценки за лесно управление в мащаб.

Както ми каза McFadin на DataStax, потребителите са склонни да гравитират към Касандра, колкото повече се блъскат в главата срещу трудността да направят релационните бази данни по-бързи и по-надеждни, особено в мащаб. Бивш DBA на Oracle, McFadin беше развълнуван да открие, че „репликацията и линейното мащабиране са примитиви“ с Cassandra, а характеристиките са „основната цел на дизайна от самото начало“.

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

Както чух от Макфадин и други, Касандра особено блести при разгръщането на мащаба. Касандра се предлага с включена поддръжка за множество центрове за данни. Що се отнася до добавянето на капацитет към клъстер, „Вие просто зареждате нова машина и казвате на Касандра къде са останалите възли“, каза Макфадин, „и тя се грижи за останалото.“

Тази лекота на мащабиране, съчетана с изключителна производителност на запис („Всичко, което правите, е добавяне в края на регистрационен файл“) и предвидима производителност на заявките, добавят към високопроизводителен кон в Cassandra.

Една статия от вярата на NoSQL, която отдавна твърдя, е, че Касандра може да е мощна по мащаб, но за да започне, тя изисква докторска степен. Не е така, Макфадин настоя:

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

Това означава, че цената за допускане до ефективно развитие на Касандра е в разбирането на модела на данни и как ще работи с вашето приложение. Като се има предвид познаването на езика за заявки на CQL на Cassandra (предвиден да бъде „точно като SQL, освен когато не е такъв“), Макфадин каза, че това не е стръмна крива на обучение.

По-важното, той ми каза, „Касандра ви възнаграждава с едно нещо, което искате от базата данни: без драма. Ето защо потребителите обичат да използват Cassandra. "

HBase: Бум приятели с Hadoop

HBase, подобно на Касандра, ориентирано към колони хранилище с ключ-стойност, се използва много в голяма степен поради общото си родословие с Hadoop. Всъщност, както казва Кестелин на Cloudera, „HBase осигурява базиран на запис слой за съхранение, който позволява бързо, произволно четене и запис на данни, допълвайки Hadoop, като подчертава висока производителност за сметка на I / O с ниска латентност.“

Кестелин продължава:

Промените се каталогизират ефективно в паметта, за да се постигне максимален достъп, докато данните се запазват в HDFS. Този дизайн позволява на базиран на Hadoop EDH [корпоративен център за данни] да обслужва произволно четене и запис на потребители и приложения в реално време, но въпреки това се наслаждава на устойчивостта на грешки и трайността на HDFS.

Афинитетът с Hadoop не е единствената причина, поради която HBase продължава да нараства в класацията за популярност на базата данни, макар че това може да е достатъчно. Подобно на Касандра, корените на HBase като внедрена версия на Bigtable на Google с отворен код се превеждат в базата данни и са силно мащабируеми по дизайн.

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

Но мащабът не е само полезност. Както отбелязва Кестелин, „Благодарение на тясната си интеграция с останалата част от екосистемата на Hadoop, данните са лесно достъпни за потребителите и приложенията чрез SQL заявки (с помощта на Cloudera Impala, Apache Phoenix или Apache Hive) или дори фасетирано търсене на свободен текст (използвайки Cloudera Search). " По този начин HBase дава на разработчиците начин да се възползват от съществуващия опит в SQL, като същевременно надграждат върху по-модерна, разпределена база данни.

Всяка база данни идва със своите силни страни и недостатъци, но всяка от трите профилирани тук е запълнила голяма дупка в пейзажа на големите данни. Въпреки че е възможно да се появи нова база данни, която да претендира за място в тройката на NoSQL (DynamoDB?), Реалността е, че разработчиците и предприятията, които обслужват, вече се стандартизират за няколко силни опции: MongoDB, Cassandra и HBase.

Понастоящем вицепрезидент на мобилни устройства в Adobe, Мат Асей преди е бил вицепрезидент на общността в MongoDB, Inc. Той е почетен член на борда на Инициативата с отворен код (OSI) и спечели докторска степен в Станфорд, където се фокусира върху отворен код и други въпроси за лицензиране на интелектуална собственост, както и магистърска степен от университета в Кент в Кентърбъри и бакалавърска степен от университета Бригъм Йънг. Асей беше един от първите блогъри на.

Форумът New Tech предоставя място за изследване и обсъждане на нововъзникващите корпоративни технологии в безпрецедентна дълбочина и широчина. Изборът е субективен, базиран на нашия избор на технологиите, които смятаме, че са важни и представляват най-голям интерес за читателите. не приема маркетингово обезпечение за публикуване и си запазва правото да редактира цялото съдържание. Изпращайте всички запитвания на [email protected]