Когда использовать MongoDB или другие системы баз данных, ориентированные на документы? [закрытый]

мы предлагаем платформу для видео - и аудио-роликов, фотографий и векторной графики. Мы начали с MySQL в качестве бэкэнда базы данных и недавно включили MongoDB для хранения всей метаинформации файлов, потому что MongoDB лучше соответствует требованиям. Например: фотографии могут иметь в EXIF информация, видео могут иметь аудио-треки, где мы хотим сохранить мета-информацию тоже. Видео и векторная графика не имеют общей метаинформации и т. д. так что я знайте, что MongoDB идеально подходит для хранения этих неструктурированных данных и их поиска.

тем не менее, мы продолжаем развивать нашу платформу и добавлять функции. Теперь одним из следующих шагов будет предоставление форума для наших пользователей. Теперь возникает вопрос: используйте базу данных MySQL, которая была бы хорошим выбором для хранения форумов и форумов-сообщений и т. д. или использовать для этого MongoDB?

Итак, вопрос: когда использовать MongoDB и когда использовать СУБД. Что бы ты взял?, mongoDB или MySQL, если бы у вас был выбор и почему вы его взяли?

11 ответов


на NoSQL: Если Бы Это Было Так Просто, автор пишет о MongoDB:

MongoDB не является хранилищем ключей / значений, это немного больше. Это определенно не РСУБД. Я не использовал MongoDB в производстве, но я использовал его немного, создавая тестовое приложение, и это очень классный комплект. Кажется, что он очень эффективен и либо имеет, либо скоро будет иметь отказоустойчивость и автошардинг (он же будет масштабироваться). Думаю, Монго ближе всех. вещь для замены РСУБД, которую я видел до сих пор. Он не будет работать для всех наборов данных и шаблонов доступа, но он построен для вашего обычного материала. Хранение того, что по сути является огромным хэшем, и возможность выбора на любом из этих ключей-это то, для чего большинство людей используют реляционную базу данных. если ваша БД 3NF, и вы не делаете никаких соединений (вы просто выбираете кучу таблиц и объединяете все объекты вместе, то есть то, что большинство людей делают в веб-приложении), MongoDB, вероятно, надерет задницу для вы.

затем, в заключение:

реальная вещь, чтобы указать, что если вы сдерживаются от создания чего-то супер удивительным, потому что вы не можете выбрать базу данных, вы делаете это неправильно. если вы знаете mysql, просто используйте его. Оптимизируйте, когда вам действительно нужно. Используйте его как магазин k/v, используйте его как СУБД, но ради бога, создайте свое приложение-убийца! Ничто из этого не будет иметь значения для большинства приложений. Facebook по-прежнему использует MySQL, много. Википедия использует MySQL, много. FriendFeed использует MySQL, много. NoSQL-отличный инструмент, но это, конечно, не будет вашим конкурентным преимуществом, это не сделает ваше приложение горячим, и, самое главное, ваши пользователи не будут заботиться ни о чем из этого.

на чем я собираюсь построить свое следующее приложение? Наверное И Postgres. Буду ли я использовать NoSQL? Возможно. Я также могу использовать Hadoop и Hive. Я могу хранить все в плоских файлах. Может, я начну взламывать маглев. Я буду использовать все, что лучше для работы. если мне нужна отчетность, я не буду использовать NoSQL. если мне нужно кэширование, я, вероятно, буду использовать Tokyo Tyrant. если мне нужна кислотность, я не буду использовать NoSQL. если мне нужна тонна счетчиков, я буду использовать Redis. если мне нужны транзакции, я буду использовать Postgres. если у меня есть тонна одного типа документов, я, вероятно, буду использовать Mongo. если мне нужно писать 1 миллиард объектов в день, я бы, вероятно, использовал Волдеморта. Если мне нужен полный текстовый поиск, я бы вероятно, используйте Solr. Если мне нужен полнотекстовый поиск изменчивых данных, я, вероятно, использую Sphinx.

Мне нравится эта статья, я нахожу ее очень информативной, она дает хороший обзор ландшафта NoSQL и шумихи. Но, и это самая важная часть, это действительно помогает задавать себе правильные вопросы, когда дело доходит до выбора между СУБД и NoSQL. Стоит прочитать ИМХО.

альтернативная ссылка на статью


после двух лет использования MongoDb для социального приложения я стал свидетелем того, что значит жить без СУБД SQL.

  1. вы в конечном итоге пишете задания, чтобы делать такие вещи, как объединение данных из разных таблиц/коллекций, что-то, что РСУБД будет делать для вас автоматически.
  2. ваши возможности запроса с NoSQL резко повреждены. MongoDb может быть ближе всего к SQL, но он все еще очень далеко позади. Доверьтесь мне. SQL-запросы супер интуитивно понятный, гибкий и мощный. Запросы MongoDb не являются.
  3. запросы MongoDb могут извлекать данные только из одной коллекции и использовать только один индекс. И MongoDb, вероятно, является одной из самых гибких баз данных NoSQL. Во многих сценариях это означает больше обращений к серверу для поиска связанных записей. А затем вы начинаете де-нормализацию данных, что означает фоновые задания.
  4. тот факт, что это не реляционная база данных, означает, что у вас не будет (Некоторые считают, что это плохо выполнение) внешний ключ ограничивает, чтобы гарантировать согласованность ваших данных. Я заверяю вас, что это в конечном итоге создаст несоответствия данных в вашей базе данных. Готовиться. Скорее всего, вы начнете писать процессы или проверки, чтобы сохранить согласованность базы данных, которая, вероятно, не будет работать лучше, чем позволить СУБД сделать это за вас.
  5. забудьте о зрелых фреймворках, таких как hibernate.

