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

Ответ 1

В 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.

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

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

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