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

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

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

Таким образом, вопрос в том, когда использовать MongoDB, а когда использовать RDBMS. Что бы вы взяли, mongoDB или MySQL, если бы у вас был выбор и почему вы его выбрали?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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