Я считаю, что 98% всех проектов, наверное, лучше с типичные СУБД SQL, чем с NoSQL.


для хранения этих неструктурированных данных

Как вы сказали, MongoDB лучше всего подходит для хранения неструктурированных данных. И это может организовать ваши данные в формат документа. Эти РСУБД альтенативы называются NoSQL хранилища данных (MongoDB, CouchDB, Волдеморт) очень полезны для приложений, которые масштабируются массово и требуют более быстрого доступа к данным из этих больших хранилищ данных.

и реализации эти базы данных проще обычных РСУБД. Поскольку это простые двоичные объекты типа ключа или документа, непосредственно сериализуемые на диск. Эти хранилища данных не применяют свойства кислоты и ни - схемы. Это не дает никаких сделки способностей. Таким образом, это может масштабироваться, и мы можем добиться более быстрого доступа (как для чтения, так и для записи).

но, напротив, RDBM применяет ACID и схемы к данным. Если вы хотите работать со структурированными данными вы можете идти вперед с RDBM.

Я бы выбрал в MySQL для создания форумы для такого рода вещи. Потому что масштаб не будет большим. И это очень простое (распространенное) приложение, которое имеет структурированные отношения между данными.


обратите внимание, что Mongo по существу хранит JSON. Если ваше приложение имеет дело с большим количеством объектов JS (с вложенностью), и вы хотите сохранить эти объекты, то есть очень сильный аргумент для использования Mongo. Это делает ваши слои DAL и MVC ультратонкими, потому что они не распаковывают все свойства объекта JS и не пытаются принудительно вписать их в структуру (схему), в которую они естественным образом не вписываются.

У нас есть система, которая имеет несколько сложных объектов JS в своем сердце, и мы любите Монго, потому что мы можем продолжать все очень, очень легко. Наши объекты также довольно аморфны и неструктурированы, и Монго впитывает это усложнение, не моргая. У нас есть пользовательский уровень отчетности, который расшифровывает аморфные данные для потребления человеком, и это было не так сложно разработать.


Я бы сказал, используйте СУБД, если вам нужны сложные транзакции. В противном случае я бы пошел с MongoDB - более гибким для работы, и вы знаете, что он может масштабироваться, когда вам нужно. (Я пристрастен хотя я работаю над проектом в MongoDB)


кому нужны распределенные, разделенные форумы? Возможно, Facebook, но если вы не создаете Facebook-конкурента, просто используйте Mysql, Postgres или все, что вам наиболее удобно. Если вы хотите попробовать MongoDB, хорошо, но не ожидайте, что он сделает магию для вас. У него будут свои причуды и общая гадость, как и у всего остального, в чем вы, я уверен, уже убедились, если действительно работали над ним.

конечно, MongoDB может быть раздут и казаться легким на поверхности, но вы будете столкнитесь с проблемами, которые уже преодолели более зрелые продукты. Не поддавайтесь соблазну так легко, а скорее подождите, пока "nosql" не созреет или не умрет.

лично я думаю, что "nosql" увянет и умрет от фрагментации, поскольку нет установленных стандартов (почти по определению). Поэтому лично я не буду делать ставку на какие-либо долгосрочные проекты.

единственное, что может сохранить "nosql" в моей книге, это если он может легко интегрироваться в Ruby или аналогичные языки и сделать язык "постоянный", почти без каких-либо накладных расходов в кодировании и дизайне. Это может произойти, но я подожду до тех пор, не сейчас, и это должно быть более зрелым, конечно.

кстати, почему вы создаете форум с нуля? Есть тонны форумов с открытым исходным кодом, которые можно настроить в соответствии с большинством требований, если вы действительно не создаете следующее поколение форумов (в чем я сомневаюсь).


после посещения Devoxx 2011 и посещения презентации от 10Gen я написал небольшой блог, сравнивающий MongoDB с базами данных РСУБД. MongoDB является одним из популярных NoSQL dbs. См. ниже:

http://blog.iprofs.nl/2011/11/25/is-mongodb-a-good-alternative-to-rdbms-databases-like-oracle-and-mysql/


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

Это одна область, для которой я действительно думаю, что MongoDB подходит, но MySQL/PostgreSQL более рекомендуется в целом. Много документирование и ресурсы разработчика в интернете, а также их функциональность и надежность.


основная причина 2, Почему вы можете предпочесть Mongo

  • гибкость в дизайне схемы (хранилище документов типа JSON).
  • масштабируемость - просто добавьте узлы, и он может масштабироваться по горизонтали довольно хорошо.

соответствующее для больших применений данных. СУБД не подходит для больших данных.


вы знаете, все эти вещи о соединениях и "сложных транзакциях" - но это был сам Монти, который много лет назад объяснил "необходимость" фиксации / отката, сказав, что "все, что делается в логических классах (а не в базе данных) в любом случае" - так что это то же самое снова и снова. Что нужно, так это тупой, но невероятно аккуратный и быстрый механизм хранения/поиска данных для 99% того, что делают веб-приложения.


Как ранее сказал , ты можешь выбирать между множеством вариантов, взгляни на все эти варианты.: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Что я предлагаю, чтобы найти лучшее сочетание: MySQL + Memcache действительно отлично, если вам нужна кислота, и вы хотите присоединиться к некоторым таблицам MongoDB + Redis идеально подходит для хранения документов Neo4J идеально подходит для графической базы данных

Что я делаю: я начинаю с MySQl + Memcache, потому что я привык, то я начать использовать другие базы данных. В одном проекте вы можете объединить MySQL и MongoDB, например !