Що слід вибрати: MongoDB / Cassandra / Redis / CouchDB? [зачинено]


75

Ми розробляємо справді великий проект, і мені було цікаво, чи може хтось дати мені якусь пораду щодо того, який сервер БД нам слід вибрати.

Наша система складається з 1100 електронних пристроїв, які відправляють сигнал на центральний сервер, а потім сервер зберігає інформацію про сигнал (довжина сигналу становить близько 35 байт). Однак коли ці пристрої будуть відправляти приблизно 3 сигнали на хвилину кожен, тож, якщо ми будемо робити де числа, це буде 4.752.000 нових записів / день у базі даних, і загалом 142.560.000 нових записів / місяць.

Нам потрібен DB Backend, який висвітлює швидко та надійно. Звичайно, нам потрібно зробити декілька складних аналізів даних на цій БД. Ми проводимо деякі дослідження на MongoDB / Cassandra / Redis / CouchDB, однак веб-сайти з документацією все ще перебувають на початковій стадії.

Будь-яка допомога? Ідеї?

Дуже дякую!


2
То які ваші критерії відбору? Наскільки швидким є db? Ви шукаєте певну функцію? Це питання дуже розмите.
Нік Ларсен


1
Що зрештою ви вирішили і як це працює?
user359996

13
Привіт, ми вирішили поїхати з Кассандрою, і це було дійсно чудово. У нас поки немає платформи тестування, але первинні тести показують, що Кассандра перевершує MySql (приблизно на 3000% швидше для записів). Ми використовуємо Thrift, щоб поспілкуватися з Кассандрою, і за цим стоїть справді активна спільнота (головним чином Twitter), тому статей не буває багато, але статті дуже корисні. Я повідомлю вам, чим це закінчується.
Juanda

7
142.560.000 на місяць - це не дуже великий набір даних насправді. Ви навіть можете використовувати RDMS для цієї мети.
DarthVader

Відповіді:


101

Не дозволяйте просторовому масштабу (1000+ пристроїв) вводити вас в оману щодо обчислювального та / або сховища. Кілька десятків 35-байтових вставок на секунду є тривіальним навантаженням для будь-якої основної СУБД, навіть на низькоякісному обладнанні. Подібним чином, 142 мільйони записів на місяць складають лише близько 1 ~ 10 гігабайт пам’яті на місяць, без стиснення, включаючи індекси.

У своєму коментарі до запитання ви сказали:

"Вся справа в надійності, масштабованості та швидкості. Дуже важливо, щоб рішення легко масштабувалось (автозаточування MongoDB?), Просто вкидаючи більше вузлів, і швидкість також дуже важлива

Надійність? Будь-яка основна СУБД може це гарантувати (припускаючи, що ви маєте на увазі, що це не призведе до пошкодження ваших даних і не призведе до збою - див. Моє обговорення теореми CAP внизу цієї відповіді). Швидкість? Навіть на одній машині в 10 ~ 100 разів це навантаження не повинно бути проблемою. Масштабованість? За нинішніх показників дані за весь рік, не стиснуті, навіть повністю проіндексовані, легко поміщаються в межах 100 гігабайт дискового простору (так само ми вже встановили, що швидкість вставки не є проблемою).

Як такий, я не бачу жодної чіткої потреби в такому екзотичному рішенні, як NoSQL, або навіть у розподіленій базі даних - проста, стара реляційна база даних, така як MySQL, була б чудовою. Якщо ви турбуєтесь про відмовостійкість, просто налаштуйте сервер резервного копіювання у конфігурації ведучого-підлеглого. Якщо ми говоримо в 100 або 1000 разів більше поточного масштабу, просто горизонтально розділіть кілька екземплярів на основі ідентифікатора пристрою збору даних ( тобто {індекс розділу} = {ідентифікатор пристрою} за модулем {кількість розділів}).

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

Все сказане, MongoDB та CouchDB надзвичайно прості в розгортанні та роботі з ними. Вони також дуже веселі і зроблять вас більш привабливим для будь-якої кількості людей (не лише для програмістів - керівників!).

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

