MongoDB або CouchDB - придатні для виробництва? [зачинено]

Мені було цікаво, чи хтось може мені сказати, чи готові MongoDB чи CouchDB до виробничих умов.

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

Що я хотів би знати:

1. Хто сьогодні використовує MongoDB або CouchDB у виробничих умовах?

2. Як ви використовуєте MongoDB / CouchDB?

3. З якими проблемами (якщо такі були) у вас виникли, коли ви прийняли цей новий механізм зберігання (і як ви їх подолали)?

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

5. Чи є у вас хороший / поганий досвід з будь-яким із цих рішень, якими ви хочете поділитися?

Я CTO 10gen (розробники MongoDB), тому я трохи упереджений, але я також керую кількома сайтами, які використовують MongoDB у виробництві.

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

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

Якщо ви перейдете на сторінку mongodb Production Deployments, ви побачите людей, які використовують монго у виробництві.

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

BBC і meebo.com використовувати CouchDB у виробництві і так само один з моїх клієнтів. Ось список інших людей, які використовують Couch: CouchDB в дикій природі

Основна проблема - знати, як упорядкувати свої документи та перестати думати щодо реляційних даних.

SourceForge використовує MongoDB. Дивіться цю презентацію чи читайте тут .

Ми використовуємо CouchDB в якості заміни для MySQL для наших магазинів (70,0000 предметів / магазин, загалом 4 мільйони атрибутів усіх предметів, перехресні зв’язки між предметами).

Нашими цілями були:

1. Проста копія з master-db на декілька клієнтів з різними документами.

2. Швидкі заздалегідь обчислені дані на кшталт "скільки деталей у мене з цим атрибутом і цим фільтром, що відповідає цим умовам"

факти:

1. Зараз наші магазини працюють набагато швидше, ніж для MySQL (і MySQL-базі потрібні додатково 1-3 дні попереднього розрахунку (тому оновлення було два рази на місяць), що робить дані готовими до підрахунку та фільтрації продуктів. CouchDB потребує 5 годин, так ми могли оновлювати дані про продукт щовечора)
2. Налаштування (відфільтрованого) розповсюдження та резервного копіювання даних у вузлах магазину швидко та легко

але також:

