З якими проблемами масштабування ви стикалися при використанні магазину даних NoSQL? [зачинено]

NoSQL посилається на нереляційні сховища даних, які розриваються з історією реляційних баз даних та гарантіями ACID. Популярні магазини даних NoSQL з відкритим кодом включають:

• Кассандра (таблична, написана на Java, використовується Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit і Twitter)
• CouchDB (документ, написаний в Ерланге, використовується BBC та Engine Yard)
• Диноміт (ключ-значення, написаний на Ерланг, використовується Powerset)
• HBase (ключ-значення, написане на Java, використовується Bing)
• Гіпертабельний (табличний, написаний на C ++, використовується Baidu)
• Кай (ключ-значення, написане на Ерланг)
• MemcacheDB (ключ-значення, написане на C, використовується Reddit)
• MongoDB (документ, написаний на C ++, використаний Electronic Arts, Github, NY Times та Sourceforge)
• Neo4j (графік, написаний на Java, який використовують деякі шведські університети)
• Проект Voldemort (ключ-значення, написаний на Java, використовується LinkedIn)
• Redis (ключ-значення, написане на C, використовується Craigslist, Engine Yard та Github)
• Riak (ключ-значення, написаний на Ерланг, використовується Comcast та Mochi Media)
• Ringo (ключ-значення, написаний на Ерланг, використовується Nokia)
• Скаляріс (ключ-значення, написане в Ерланге, використовується OnScale)
• Terrastore (документ, написаний на Java)
• ThruDB (документ, написаний на C ++, використовується JunkDepot.com)
• Токіо Кабінет / Токіо-Тиран (ключова цінність, написана на мові С, використовується Mixi.jp (японський сайт соціальних мереж))

Мені хотілося б дізнатися про конкретні проблеми, які ви - читач SO - вирішили, використовуючи сховища даних та використовуваний вами NoSQL-сховище даних.

Запитання:

• Які проблеми зі масштабованістю ви використовували для зберігання даних NoSQL?
• Який магазин даних NoSQL ви використовували?
• Яку базу даних ви використовували до переходу на сховище даних NoSQL?

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

Я переключив невеликий підпроект з MySQL на CouchDB, щоб мати змогу впоратися з навантаженням. Результат був дивовижним.

Близько 2 років тому ми випустили самостійно написане програмне забезпечення на веб-сайті http://www.ubuntuusers.de/ (це, мабуть, найбільший веб-сайт німецької спільноти Linux). Сайт написаний на Python, і ми додали проміжне програмне забезпечення WSGI, яке змогло схопити всі винятки та відправити їх на інший невеликий веб-сайт, що працює на MySQL. Цей невеликий веб-сайт використовував хеш для визначення різних помилок, а також зберігав кількість випадків і останнє виникнення.

На жаль, незабаром після виходу веб-сайт trackback-logger більше не реагував. У нас були деякі проблеми з блокуванням з виробничим db нашого основного сайту, який викидав винятки майже кожного запиту, а також кілька інших помилок, яких ми не досліджували на етапі тестування. Серверний кластер нашого головного сайту, який називається traceback-logger, подає сторінку кілька к разів на секунду. І це було занадто багато для маленького сервера, який розміщував реєстратор зворотного звороту (це вже був старий сервер, який використовувався лише для цілей розробки).

У цей час CouchDB був досить популярним, і тому я вирішив спробувати його і написати невеликий прослідковувач із ним. Новий реєстратор складався лише з одного файлу python, який містив список помилок із параметрами сортування та фільтрування та сторінкою подання. І на задньому плані я розпочав процес CouchDB. Нове програмне забезпечення надзвичайно швидко реагувало на всі запити, і ми змогли переглянути велику кількість автоматичних звітів про помилки.

Цікавим є те, що раніше рішення працювало на старому спеціалізованому сервері, де новий веб-сайт, заснований на CouchDB, працював лише на спільному екземплярі xen з дуже обмеженими ресурсами. І я навіть не використовував силу магазинів ключових значень, щоб масштабувати горизонтально. Можливості CouchDB / Erlang OTP обробляти паралельні запити, не блокуючи нічого, вже було достатньо для задоволення потреб.