Якщо ви позитивно налаштовані на розгортання NoSQL, ви можете розглянути теорему CAP. Це допоможе вам вибрати між MongoDB та CouchDB. Ось гарне посилання: http://blog.nahurst.com/visual-guide-to-nosql-systems . Все зводиться до того, що ви маєте на увазі під "надійністю": MongoDB торгує доступністю на постійність, тоді як CouchDB торгує на стабільність на наявність . (Кассандра дозволяє вам вдосконалити цей компроміс на кожен запит, вказавши, скільки серверів потрібно записати / прочитати для успішного запису / читання; ОНОВЛЕННЯ: Тепер може і CouchDB, з BigCouch ! Дуже захоплююче ...)

Удачі у вашому проекті.


Хоча питання не включало Ріака, що ви думаєте про це у цьому сценарії?
Марк

+1 для "MongoDB торгує доступністю для постійності, тоді як CouchDB торгує стабільністю для наявності".
Dom Vinyard

28

Значна частина відповіді залежить від того, що ви хочете з нею зробити після того, як її буде зібрано. Зберігати велику кількість даних легко: просто закиньте їх у файли журналів, не потрібно бази даних. З іншого боку, якщо ви хочете виконати складний аналіз та видобуток даних на ньому, тоді корисна база даних.

Наступне питання - який аналіз ви збираєтеся робити. Чи буде це виконуватися для підмножини даних, що мають певну властивість, лише останню годину / день / тиждень / місяць, чи можуть дані агрегуватися або якимось чином попередньо обчислюватися? Іншими словами: чи потрібен вам доступ до всього набору даних у формі, в якій він зібраний? Чи можете ви архівувати дані, коли вони старіють, щоб бути цікавими? Чи можете ви агрегувати дані та проводити аналіз на агрегації?

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

Агрегація по суті задає всі питання, які ви хочете задати щодо даних, і зберігає їх у формі, яка полегшує отримання відповіді на конкретне питання. Скажіть, що ви хочете знати, в який день тижня найбільше X. Наївна реалізація цього полягала б у збереженні всіх записаних сигналів у величезній таблиці та виконанні запиту, який підсумовує всі рядки, які мають X. Як кількість зібраних сигнали зростають, цей запит триватиме довше і довше. Жодна індексація, шардінг або оптимізація в цьому не допоможе. Замість цього кожен день / годину / хвилину (залежно від конкретного випадку використання та того, наскільки актуальною має бути ваша звітність), ви переглядаєте нові сигнали, які ви записали, і для кожного X збільшуєте лічильник, який відстежує, скільки X були в понеділок, якщо це понеділок, вівторок, якщо вівторок тощо. Таким чином ви зможете пізніше отримати підрахунок за кожен день тижня та порівняти їх. Ви робите це для всіх питань, на які ви хочете мати можливість відповісти, а потім видаляєте сигнали з бази даних (але знову ж таки зберігайте необроблені дані).

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

У системі зберігання даних старої школи говорять, що база даних, в якій ви зберігаєте вхідні сигнали, називається OLTP (для он-лайн обробки транзакцій), а база даних, в якій ви зберігаєте агрегати, називається OLAP (для онлайнової аналітичної обробки). OLTP оптимізовано для вставки, а OLAP - для запитів. Терміни застарілі, і коли люди їх чують, вони, як правило, відразу ж замислюються над SQL і про "зіркові схеми" і про все таке. Можливо, мені не слід ними користуватися, але це зручні терміни.

У будь-якому випадку, для OLTP вам потрібне щось, що швидко вставляє дані, а також те, що підтримує індексацію даних та пошук речей. Агрегації дуже допомагає база даних, яка виконує половину роботи підсумовування та пошуку максимумів і мінімумів. Мені дуже подобається MongoDB, оскільки його так легко налаштувати та працювати з ним. Дані, з якими я працюю, як правило, брудні, і не всі предмети мають однаковий набір властивостей, тому прощаюча безсхемність Монго є благом. З іншого боку, ваші дані звучать набагато одноманітніше, тому Монго, можливо, не дасть вам стільки переваг. Хоча все-таки не забувайте про старі добрі реляційні бази даних. Якщо ви збираєтеся робити багато підсумовувань тощо, тоді SQL чудовий, для цього він створений.

