Мне было интересно, может ли кто-нибудь сказать мне, если MongoDB или CouchDB готовы к созданию production.
Теперь я рассматриваю эти решения для хранения данных (в настоящее время я предпочитаю MongoDB), однако эти проекты довольно молоды и поэтому я предвижу, что мне придется много работать, чтобы убедить моего менеджера, что мы следует принять эту новую технологию.
Что я хотел бы знать:
Кто использует MongoDB или CouchDB сегодня в рабочей среде?
Как вы используете MongoDB/CouchDB?
Какие проблемы (если они есть) вы встретили, когда вы приняли этот новый механизм хранения (и как вы их преодолели)?
Как вы справлялись с проблемами миграции, с которыми вам приходилось сталкиваться?
Есть ли у вас хорошие/плохие впечатления от любого из этих решений, которые вы хотели бы поделиться?
Я технический директор 10gen (разработчики MongoDB), поэтому я немного предвзятый, но я также управляю несколькими сайтами, использующими MongoDB в производстве.
businessinsider уже более года использует монго в производстве. Они используют его для всего, от пользователей и сообщений в блогах, до каждого изображения на сайте.
shopwiki использует его для нескольких вещей, включая аналитику в реальном времени и уровень кэширования. Они выполняют более 1000 операций записи в секунду в довольно большую базу данных.
Если вы перейдете на страницу mongodb Production Deployments, вы увидите некоторых людей, которые используют монго в производстве.
Если у вас есть какие-либо вопросы о масштабах или масштабах развертывания производства, опубликуйте в нашем списке пользователей, и мы будем более чем рады помочь.
BBC и meebo.com использовать CouchDB, а также один из моих клиентов. Вот список других людей, использующих Couch: CouchDB в дикой природе
Основная задача состоит в том, чтобы знать, как организовать ваши документы и перестать думать с точки зрения реляционных данных.
SourceForge использует MongoDB. См. эту презентацию или читайте здесь.
Мы запускаем CouchDB в качестве замены для MySQL для наших магазинов (70.0000 пунктов/магазин, всего 4 миллиона атрибутов всех элементов, перекрестные соединения между элементами).
Наши цели:
Простая репликация с master-db на несколько клиентов с разными документами.
Быстрые предварительно рассчитанные данные, такие как "сколько частей у меня есть с этим атрибутом и этот фильтр, подходящий для этих условий"
факты:
но также:
В результате: MySQL как база данных для создания и обслуживания данных надежна и понятна и понятна. Думаю, мы этого не изменим. Но я также не хочу пропускать возможности представлений CouchDB и простоту настройки репликации.
Производственные кушетки иногда вызывали проблемы после нескольких месяцев работы из-за неправильной конфигурации и забытых логротатов (просмотр здания занимает слишком много времени или зависает, репликация останавливается), но никогда не теряла данные и всегда могла быть легко reset.
Я использую CouchDB в производстве. В настоящее время он хранит все эти "необязательные" поля, которые не были в исходной схеме БД. И сейчас я думаю о перемещении всех данных в CouchDB.
Это довольно рискованный шаг, признаюсь я. Во-первых, потому что это еще не v1.0. А во-вторых, потому что это голодный двигатель. По моим расчетам, файл CouchDB (с индексами) в 30 раз больше, чем база данных MySQL с теми же строками. Но я уверен, что все будет хорошо.
CouchDB 0.11 (выпущен в конце марта) - это релиз функции-замораживания для версии 1.0. Это означает, что мы будем поддерживать совместимость с текущим API за 1.0, поэтому сейчас самое подходящее время, чтобы еще раз взглянуть на CouchDB, если у вас нет времени.
Выпуск исходного кода CouchDB 0.11 доступен здесь. двоичный инсталляторов и других полезных свойств.
Я ничего не знаю о MongoDB, но из CouchDB FAQ:
Готова ли CouchDB для производства?
Да, см. InTheWild для частичного списка проектов с использованием CouchDB. Еще один хороший обзор - Примеры CouchDB
Кроме того, некоторые ссылки:
Мы используем couchdb в производстве и с тех пор, как проект прошел под зонтиком Apache.
Мы используем его для хранения всего, что мы могли бы использовать dbms, а также всевозможные неструктурированные данные. Лично мне очень нравится, как вы можете просто вбрасывать в него всевозможные данные и использовать представления, чтобы отбросить то, что вам не нужно, в зависимости от ситуации.
Самая сложная часть - это отход от мышления dbms. Мы писали собственные утилиты миграции, когда формат хранилища изменился просто для того, чтобы быть в безопасности, поэтому это не было проблемой.
У нас еще не было отрицательных переживаний, но опять же у нас не было установки под любой огромной нагрузкой. Я думаю, что все будет хорошо работать, так как у нас есть два сервера подчиненного типа, которые реплицируются с одного главного сервера, который получает все записи. Я уверен, что нам не нужно так поступать, чтобы репликация работала корректно, но это то, как мы настроили ее в начале и застряли.
Мы используем CouchDB для хранения мобильных входящих и исходящих сообщений и для сообщения об этом трафике через некоторые пользовательские представления, которые я написал. Интерфейс написан на Python. У нас не было никаких реальных технических проблем, и он работает с конца декабря. Единственное препятствие, с которым я столкнулся, изначально думал с точки зрения MapReduce, но как только я узнал, как это сделать, все остальное прошло гладко.
В настоящее время мы используем MongoDB в качестве слоя кэширования, а также механизм хранения для импорта и обработки данных продукта. Мы являемся компанией eCommerce, управляющей более чем двумя миллионами продуктов (более 100 миллионов атрибутов), охватывающей 10+ дистрибьюторов и без MongoDB, эта задача будет практически невозможна.
В настоящее время мы используем mongodb в качестве службы хранения файлов для нашего сотрудничества по локальной сети. Кроме того, проекты, такие как trello, используют mongodb в качестве своего backend хранилища данных. Раньше я использовал couchdb, но не в производственных возможностях.
Adobe использует MongoDB для их предстоящей публикации Adobe Experience Manager (ранее Day CQ) в качестве ядро БД.
Несколько клиентов в агентстве, в котором я работаю, используют CouchDB для проектов для крупных клиентов.
Оба являются отличными и жизнеспособными БД, на мой взгляд.:)
Говоря о производстве, бесперебойный переход на второй план требует восстановления детской няни
1- Couchbase, нет бесперебойного восстановления после сбоя/восстановления, требуется ручное вмешательство.
перебалансировка занимает слишком много времени, слишком много риска, если потеряно более одного node.
2- Mongo с осколками, восстановление данных от потери сервера конфигурации - непростая задача
Этот вопрос уже принял ответ, но теперь несколько дней NoSQL DB находится в тренде для многих своих замечательных функций. Это Couchbase
; который работает как CouchbaseLite
на мобильной платформе и Couchbase Server
на вашей стороне сервера.
Вот некоторые из основных особенностей Couchbase Lite.
Couchbase Lite - это легкий, ориентированный на документы (NoSQL), механизм синхронизации, подходящий для внедрения в мобильные приложения.
Легкий вес:
Embedded - механизм базы данных - это библиотека, связанная с приложением, а не отдельный серверный процесс. Небольшие размеры кода важны для мобильных приложений, которые часто загружаются через сотовые сети. Быстрое время запуска важно, поскольку мобильные устройства имеют относительно медленные процессоры. Низкие объемы использования памяти - типичные мобильные наборы данных относительно малы, но некоторые документы могут иметь большие мультимедийные вложения. Разумеется, хорошие показатели производительности зависят от ваших данных и приложений.
Документированные средства:
Сохраняет записи в гибком формате JSON вместо требуемых предопределенных схем или нормализации. Документы могут иметь двоичные вложения произвольного размера, такие как мультимедийный контент. Формат данных приложения может развиваться со временем без необходимости явных миграций. Индексирование MapReduce обеспечивает быстрый поиск без необходимости использования специальных языков запросов.
Syncable означает:
Любые две копии базы данных могут быть синхронизированы с помощью эффективного, надежного, проверенного алгоритма репликации. Синхронизация может быть по требованию или непрерывной (с задержкой в несколько секунд). Устройства могут синхронизироваться с подмножеством большой базы данных на удаленном сервере. Синхронизатор поддерживает прерывистые и ненадежные сетевые подключения. Конфликты могут быть обнаружены и решены, при этом логика приложения полностью контролирует процесс слияния. Деревья редактирования позволяют создавать сложные топологии репликации, включая сервер-сервер (для нескольких центров обработки данных) и одноранговую, без потери данных или ложных конфликтов. Couchbase Lite предоставляет собственные API-интерфейсы для бесшовных iOS (Objective-C) и Android (Java). Кроме того, он включает в себя подключаемый модуль Couchbase Lite для PhoneGap, который позволяет вам создавать приложения для iOS и Android, которые вы разрабатываете, используя привычные методы программирования веб-приложений и платформу для мобильных мобильных телефонов PhoneGap.
Вы можете больше узнать о Couchbase Lite
Это будет следующая важная вещь.
Мы используем mongodb в производстве для
www.beachfront.io - приближается к запросу на 5к в секунду www.beachfrontbuilder.com - 500 запросов на чтение/запись в секунду, поддержка 10-метровых данных пользователей и olap.
Единственная проблема, с которой приходится сталкиваться при архивировании данных, мы преодолеваем, реализуя наш пользовательский компонент.
Я использую CouchDB в производстве уже почти 2 года. Там не работает миграция, поскольку проект запускается непосредственно с реализацией CouchDB. Он служит в качестве базы данных, которая хранит данные одного электронного продукта с самого начала до упаковки.
Поскольку мы продаем сенсор с высокой точностью, мы проводим много испытаний на разных этапах, и все это будет храниться в одном документе на CouchDB.
Там есть какая-то кривая обучения, которую я узнал из своего опыта, которая должна полностью использовать представления (или также известные как постоянные виды). Представления должны быть "небольшим фильтром" части базы данных, которая будет вызываться часто.
My CouchDB databse не так сумасшедший, как другая гигантская компания. Но пока я все еще в порядке. В настоящее время у меня есть 24000 документов на 700 МБ.
Функция из CouchDB, которая мне нравится, это "репликация", "сохранение версий документа".
Я бы прочитал много хороших отзывов о MongoDB, и я хочу попробовать, если есть шанс.
Мы используем MongoDB для производства в нашей мобильной серверной службе, а именно Netmera. Мы используем его для хранения всех данных пользователя и контента.
Здесь приведен список рабочих мест с поддержкой mongoDB
и многое другое...
Извлечено из: http://lineofthought.com/tools/mongodb
Вы также можете проверить другие базы данных или инструменты.
У MongoDB есть некоторые проблемы с лицензированием бизнеса, я не уверен в деталях, но наш юридический отдел не сказал нам в каких-то определенных терминах, что нам не разрешили использовать MongoDB в любом из наших продуктов.