Когда использовать MongoDB или другие системы баз данных, ориентированные на документы? [закрыто]
Нет никакой разницы, когда механизм оптимизации запросов разбивает его на соответствующие операторы запроса.
3 ответа
В NoSQL: If Only It Was That Easy автор пишет о MongoDB:
MongoDB - это не хранилище ключей / значений, это нечто большее. Это определенно не РСУБД. Я не использовал MongoDB в производстве, но я использовал его для создания тестового приложения, и это очень крутой комплект. Он кажется очень производительным и либо имеет, либо скоро будет иметь отказоустойчивость и автоматическое шардирование (иначе говоря, он будет масштабироваться). Я думаю, что Mongo может быть самой близкой к замене СУБД, которую я видел до сих пор. Он не будет работать для всех наборов данных и шаблонов доступа, но он создан для ваших типичных CRUD-материалов. Хранение того, что по сути является огромным хешем, и возможность выбора любого из этих ключей - вот для чего большинство людей используют реляционную базу данных. Если ваша БД - 3NF, и вы не выполняете никаких объединений (вы просто выбираете кучу таблиц и объединяете все объекты, AKA то, что большинство людей делают в веб-приложении), MongoDB, вероятно, надерет задницу за вы.
Затем, в заключение:
На самом деле следует отметить, что если вы не можете создать что-то супер-классное, потому что вы не можете выбрать базу данных, вы делаете это неправильно. Если вы знаете mysql, просто используйте его. Оптимизируйте, когда вам действительно нужно. Используйте его как магазин AK / V, используйте его как rdbms, но, ради бога, создайте свое убийственное приложение! Все это не имеет значения для большинства приложений. Facebook по-прежнему много использует MySQL. Википедия очень часто использует MySQL. FriendFeed много использует MySQL. NoSQL - отличный инструмент, но он, безусловно, не будет вашим конкурентным преимуществом, он не сделает ваше приложение популярным и, что самое главное, ваших пользователей это не волнует.
На чем я собираюсь создать свое следующее приложение? Наверное, Postgres. Я буду использовать NoSQL? Может быть. Я также могу использовать Hadoop и Hive. Я могу хранить все в плоских файлах. Может, начну взламывать Маглев. Я буду использовать все, что лучше всего подходит для работы. Если мне понадобится отчетность, я не буду использовать никакой NoSQL. Если мне нужно кеширование, я, вероятно, воспользуюсь Tokyo Tyrant. Если мне нужна ACIDity, я не буду использовать NoSQL. Если мне понадобится тонна счетчиков, я воспользуюсь Redis. Если мне нужны транзакции, я буду использовать Postgres. Если у меня есть тонна документов одного типа, я, вероятно, буду использовать Mongo. Если мне нужно писать 1 миллиард объектов в день, я, вероятно, воспользуюсь Волдемортом. Если мне нужен полнотекстовый поиск, я бы, вероятно, использовал Solr. Если мне нужен полнотекстовый поиск изменчивых данных, я бы, вероятно, использовал Sphinx.
Мне нравится эта статья, я считаю ее очень информативной, она дает хороший обзор ландшафта NoSQL и шумихи. Но, и это самая важная часть, это действительно помогает задавать себе правильные вопросы, когда дело доходит до выбора между СУБД и NoSQL. Стоит прочитать IMHO.
Я бы сказал, что если вам нужны сложные транзакции, используйте СУБД. В противном случае я бы выбрал MongoDB - более гибкий в работе, и вы знаете, что он может масштабироваться, когда вам нужно. (Я пристрастен - я работаю над проектом MongoDB)
для хранения этих неструктурированных данных
Как вы сказали, MongoDB лучше всего подходит для хранения неструктурированных данных. И это может организовать ваши данные в формате документа. Эти альтернативы СУБД, называемые NoSQL хранилищами данных ( MongoDB , CouchDB , Voldemort ), очень полезны для приложений, которые масштабируются и требуют более быстрых данных. доступ из этих больших хранилищ данных.
И реализация этих баз данных проще, чем обычная СУБД. Поскольку это простые двоичные объекты с ключом или в стиле документа, непосредственно сериализуемые на диск. Эти хранилища данных не применяют свойства ACID и какие-либо схемы . Это не предоставляет никаких возможностей транзакции . Таким образом, это может масштабироваться, и мы можем добиться более быстрого доступа (как для чтения, так и для записи).
Но, напротив, RDBM применяет ACID и схемы к данным. Если вы хотите работать со структурированными данными, вы можете использовать RDBM.
Я бы выбрал MySQL для создания форумов для такого рода вещей. Потому что это не будет масштабным. И это очень простое (распространенное) приложение, в котором есть структурированные отношения между данными.