Касандра срещу MongoDB

Обмисляте ли Cassandra или MongoDB като хранилище на данни за следващия си проект? Искате ли да сравните двете бази данни? И Cassandra, и MongoDB са „NoSQL“ бази данни, но реалността е, че те са много различни. Те имат много различни силни страни и ценностни предложения – така че всяко сравнение трябва да бъде нюансирано. Нека започнем с първоначалните изисквания... Нито една от тези бази данни не замества RDBMS, нито са „ACID“ бази данни. Така че, ако имате транзакционно натоварване, където нормализирането и последователността са основните изисквания, нито една от тези бази данни няма да работи за вас. По-добре е да се придържате към традиционните релационни бази данни като MySQL, PostgreSQL, Oracle и т.н. Сега, когато имаме далеч от релационните бази данни, нека разгледаме основните разлики между Cassandra и MongoDB, които ще ви помогнат да вземете решението. В тази публикация няма да обсъждам специфични функции, но ще посоча някои стратегически разлики на високо ниво, които да ви помогнат да направите своя избор.

1. Изразителен обектен модел

MongoDB поддържа богат и изразителен обектен модел. Обектите могат да имат свойства и обектите могат да бъдат вложени един в друг (за множество нива). Този модел е много „обектно-ориентиран“ и може лесно да представи всяка структура на обекта във вашия домейн. Можете също така да индексирате свойството на всеки обект на всяко ниво от йерархията – това е поразително мощно! Касандра, от друга страна, предлага доста традиционна структура на таблицата с редове и колони. Данните са по-структурирани и всяка колона има специфичен тип, който може да бъде посочен по време на създаването.

Заключение:Ако вашият проблемен домейн се нуждае от богат модел на данни, тогава хостингът на MongoDB е по-подходящ за вас.

2. Вторични индекси

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

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

3. Висока наличност

MongoDB поддържа модел „един главен“. Това означава, че имате главен възел и определен брой подчинени възли. В случай, че капитана падне, един от подчинените се избира за господар. Този процес се случва автоматично, но отнема време, обикновено 10-40 секунди. През това време на избори за нов лидер вашият комплект копия не работи и не може да записва. Това работи за повечето приложения, но в крайна сметка зависи от вашите нужди. Касандра поддържа модел „множество глави“. Загубата на един възел не влияе върху способността на клъстера да приема записи – така че можете да постигнете 100% време на работа за запис.

Присъда:Ако имате нужда от 100% време на работа, Cassandra е по-подходяща за вас.

4. Записване на мащабируемост

MongoDB със своя модел „един главен“ може да записва само на първичния. Вторичните сървъри могат да се използват само за четене. Така че по същество, ако имате набор от три копия на възела, само главният извършва запис, а другите два възела се използват само за четене. Това значително ограничава мащабируемостта на запис. Можете да разположите множество фрагменти, но по същество само 1/3 от вашите възли за данни могат да приемат записи. Cassandra със своя модел „множество глави“ може да записва на всеки сървър. По същество вашата мащабируемост на запис е ограничена от броя на сървърите, които имате в клъстера. Колкото повече сървъри имате в клъстера, толкова по-добре ще се мащабира.

Присъда:Ако мащабируемостта на запис е вашето нещо, Касандра е по-подходяща за вас.

5. Поддръжка на език за заявки

Cassandra поддържа езика за заявки CQL, който е много подобен на SQL. Ако вече имате екип от анализатори на данни, те ще могат да прехвърлят по-голямата част от своите SQL умения, което е много важно за големите организации. CQL обаче не е пълноценен ANSI SQL – има няколко ограничения (без поддръжка за присъединяване, без клаузи ИЛИ) и т.н. MongoDB в този момент няма поддръжка за език за заявки. Заявките са структурирани като JSON фрагменти.

Присъда:Ако имате нужда от поддръжка на езика на заявките, Cassandra е по-подходяща за вас.

6. Показатели за ефективност

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

1.  Модел на база данни  - Моделът/схемата на базата данни на приложението, което се тества, прави голяма разлика. Някои схеми са много подходящи за MongoDB, а някои са много подходящи за Cassandra. Така че, когато сравнявате бази данни, е важно да използвате модел, който работи сравнително добре и за двете бази данни.
2.  Характеристики на натоварване – Характеристиките на референтното натоварване са много важни. напр. В бенчмаркове с тежки записи бих очаквал Касандра да пуши MongoDB. Въпреки това, в бенчмаркове за тежки четене, MongoDB и Cassandra трябва да са сходни по производителност.
3. Изисквания за последователност - Това е сложно. Трябва да се уверите, че посочените изисквания за последователност за четене/запис са идентични в двете бази данни и не са предубедени към един участник. Много често в редица „Маркетингови“ бенчмаркове, копчетата са настроени, за да поставят в неизгодно положение другата страна. Така че, обърнете специално внимание на настройките за последователност.

Последното нещо, което трябва да имате предвид, е, че натоварването на бенчмарк може или не може да отразява производителността на вашето приложение. Така че, за да бъдат бенчмарковете полезни, е много важно да намерите бенчмарк натоварване, което отразява характеристиките на производителността на вашето приложение. Ето някои еталонни показатели, които може да искате да разгледате:
- Референти за производителност на NoSQL
- Cassandra срещу MongoDB срещу Couchbase срещу HBase

7. Лесна употреба

Ако бяхте задали този въпрос преди няколко години, MongoDB щеше да бъде победител. Това е доста проста задача да стартирате и стартирате MongoDB. През последните няколко години обаче Cassandra постигна големи крачки в този аспект на продукта. С приемането на CQL като основен интерфейс за Cassandra, това направи крачка напред – те направиха много лесно за легиони SQL програмисти да използват Cassandra много лесно.

Присъда:И двете са сравнително лесни за използване и се увеличават.

8. Естествено агрегиране

MongoDB има вградена рамка за агрегиране за стартиране на ETL тръбопровод за трансформиране на данните, съхранявани в базата данни. Това е чудесно за малки и средни работни места, но тъй като вашите нужди от обработка на данни стават по-сложни, рамката за агрегиране става трудна за отстраняване на грешки. Cassandra няма вградена рамка за агрегиране. За това се използват външни инструменти като Hadoop, Spark.

9. Модели без схема

В MongoDB можете да изберете да не налагате никаква схема върху вашите документи. Въпреки че това беше по подразбиране в предишни версии, в по-новата версия имате възможност да наложите схема за вашите документи. Всеки документ в MongoDB може да бъде с различна структура и вашето приложение зависи да интерпретира данните. Въпреки че това не е от значение за повечето приложения, в някои случаи допълнителната гъвкавост е важна. Cassandra в по-новите версии (с CQL като език по подразбиране) осигурява статично въвеждане. Трябва предварително да дефинирате типа на много колона.

За да обобщим, ето важните разлики във формата на таблицата:
Ако искате да видите пълната инфографика, можете да посетите нашата страница за сравнение на Cassandra срещу MongoDB.