МонгоДБ проти Кассандри [закрито]

Я оцінюю, що може бути найкращим варіантом міграції.

Наразі я перебуваю на заточеному MySQL (горизонтальному розділі), більшість моїх даних зберігається у краплях JSON. У мене немає складних запитів SQL (вже переміщених після того, як я розділив db).

Зараз здається, що і MongoDB, і Кассандра були б імовірними варіантами. Моя ситуація:

• Багато читає в кожному запиті, менш регулярно пише
• Не переживає "масивна" масштабованість
• Більше стурбовані простими налаштуваннями, технічним обслуговуванням та кодом
• Мінімізуйте вартість апаратного забезпечення / сервера

Багато запитів у кожному запиті, менше регулярних записів

Обидві бази даних добре працюють при зчитуванні, де гарячий набір даних вписується в пам'ять. Обидва також наголошують на моделях даних, що не містять об'єднаних даних (а натомість заохочують денормалізацію), і обидва надають індекси на документи чи рядки , хоча індекси MongoDB наразі є більш гнучкими.

Кассандрівський накопичувач забезпечує постійний час запису незалежно від того, наскільки великий набір ваших даних. Записи є більш проблематичними в MongoDB, частково через механізм зберігання даних, що базується на b-дереві, але більше через багатогранність блокування .

Для аналітики MongoDB забезпечує власну карту / зменшення впровадження; Cassandra надає підтримку нативного Hadoop, у тому числі для Hive (сховища даних SQL, побудованого на карті Hadoop / зменшення) та Pig (мова для аналізу Hadoop, яка, на думку багатьох, є більш придатною для навантаження на карту / зменшення навантажень, ніж SQL). Кассандра також підтримує використання Spark .

Не переживає "масивна" масштабованість

Якщо ви дивитесь на один сервер, MongoDB, мабуть, краще підходить. Для тих, хто більше стурбований масштабуванням, архітектура Кассандри, яка не має жодної точки відмови, буде простішою у налаштуванні та надійнішою. (Глобальне блокування запису MongoDB теж стає більш болісним.) Кассандра також дає набагато більше контролю над тим, як працює ваша реплікація, включаючи підтримку декількох центрів обробки даних.

Більше стурбовані простими налаштуваннями, технічним обслуговуванням та кодом

І те й інше налаштовано з розумними стандартними типовими налаштуваннями для одного сервера. Кассандру простіше налаштувати в конфігурації з декількома серверами, оскільки немає жодних вузлів для особливих ролей.

Якщо ви зараз використовуєте краплі JSON, MongoDB - це шалено добре відповідне для вашого випадку використання, враховуючи, що він використовує BSON для зберігання даних. Ви зможете мати багатші та більш цікаві дані, ніж у вашій теперішній базі даних. Це була б найзначніша перемога для Монго.

Я широко використовував MongoDB (останні 6 місяців), будуючи ієрархічну систему управління даними, і я можу поручитися як за простоту налаштування (встановити її, запустити, використовувати!), Так і швидкість. Поки ви ретельно продумуєте індекси, вони можуть абсолютно кричати разом, із швидкістю.

Я вважаю, що Кассандра, завдяки використанню таких масштабних проектів, як Twitter, має кращу функціональність масштабування, хоча команда MongoDB працює над паритетом. Я мушу зазначити, що я не використовував Кассандру поза етапом випробувань, тому не можу говорити для деталей.

Справжнім свінгерів для мене, коли ми оцінювали бази даних NoSQL, був запит - Кассандра в основному є просто гігантським сховищем ключів / цінностей, а запити - трохи хитро (принаймні порівняно з MongoDB), тому для продуктивності вам доведеться дублювати досить багато даних як своєрідний індекс вручну. MongoDB, з іншого боку, використовує модель "запит за прикладом".

Наприклад, скажіть, що у вас є колекція (мова MongoDB для еквівалента таблиці RDMS), що містить користувачів. MongoDB зберігає записи як Документи, які в основному є бінарними об'єктами JSON. наприклад:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

Якщо ви хочете знайти всіх користувачів, які називаються Смітом, які мають права адміністратора, ви просто створіть новий документ (на консолі адміністратора за допомогою Javascript або у виробництві на вибраній вами мові):

{
   LastName: "Smith",
   Groups: "Admin"
}

... а потім запустіть запит. Це воно. Додані оператори для порівнянь, фільтрування RegEx тощо, але все це досить просто, а документація на основі Wiki є досить хорошою.

Чому вибирати між традиційною базою даних та сховищем даних NoSQL? Використовуйте обидва! Проблема з рішеннями NoSQL (за межами початкової кривої навчання) полягає у відсутності транзакцій - ви робите всі оновлення для MySQL і MySQL заповнюєте сховище даних NoSQL для читання - ви отримуєте вигоду від переваг кожної технології. Це додає більшої складності, але у вас вже є MySQL сторона - просто додайте MongoDB, Cassandra тощо до суміші.

Сховища даних NoSQL, як правило, значно краще, ніж традиційні БД, для тих же специфікацій - є причина, чому Facebook, Twitter, Google і більшість стартапів використовують рішення NoSQL. Це не просто вундеркінги, які отримують високий рівень нових технологій.

Я, мабуть, буду дивакуватою людиною, але я думаю, що вам потрібно залишатися з MySQL. Ви не описали справжню проблему, яку потрібно вирішити, і MySQL / InnoDB є відмінним резервним сховищем навіть для даних blob / json.

Серед веб-інженерів існує загальна хитрість намагатися використовувати більше NoSQL, як тільки з'ясовується, що використовуються не всі функції RDBMS. Це одне не є вагомою причиною, оскільки найчастіше в базах даних NoSQL є досить погані двигуни даних (те, що MySQL називає двигуном зберігання даних).

Тепер, якщо ви не такого типу, то вкажіть, будь ласка, чого не вистачає в MySQL, і ви шукаєте в іншій базі даних (наприклад, автоматичне загострення, автоматичне відключення, багатопрофільна реплікація, слабша гарантія узгодженості даних у кластер, що окупається з більшою пропускною здатністю запису тощо).

Я не використовував Кассандру, але я використав MongoDB і думаю, що це приголомшливо.

Якщо ви після простого налаштування, це все: ви просто зніміть MongoDB і запускаєте демона mongod, і це все ... це працює.

Очевидно, що це лише закваска, але розпочати роботу досить просто.

Я вчора побачив презентацію на mongodb. Я точно можу сказати, що налаштування було "простим", таким же простим, як його розпакувати та запустити. Зроблено.

Я вірю, що і mongodb, і cassandra працюватимуть практично на будь-якому звичайному апаратному забезпеченні Linux, тому ви не повинні знаходити особливих бар'єрів у цій галузі.

Я думаю, що в такому випадку, наприкінці дня, це дійде до того, до чого ви особисто почуваєтесь більш комфортно і який має набір інструментів, який ви віддаєте перевагу. Що стосується презентації на mongodb, то ведучий зазначив, що набір інструментів для mongodb досить легкий і що не було багато (вони сказали, що справді) інструментів, схожих на доступні для MySQL. Це, звичайно, був їхній досвід, тому YMMV. Одне, що мені сподобалось у mongodb, це те, що, здається, існує велика підтримка мови для нього (Python та .NET - це два, якими я в основному користуюся).

Список сайтів, які використовують mongodb, досить вражаючий , і я знаю, що твіттер просто перейшов на використання кассандри.