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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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