Когда использовать MongoDB

Я пишу приложение, которое не обязательно должно масштабировать способности, поскольку оно не будет собирать данные больших объемов в начале. (Однако, если мне повезет, я мог бы спуститься вниз по дороге.)

Я буду запускать свой веб-сервер и базу данных в том же поле (пока).

Говоря, я ищу производительность и эффективность.

Основная часть моего приложения будет загружать статьи в блогах. Используя RDBMS (MySQL), я сделаю 6 запросов (2 из входящих запросов), чтобы загрузить одну страницу статьи блога.

select blog
select blog_album
select blog_tags
select blog_notes
select blog_comments (join with users)
select blog_author_participants (join with users)

Однако MongoDB Я могу де-нормализовать и свернуть 6 таблиц всего на 2 таблицы/коллекции и минимизировать мои запросы потенциально просто один запрос,

users
blogs
    ->blog_album
    ->blog_tags        
    ->blog_notes
    ->blog_comments
    ->blog_author_participants

Теперь, перейдя к схеме MongoDB, будет избыточность данных. Однако пространство на жестком диске дешевле, чем CPU/серверы.

1.) Будет ли это хорошим сценарием для использования MongoDB?

2.) Вы используете только преимущества при использовании MongoDB при масштабировании за пределами одного сервера?

3.) Существуют ли риски устойчивости при использовании MongoDB? Я слышал, что есть потенциал для потери данных при выполнении вставок - поскольку вставка сначала записывается в память, а затем в базу данных.

4.) Должно ли это остановить меня от использования MongoDB в производстве?

Ответы

Ответ 1

Однако с MongoDB я могу де-нормализовать и свернуть 6 таблиц всего на 2 таблицы/коллекции и минимизировать мои запросы потенциально только одним запросом

Но вы можете легко запросить MySQL за 6 табличных значений информации, связанной с одним сообщением в блоге, с помощью одного правильно созданного оператора SQL.

однако место на жестком диске дешевле, чем CPU/серверы.

Если производительность и масштабирование являются приоритетными, тогда вы будете озабочены наличием достаточного количества ОЗУ для размещения всего в основной памяти и достаточного количества ядер процессора для выполнения запросов. Массив массива RAID 10 предприятия - это требование, не поймите меня неправильно, но как только ваше программное обеспечение базы данных (MongoDB или MySQL) должно сканировать индекс, который не может вписаться в основную память, вы попадете в мир боли, предполагающей большую активную базу данных.:)

Мне нравится MongoDB, но это большая сила, на мой взгляд, это карта/сокращение и ориентация на документ. Вам не требуется ни одна из этих функций. MySQL проверена временем в крупномасштабных развертываниях и поддерживает разделение (но я бы сказал, что ваша база данных должна быть в порядке 50-100 ГБ, прежде чем вы сможете добиться существенного выигрыша от разделения по сравнению с одним (плюс пассивным резервным) сервером с (64 ГБ +) оперативной памяти.Я также хотел бы утверждать, что если производительность поистине является проблемой, тогда MySQL будет предпочтительнее, так как у вас будет полный контроль над вашими индексами.

Чтобы не сказать, что MongoDB не является высокой производительностью, но его место, вероятно, не служит блогов. Ваша забота о вставках также действительна. MongoDB не является системой ACID. Транзакции Google в обеих системах и сравнить.

Ответ 2

Вы использовали бы MongoDB, когда у вас есть прецедент, соответствующий его сильным сторонам.

Вам нужен хранилище документов без схемы? Нет, у вас есть стабильная схема.

Вам нужен автоматический осколок? Нет, у вас нет чрезвычайных данных или бюджета для горизонтального масштабирования аппаратного обеспечения.

Вам нужна карта/сокращение обработки данных? Не для чего-то вроде блога.

Так почему вы даже это рассматриваете?

Ответ 3

Вот хорошее объяснение: http://mod.erni.st/2009/08/nosql-if-only-it-was-that-easy/

В последнем абзаце резюмируется следующее:

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

Ответ 4

NoSQL vs. RDBMS: яблоки и апельсины?

Я бы посоветовал вам немного почитать о том, что такое NoSQL и что он делает, прежде чем вы решите, можете ли вы его использовать. Вы не можете взять обычную базу данных и превратить ее в вещь NoSQL точно так же. То, как вы работаете с данными, совершенно другое.

NoSQL определенно использует свои возможности. Но это определенно не ответ на все. Основным преимуществом NoSQL является легко изменяемая модель данных.

Ответ 5

Преимущества использования mongodb (согласно Moshe Kaplan опубликованы в dzone article)

Схема без дизайна
Масштабируемость при управлении байтами данных Tera
Rapid replicaSet с функцией высокой доступности
Sharding обеспечивает линейный и масштабный рост без исчерпания бюджета
Поддержка высокой нагрузки на запись
Использование локальности данных для обработки запросов

MongoDB отвечает требованиям Consistency и Partitioning в теории CAP (согласованность, доступность и разделение)

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

В чем преимущества использования бесплатной базы данных, такой как MongoDB, по сравнению с реляционной базой данных?

Когда Редису? Когда в MongoDB?