Тепер швидко написаний реєстратор CouchDB-traceback все ще працює і є корисним способом дослідження помилок на головному веб-сайті. У будь-якому разі приблизно раз на місяць база даних стає занадто великою, і процес CouchDB вбивається. Але потім, компактна db команда CouchDB знову зменшує розмір з декількох ГБ до деяких КБ, і база даних знову працює і працює (можливо, я повинен розглянути можливість додавання там cronjob ... 0o).

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

Насправді мій поточний проект

Зберігання 18000 об’єктів у нормалізованій структурі: 90 000 рядків у 8 різних таблицях. Витягнули 1 хвилину, щоб отримати та відобразити їх у нашій об'єктній моделі Java, це все правильно індексовано тощо.

Зберігання їх як пари ключів / значень, використовуючи полегшене подання тексту: 1 таблиця, 18000 рядків, 3 секунди, щоб отримати їх усіх і відновити об'єкти Java.

З точки зору бізнесу: перший варіант був нездійсненним. Другий варіант означає, що наша програма працює.

Деталі технології: працює на MySQL як для SQL, так і для NoSQL! Дотримуватися MySQL для хорошої підтримки транзакцій, продуктивності та перевірених результатів роботи за те, що вони не пошкоджують дані, масштабування досить добре, підтримка кластеризації тощо.

Наша модель даних у MySQL - це лише ключові поля (цілі числа) та велике поле "значення": в основному велике поле TEXT.

Ми не ходили ні з одним із нових гравців (CouchDB, Cassandra, MongoDB тощо), оскільки, хоча кожен з них пропонує чудові функції / продуктивність по-своєму, завжди були недоліки для наших обставин (наприклад, відсутні / незріла підтримка Java).

Додаткова вигода від (ab) використання MySQL - біти нашої моделі, які працюють реляційно, можуть бути легко пов'язані з нашими даними зберігання ключів / цінностей.

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

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

Todd Hoff's highscalability.com має велике висвітлення NoSQL, включаючи деякі тематичні дослідження.

Комерційна стовпчаста СУБД Vertica може відповідати вашим цілям (навіть якщо вона підтримує SQL): це дуже швидко порівняно з традиційними реляційними СУБД для аналітичних запитів. Дивіться нещодавній документ CACM Stonebraker та ін., Протиставляючи Vertica із зменшенням карт.

Оновлення: а також вибрана Кассандра від Twitter у кількох інших, зокрема HBase, Voldemort, MongoDB, MemcacheDB, Redis та HyperTable.

Оновлення 2: Рік Кеттелль щойно опублікував порівняння декількох систем NoSQL у магазинах даних високої продуктивності . І робота Highscalability.com на папері Ріка тут .

Частину наших даних ми перемістили з mysql в mongodb, не стільки для масштабованості, скільки більше, оскільки вони краще підходять для файлів і нетабличних даних.

Зараз у виробництві ми зберігаємо:

• 25 тис. Файлів (60 Гб)
• 130 мільйонів інших "документів" (350 Гб)

із щоденним обігом близько 10 ГБ.

База даних розгорнута у "парній" конфігурації на двох вузлах (6x450GB sas raid10) з клієнтами apache / wsgi / python за допомогою mongodb python api (pymongo). Налаштування диска, ймовірно, є надмірним, але ось що ми використовуємо для mysql.

Окрім деяких проблем із потоками пупок Pymongo та блокувальним характером сервера mongodb, це був хороший досвід.

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

CouchDB: тематичне дослідження

По суті, програма textme використовувала CouchDB для вирішення проблеми, що вибухнула. Вони виявили, що SQL надто повільно обробляти велику кількість архівних даних, і перенесли їх на CouchDB. Це відмінне прочитання, і він обговорює весь процес з'ясування того, які проблеми CouchDB може вирішити і як вони врешті-решт вирішують їх.

Ми перемістили деякі наші дані, які ми зберігали в Postgresql, і Memcached у Redis . Запаси ключових значень набагато краще підходять для зберігання даних ієрархічних об'єктів. Ви можете зберігати дані краплин набагато швидше та з набагато меншим часом та зусиллями на розробку, ніж використовуючи ORM для зіставлення вашої крапки в RDBMS.