1. Зрозуміти карту / зменшити та обмежити відсутність приєднання досить складно
2. Жодна операція над такими даними, як "видалити куди" або "оновити куди" без зовнішніх програм
3. Реплікація працює добре, якщо немає проблем; то справді важко з’ясувати, що було причиною (для початківців)
4. Установка CouchDB без бінарних файлів (так, деякі є в дикій природі, але не для кожної ОС / версії) може бути важким, якщо ви не вихователь Linux. Але співтовариство CouchDB є корисним (#couchdb), і на щастя, там є компанії (cloudant, iriscouch), які пропонують послуги від безкоштовного до великого бізнесу.
5. CouchDB рухається вперед, тому відбувається багато змін (удосконалень), які можуть змінити їхній спосіб роботи. Але основні речі залишаються стабільними.

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

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

Я використовую CouchDB у виробництві. В даний час він зберігає всі ті "необов'язкові" поля, які не були в оригінальній схемі БД. І саме зараз я думаю про переміщення всіх даних на CouchDB.

Я визнаю, це досить ризикований крок. По-перше, тому що це ще не v1.0. По-друге, тому, що він зголоднів. За моїми підрахунками, файл CouchDB (з індексами) приблизно в 30 разів більший, ніж база даних MySQL з тими ж рядками. Але я впевнений, що це вийде просто чудово.

CouchDB 0,11 (випущений наприкінці березня) - це версія для заморожування функцій 1.0. Це означає, що ми будемо підтримувати сумісність з поточним API для 1.0, тому зараз настав час поглянути ще раз на CouchDB, якщо ви цього не зробили.

Випуск вихідного коду CouchDB 0,11 доступний тут. Тут пов’язані двійкові інсталятори та інші смаколики.

Я нічого не знаю про MongoDB, але з FAQ на CouchDB :

Чи готовий CouchDB до виробництва?

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

Також деякі посилання:

• Re: Поточний стан CouchDB?
• SimpleDB, CouchDB та інші "НОВІ" магазини даних - зворотній зв'язок

Ми використовуємо couchdb у виробництві і з тих пір, перш ніж проект пішов під парасольку Apache.

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

Найважча частина була відійти від мислення dbms. Ми написали власні утиліти міграції, коли формат пам’яті змінився просто на безпеку, тому насправді це не було проблемою.

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

Ми використовуємо CouchDB для зберігання мобільних вхідних та вихідних повідомлень та для звітування про цей трафік через деякі власні представлення даних, які я написав. Передня частина написана Python. У нас не було жодних реальних технічних проблем, і це триває з кінця грудня. Єдине перешкода, з яким я зіткнувся, спочатку думав з точки зору MapReduce, але як тільки я навчився це робити, все інше пройшло гладко.

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

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

Ми використовуємо MongoDB у виробництві в нашому мобільному сервісі резервних даних, а саме Netmera. Ми використовуємо його для зберігання всіх даних користувачів та вмісту.

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

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

Існує деяка крива навчання, яку я дізнався зі свого досвіду, який полягає у повному використанні поглядів (або також відомих як постійні погляди). Перегляди повинні бути "малим фільтром" частини Бази даних, яку часто називатимуть.

Моя база даних CouchDB не така божевільна, як інші гігантські компанії. Але поки що мені все одно добре. Наразі у мене є 24000 документів на 700 МБ.

Особливістю CouchDB, що мені подобається, є «реплікація», «зберігати версії документа».

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

Ми використовуємо mongodb у виробництві для

www.beachfront.io - близько 5 к запитів на секунду www.beachfrontbuilder.com - 500 запитів читання / запису в секунду, підтримка даних користувачів 10 м та olap.

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

На це питання вже було прийнято відповідь, але вже через кілька днів ще один NoSQL БД в тренді для багатьох його чудових функцій. Це Couchbase; яка працює як CouchbaseLiteна мобільній платформі, так і Couchbase Serverна стороні вашого сервера.

Ось деякі основні особливості Couchbase Lite.

Couchbase Lite - це легкий, орієнтований на документи (NoSQL), синхронізований двигун бази даних, придатний для вбудовування в мобільні додатки.

Легкі засоби:

Вбудований - двигун бази даних - це бібліотека, пов'язана з додатком, а не окремий серверний процес. Невеликий розмір коду - важливий для мобільних додатків, які часто завантажуються через стільникові мережі. Швидкий час запуску - важливо, оскільки мобільні пристрої мають відносно повільні процесори. Мале використання пам'яті - типовий набір мобільних даних порівняно невеликий, але деякі документи можуть мати великі мультимедійні вкладення. Хороша ефективність - точні цифри, звичайно, залежать від ваших даних та програми.

Документоорієнтовані засоби:

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

Syncable означає:

Будь-які дві копії бази даних можуть бути приведені в синхронізацію за допомогою ефективного, надійного, перевіреного алгоритму реплікації. Синхронізація може бути на вимогу або безперервно (із затримкою на кілька секунд). Пристрої можуть синхронізуватися з підмножиною великої бази даних на віддаленому сервері. Двигун синхронізації підтримує переривчасті та ненадійні мережеві з'єднання. Конфлікти можна виявити та вирішити, використовуючи логіку програми, що повністю контролює об'єднання. Дерева редагування дозволяють складною топологією реплікації, включаючи сервер-сервер (для декількох центрів обробки даних) і одноранговий, без втрати даних або помилкових конфліктів. Couchbase Lite пропонує вбудовані API для безшовної розробки iOS (Objective-C) та Android (Java). Крім того, він включає плагін Couchbase Lite для PhoneGap,

Ви можете дізнатися більше на Couchbase Lite

та Couchbase Server

Це переходить до наступної великої речі.

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

2- Mongo з осколками, відновлення даних після втрати конфігураційного сервера - завдання не з легких

Adobe використовує MongoDB для свого майбутнього випуску Adobe Experience Manager (раніше Day CQ ) як основного двигуна БД.

Кілька клієнтів в агентстві, в якому я працюю, використовують CouchDB в проектах для великих клієнтів.

На мою думку, обидва чудові та життєздатні БД. :)

Ось список виробничих розгорнутих сайтів з mongoDB

• Нью-Йорк Таймс : Використовуючи його в програмі для формування форм для подання фотографій. Відсутність схеми Монго дає виробникам можливість визначати будь-яку комбінацію спеціальних полів форми.
• SourceForge : використовується для резервного зберігання на перших сторінках SourceForge, сторінок проектів та сторінок завантаження для всіх проектів.
• Біт.лі
• Етсі
• IGN : надає повноваження IGN в аналізі трафіку в реальному часі та API інтерфейсу RESTful Content.
• Justin.tv : використовує внутрішні аналітичні інструменти Justin.tv щодо вірусу, збереження користувачів та загальної статистики використання, які нестандартні рішення не можуть надати.
• Пористий
• Інтуїт
• Foursquare : Заточені бази даних Монго використовуються для більшості даних у четвертинку.
• Business Insider : Використовуйте його з початку 2008 року. Всі дані сайту, включаючи публікації, коментарі та навіть зображення, зберігаються на MongoDB.
• Github : використовується для внутрішньої програми звітування.
• Екзаменатор : перенесли свій сайт із Cold Fusion та SQL Server на Drupal 7 та MongoDB.
• Grooveshark : в даний час Mongo використовує для управління понад мільйон унікальних сеансів користувача в день.
• Buzzfeed
• Обговорити
• Evite : використовується для аналітики та швидкого звітування.
• Квадратний простір
• Shutterfly : використовується для різних постійних вимог щодо зберігання даних у Shutterfly. MongoDB допомагає Shutterfly створити неперевершений сервіс, який забезпечує більш глибокі, особисті відносини між клієнтами та тими, хто найбільше має значення у їхньому житті.
• Топсія
• Поділитися цим
• Mongohq : надає хостинг-платформу для MongoDB, а також використовує MongoDB в якості резервного сервісу для свого обслуговування. Наша сторінка хостингових центрів надає додаткову інформацію про MongoHQ та інші варіанти хостингу MongoDB.

і більше...

Витягнуто з: http://lineofthought.com/tools/mongodb

Ви також можете перевірити інші бази даних чи інструменти.

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