Для OLAP працює щось набагато простіше, сховище ключ-значення - це все, що вам потрібно. Я використовую Redis, тому що з ним дуже легко працювати і налаштовувати. Це також дозволяє зберігати більше скалярних значень, що зручно. Іноді вашим значенням є насправді список або хеш, у більшості сховищ ключ-значення вам доводиться кодувати такі значення, але Redis обробляє це спочатку. Недоліком Redis є те, що ви не можете робити запити ("як, наприклад, дайте мені всі рядки, що мають це значення для Y"), ви повинні зберігати індекси своїх даних самостійно. З іншого боку, вам дуже не знадобляться індекси, оскільки відповіді на всі ваші запитання були попередньо обчислені, все, що вам потрібно зробити, це шукати відповідь за допомогою ключа, який визначається запитанням. Для вищезазначеного питання, в який день тижня найбільше X, ви шукаєте кількість X робочих понеділка, вівторка тощо, можливо, ви '

На закінчення: MongoDB та Redis чудово працюють для мене. Я не думаю, що MongoDB дуже добре підходить для вашого випадку використання, натомість я думаю, що ви насправді можете отримати більше користі від традиційної бази даних SQL (але це залежить, якщо ваші дані дійсно прості, ви, можливо, можете використовувати Redis до кінця). Найголовніше - не помилитися, думаючи, що вам потрібно мати дані в одній базі даних і зберігати їх назавжди. Агрегація та викидання старих даних є ключовим фактором.


13

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

Завдяки своїм можливостям реплікації та RESTful API (він використовує HTTP для свого API) ви можете досить легко масштабувати горизонтально за допомогою зрілих інструментів. (Nginx або Apache для зворотного проксі-сервера, балансування навантаження HTTP тощо)

Ви пишете функції зіставлення / зменшення в JavaScript для попереднього обчислення запитів. Результати нарощуються поступово на диску, що означає, що їх потрібно обчислювати лише один раз за сигнал. Іншими словами, запити можуть бути дуже швидкими, оскільки для цього потрібно лише обчислювати дані сигналу, записані з часу останнього запуску запиту.

CouchDB торгує дисковим простором для підвищення продуктивності, тому ви можете сподіватися на те, що ви будете використовувати багато дискового простору. Якщо ви правильно їх реалізуєте, ваші запити можуть бути блискавичними та заощадити місце на диску.

Спробуйте CouchDB.

Перевірте, чому вчені Великого адронного колайдера використовують CouchDB та CouchDB у Бі-Бі-Сі як стійкий до відмов, масштабований, багатозначний центр зберігання ключів і значень


9

~ 3000 сигналів на хвилину = 50 записів / с, які будь-яка з цих систем зможе легко обробити.

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


Дякую за вашу відповідь, я перевірю Hadoop глибше, бо правда в тому, що я з ним не знайомий. Дуже дякую!
Juanda

4

Отже, ви зберігаєте дані в центральній базі даних для обробки даних? Немає обробки онлайн-транзакцій?

Я не думаю, що MongoDB робить хорошу роботу, коли справа стосується довговічності. Див. Http://nosql.mypopescu.com/post/392868405/mongodb-dubility-a-tradeoff-to-be-aware-of .

Можливо, ви можете скористатися аналітикою db Infobright, вона має спільне видання: http://www.infobright.org/ ?


Дякую за відповідь, мені не потрібна обробка онлайн-транзакцій лише зберігання для обробки даних. Я перевірю інфобрайт і повідомлю вас.
Juanda

4

Ви шукаєте сховище даних, яке може дозволити "блискавично швидкі" записи (дані зберігаються на диску), і видобуток даних відбудеться на більш пізньому етапі (це цикл READ). Крім того, враховуючи вказані вами цифри, виявляється, ви будете збирати всю 159 МБ інформації на день, або приблизно 5 ГБ на місяць.

Чому б у цьому випадку не подивитися на Редіс.

Ви завжди можете заархівувати щоденний файл даних Redis і звернутися до нього пізніше (якщо у вас є проблеми із завантаженням обсягу оперативної пам'яті обсягом 5 ГБ або більше, тоді це архівування може бути вирішено)

Редіс досить швидкий, виходячи з номерів, опублікованих на цьому сайті. Сподіваюся, це допомагає. Кіран


2

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


1
Clojure має власну підтримку транзакційної пам'яті програмного забезпечення , а не транзакцій баз даних (не кажучи вже про транзакції розподілених баз даних).
user359996

2

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


Я не знав про Ріак. Я спробую це і дам вам знати. Дякуємо за Ваш відповідь!
Juanda
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.