MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Битката на базите данни NoSQL - Сравняване на MongoDB и Cassandra

Въведение в MongoDB

MongoDB беше представен през 2009 г. от компания на име 10gen. По-късно 10gen беше преименуван на MongoDB Inc., компанията, която отговаря за разработването на софтуера и продава корпоративната версия на тази база данни. MongoDB Inc. се справя с цялата поддръжка с отличния си корпоративен екип за поддръжка денонощно. Те се ангажират да предоставят доживотна поддръжка, което означава, че клиентите избират да използват всяка версия на MongoDB и ако желаят да надстроят, тя ще бъде поддържана по всяко време. Освен това им предоставя възможност да бъдат в синхрон с всички корекции на сигурността, които компанията предлага денонощно.

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

Въведение в Касандра

Apache Cassandra е друг добре известен като безплатен и с отворен код, разпределен магазин с широки колони. Cassandra беше представена през 2008 г. от няколко разработчици от Facebook, който по-късно беше пуснат като проект с отворен код. В момента се поддържа от Apache Software Foundation и Apache в момента поддържа този проект за всякакви допълнителни подобрения.

Cassandra е система за управление на база данни NoSQL, предназначена да обработва големи количества данни в много основни сървъри и да осигурява висока наличност без нито една точка на отказ. Cassandra предлага много стабилна поддръжка за клъстери, обхващащи множество центрове за данни, с асинхронна репликация без мастер, позволяваща операции с ниска латентност за всички клиенти. Cassandra поддържа дизайна на разпространение на Amazon Dynamo с модела на данни на Bigtable на Google.

Прилики между MongoDB и Cassandra

С краткото представяне на тези две бази данни NoSQL, нека разгледаме някои от приликите между тези две бази данни:

И MongoDB, и Cassandra са типове бази данни NoSQL и разпространение с отворен код.

  • Нито една от тези бази данни не е заместител на традиционните типове бази данни за RDBMS.
  • И двете бази данни не са съвместими с ACID (атомност, консистенция, изолация, издръжливост), което се отнася до свойства на транзакциите в базата данни, които гарантират, че транзакциите в базата данни се обработват надеждно.
  • И двете бази данни поддържат хоризонтално разделяне на разделяне.
  • Последователността и нормализирането са две концепции, които тези два типа бази данни не удовлетворяват (тъй като те клонят повече към типовете база данни RDBMS)

MongoDB срещу Cassandra:Характеристики

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

Фигура 1 MongoDB срещу Cassandra – 8 основни фактора на разлика

Модел на експресивни данни

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

Фигура 2:Архитектурна диаграма MongoDB срещу Cassandra

Главен възел с висока достъпност

MongoDB поддържа един главен възел в клъстер, който контролира набор от подчинени възли. Ако главният възел падне, подчинен се избира за главен и отнема около 20-30 секунди за същото. По време на това време на забавяне клъстерът ще бъде изключен и няма да може да приеме никакви данни. Cassandra поддържа множество главни възли в клъстер и в случай, че един от главните възли излезе офлайн, мястото му ще бъде заето от друг главен възел. За сравнение, Cassandra поддържа по-висока наличност в сравнение с MongoDB, защото не засяга клъстера и е винаги достъпна.

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

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

Мащабируемост на запис

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

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

В момента MongoDB не поддържа език за заявки. Заявките в MongoDB са структурирани като JSON фрагменти. За разлика от това, Cassandra има удобен за потребителя набор от заявки, който е известен като CQL (Cassandra Query Language) и е лесно адаптируем от разработчиците, които имат предварителни познания по SQL. Как се различават техните запитвания?

Избор на записи от таблицата с клиенти:

 Касандра:

SELECT * FROM customer;

 MongoDB:

db.customer.find()

Вмъкване на записи в таблицата с клиенти:

 Касандра:

INSERT INTO customer (custid, branch, status) VALUES('appl01', 'headquarters', 'A');

 MongoDB:

db.customer.insert({ cust_id: 'appl01', branch: 'headquarters', status: 'A' })

Актуализиране на записи в таблицата с клиенти:

Касандра:

UPDATE Customer SET branch = ‘headquarters' WHERE custage > 2;

MongoDB:

db.customer.update( { custage: { $gt: 2 } }, { $set: { branch: 'headquarters' } }, { multi: true } )

Собствена агрегация

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

Модел без схема

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

Сравнение на производителността

Cassandra смята, че се представя по-добре в приложения, които изискват голямо натоварване с данни, тъй като може да поддържа множество главни възли в клъстер. Като има предвид, че MongoDB няма да бъде идеален за приложения с голямо натоварване на данни, тъй като не може да се мащабира с производителността. Въз основа на стандартния за индустрията еталон, създаден от Yahoo! наречен YCSB, MongoDB осигурява по-голяма производителност от Cassandra във всички тестове, които са изпълнили, в някои случаи на използване до 25 пъти. Когато е оптимизиран за баланс на пропускателна способност и издръжливост между Cassandra и MongoDB, MongoDB осигурява над 50% по-голяма пропускателна способност при смесени работни натоварвания и 2,5 пъти по-голяма пропускателна способност при доминиращи за четене натоварвания в сравнение с Cassandra.

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

Заключение

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


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Как да създадете потребител и да добавите роля в MongoDB

  2. Как да агрегирате по дата, когато в рамката за агрегиране е дадено пълно клеймо за време?

  3. грешка:тип параметър `D` трябва да се използва като параметър на типа за някакъв локален тип

  4. Производителност на MongoDB:Изпълняване на MongoDB Aggregations на вторични

  5. MongoDB – ограничаване на резултатите от заявка