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

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

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

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

+459
25 сент. '09 в 9:16
источник поделиться
11 ответов

В NoSQL: если только это было так просто, автор пишет о MongoDB:

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

Тогда в заключении:

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

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

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

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

+618
25 сент. '09 в 13:42
источник

Связанные вопросы


Похожие вопросы

Через два года, используя MongoDb для социального приложения, я стал свидетелем того, что на самом деле означает жить без SQL-RDBMS.

  • В конечном итоге вы записываете задания, чтобы делать такие вещи, как объединение данных из разных таблиц/коллекций, то, что RDBMS сделает для вас автоматически.
  • Возможности запроса с NoSQL сильно искалечены. MongoDb может быть самым близким к SQL, но он все еще очень далеко позади. Доверьтесь мне. SQL-запросы являются супер-интуитивными, гибкими и мощными. Запросов MongoDb нет.
  • Запросы MongoDb могут извлекать данные только из одной коллекции и использовать только один индекс. И MongoDb, вероятно, является одной из самых гибких баз данных NoSQL. Во многих сценариях это означает, что для поиска соответствующих записей требуется больше обращений к серверу. И затем вы начинаете де-нормализующие данные, что означает фоновые задания.
  • Тот факт, что он не является реляционной базой данных, означает, что у вас не будет (по мнению некоторых из них плохое выполнение) ограничений внешнего ключа, чтобы обеспечить согласованность ваших данных. Я заверяю вас, что в конечном итоге вы создадите несоответствия данных в своей базе данных. Приготовься. Скорее всего, вы начнете писать процессы или проверки, чтобы ваша база данных была последовательной, что, вероятно, не будет работать лучше, чем позволить РСУБД сделать это за вас.
  • Забудьте о зрелых фреймворках, таких как спящий режим.

Я считаю, что 98% всех проектов, вероятно, лучше подходят для типичной SQL RDBMS, чем для NoSQL.

+157
07 окт. '12 в 17:00
источник

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

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

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

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

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

+26
25 сент. '09 в 10:52
источник

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

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

+8
16 июл. '13 в 12:54
источник

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

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

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

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

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

+7
19 нояб. '10 в 3:02
источник

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

+7
25 сент. '09 в 13:33
источник

После посещения 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/

+4
19 дек. '11 в 20:41
источник

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

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

+4
28 дек. '12 в 9:53
источник

2 основные причины, по которым вы можете предпочесть Mongo, -

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

Он подходит для больших приложений данных. RDBMS не подходит для больших данных.

+4
21 июн. '13 в 5:16
источник

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

+3
01 июл. '11 в 4:48
источник

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

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

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

+1
21 авг. '13 в 8:55
источник

Посмотрите другие вопросы по меткам или Задайте вопрос