У мене є клієнт із відкритим кодом c # redis, який дозволяє зберігати та отримувати будь-які об’єкти POCO з 1 рядка:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

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

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

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

Я не маю досвіду з перших рук., Але мені цей запис у блозі був досить цікавим.

Я намагаюсь зіставити об’єкти домену програмного забезпечення (наприклад, aSalesOrder, aCustomer ...) на двовимірну реляційну базу даних (рядки та стовпці), яка потребує великого коду, щоб зберегти / оновити, а потім знову інстанціювати екземпляр об’єкта домену з кількох таблиць . Не кажучи вже про ефективність приєднання всіх цих приєднань, усіх цих дисків читає ... просто для перегляду / маніпулювання об’єктом домену, таким як замовлення на продаж або запис клієнтів.

Ми перейшли до систем управління базами даних об'єктів (ODBMS). Вони виходять за межі можливостей перелічених систем noSQL. GemStone / S (для Smalltalk) є таким прикладом. Є й інші рішення ODBMS, які мають драйвери для багатьох мов. Ключовою перевагою для розробника, ієрархією вашого класу є автоматично ваша схема бази даних, підкласи та всі. Просто використовуйте об'єктно-орієнтовану мову, щоб зробити об'єкти стійкими до бази даних. Системи ODBMS забезпечують цілісність транзакцій на рівні ACID, тому вона також працюватиме у фінансових системах.

Я перейшов з MySQL (InnoDB) на кассандру для системи M2M, яка в основному зберігає часові ряди датчиків для кожного пристрою. Кожні дані індексуються (device_id, дата) та (device_id, type_of_sensor, date). Версія MySQL містила 20 мільйонів рядків.

MySQL:

• Налаштування в синхронізації master-master. Небагато проблем виникло навколо втрати синхронізації . Це було стресом і особливо на початку могло зайняти години, щоб виправити.
• Час вставки не був проблемою, але запит вимагав все більшої кількості пам'яті в міру зростання даних. Проблема в тому, що індекси розглядаються в цілому. У моєму випадку я використовував лише дуже тонкі частини індексів, які були необхідні для завантаження в пам'ять (лише кілька відсотків пристроїв часто контролювались, і це було за останніми даними).
• Це було важко зробити резервне копіювання . Rsync не в змозі робити швидке резервне копіювання у великих файлах таблиці InnoDB.
• Швидко стало зрозуміло, що це оновити схему важких таблиць неможливо , оскільки це зайняло занадто багато часу (годин).
• Імпорт даних займав години (навіть коли індексація була зроблена в кінці кінців). Найкращим планом порятунку було завжди зберігати кілька копій бази даних (файл даних + журнали).
• Перехід від однієї хостингової компанії до іншої був справді великою справою . З реплікацією треба було поводитися дуже обережно.

Кассандра:

• Навіть простіше в установці, ніж MySQL.
• Вимагає багато оперативної пам’яті. Екземпляр 2 Гб не міг змусити його запускатись у перших версіях, тепер він може працювати на екземплярі 1 ГБ, але це не ідея (занадто багато промиває дані). Надання 8 Гб в нашому випадку було достатньо.
• Після того, як ви зрозумієте, як ви впорядковуєте свої дані, зберігання легко. Запит трохи складніший. Але як тільки ви його обійшли, це дійсно швидко (ви дійсно не можете помилитися, якщо цього не хочете).
• Якщо попередній крок був зроблений правильно, він є і залишається надшвидким.
• Майже здається, що дані організовані для резервного копіювання. Кожні нові дані додаються як нові файли. Я особисто, але це не дуже добре, щодня і перед кожним вимкненням (зазвичай для оновлення) обробляйте дані, щоб відновити потрібно менше часу, тому що у нас менше журналів для читання. Це не створює багато файлів, вони стискаються.
• Імпорт даних швидкий, як пекло. І чим більше хостів у вас швидше. Експорт та імпорт гігабайт даних вже не є проблемою.
• Немає схеми - дуже цікава річ, оскільки ти можеш змусити вас еволюціонувати дані відповідно до ваших потреб. Що може означати наявність різних версій даних одночасно в одній родині стовпців.
• Додавання хоста було простим (хоча і не швидким), але я цього не робив під час налаштування мультицентру даних.

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

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

Однак якщо ви хочете використовувати ОС Windows, вибір баз даних NoSQL обмежений. І не завжди є постачальник C #

Я спробував MongoDB, і це було в 40 разів швидше, ніж Sqlite, тому, можливо, я повинен його використовувати. Але я все ще сподіваюся на просте в процесі рішення.

Я використовував redis для зберігання журналів повідомлень на машинах. Це було дуже просто у виконанні та дуже корисно. Редіс справді скелі

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

У минулому я використовував Couchbase, і ми зіткнулися з проблемами відновлення балансу та безліччю інших проблем. В даний час я використовую Redis в декількох виробничих проектах. Я використовую redislabs.com - це керований сервіс для Redis, який піклується про масштабування ваших кластерів Redis. Я опублікував у своєму блозі на веб-сайті http://thomasjaeger.wordpress.com відео про збереження об'єкта, де показано, як використовувати Redis у моделі постачальника та як зберігати свої об'єкти C # у Redis. Поглянь.

Я б закликав когось, хто читає це, спробувати Couchbase ще раз, коли 3.0 за дверима. Існує понад 200 нових функцій для початківців. Функціональні можливості, доступність, масштабованість та зручність управління Couchbase Server створює надзвичайно гнучку, високодоступну базу даних. Інтерфейс управління вбудований, і API автоматично виявляють вузли кластера, тому немає необхідності в балансуванні навантаження від програми до БД. Поки ми не маємо керованого сервісу на даний момент, ви можете запускати couchbase на таких речах, як AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers, як CloudSoft, та багато іншого. Що стосується перебалансування, то це залежить від того, що конкретно ви маєте на увазі, але Couchbase не автоматично відновлює баланс після відмови вузла, як було розроблено, але адміністратор може налаштувати автоматичну відмову при відмові першого вузла, використовуючи наші API, ви також можете отримати доступ до vbuckets-реплік для читання перед тим, як активувати їх або використовувати RestAPI, ви можете застосувати відмову інструментом моніторингу. Це особливий випадок, але це можливо зробити.

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

1. Couchbase Server 3.0
2. Посібник з адміністрації
3. REST API
4. Посібники для розробників

Нарешті, я також рекомендую вам перевірити N1QL для розподілених запитів:

1. Підручник з N1QL
2. Посібник по N1QL

Дякуємо за прочитане та повідомте мені чи іншим, якщо вам потрібна додаткова допомога!

Остін

Я використовував Vertica в минулому. Він покладається на стовпчасте стиснення і прискорює читання дисків і знижує потреби в сховищі, щоб максимально використовувати ваше обладнання. Швидше завантаження даних та більша паралельність дозволяють подавати аналітичні дані більшості користувачів із мінімальною затримкою.

Раніше ми запитували базу даних Oracle з мільярдами записів, а продуктивність була дуже неоптимальною. Запити зайняли від 8 до 12 секунд, навіть після оптимізації за допомогою SSD. Отже, ми відчули необхідність використовувати більш оптимізовану для читання оптимізовану базу даних. З Vertica Clusters за низьким рівнем обслуговування ми можемо запускати API з низькою ефективністю.

Vertica зберігає дані в проекціях у форматі, який оптимізує виконання запитів. Як і в матеріалізованих представленнях, проекції зберігають набори результатів на диску АБО SSD, а не обчислюють їх щоразу, коли вони використовуються в запиті. Прогнози надають такі переваги:

1. Стискайте та кодуйте дані, щоб зменшити місце для зберігання.
2. Спростіть розподіл по кластеру баз даних.
3. Забезпечити високу доступність та відновлення.

Vertica оптимізує базу даних, розподіляючи дані по кластері за допомогою сегментації.

1. Сегментація розміщує частину даних на вузлі.
2. Він рівномірно розподіляє дані по всіх вузлах. Таким чином, кожен вузол виконує фрагмент процесу запиту.
3. Запит працює на кластері і кожен вузол отримує план запиту.
4. Результати запитів агрегуються та використовуються для створення результату.

Докладнішу інформацію див. У документації Vertica @ https://www.vertica.com/knowledgebase/