Почему не mongodb?

Question

Недавно я впервые использовал MongoDB и обнаружил, что он исключительно прост в использовании и высокопроизводителен. Что приводит к моему вопросу - почему не MongoDB?

Допустим, я реализую приложение для вопросов и ответов. Мой подход состоял бы в том, чтобы внедрить пользовательские данные в базу данных MySQL и затем использовать MongoDB для хранения вопросов и ответов - одна коллекция, хранящая вопрос и все ответы.

Что-то не так с этим подходом?

Answer 1

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

MongoDB не очень хорошо подходит для приложений, которым требуется:

1. Многообъектные транзакции: MongoDB поддерживает ACID-транзакции только для одного документа.
2. SQL: SQL хорошо известен, и многие люди знают, как писать очень сложные запросы для выполнения многих задач.Эти знания могут передаваться во многих реализациях, где язык запросов MongoDB специфичен для него.
3. Сильные ACID гарантируют: MongoDB допускает такие вещи, как несовместимое чтение, что хорошо в некоторых приложениях, но не во всех.
4. Традиционный BI: существует множество очень мощных инструментов, которые позволяют OLAP и другим сильным приложениям BI, а также работают с традиционной базой данных SQL.

Answer 2

MongoDB - великолепная база данных, и мне нравится ее использовать. Тем не менее, у вас есть несколько ошибок, если вы пришли из мира SQL.

Помимо ACID и других вещей, которые хорошо документированы (и в других ответах), эти вещи застали нас врасплох:

• MongoDB ожидает, что у вас есть память. Много памяти . Если вы не можете поместить свой рабочий набор в память, вы можете забыть об этом. Это отличается от большинства реляционных БД, которые используют память только как кеш! Если быть более точным: MongoDB использует оперативную память в качестве основного хранилища и «выгружает» ненужные части на диск (Mongo оставляет решение, какие части «переставляются» ядру). Традиционные СУБД работают наоборот - они используют диск в качестве основного хранилища и ОЗУ в качестве механизма кэширования. Так что в целом MongoDB использует больше оперативной памяти. Само по себе это неплохо, но, как следствие, «реальное» потребление ОЗУ трудно предсказать, что может привести к серьезному и неожиданному снижению производительности, когда рабочий набор вырастет (трудно предсказать ) предел.

• хранилище не сжимается автоматически при удалении записей. Пространство, выделенное для каждой коллекции, остается выделенным до тех пор, пока вы либо repair DB не удалите коллекцию. И он распределяется большими порциями на уровне БД ( файлы данных ), которые затем распределяются по коллекциям при необходимости ( extents ). Тем не менее, внутри выделенного пространства коллекции удаляемые документы ДОПУСКАЮТ свое пространство для других документов в той же коллекции. Это хорошее объяснение понятий: http://www.10gen.com/presentations/storage-engine-internals

• В отличие от SQL, который анализируется на стороне сервера, в Mongo структуры данных передаются в функции запроса и CRUD. Следствием этого является то, что каждый драйвер имеет свой синтаксис , что немного раздражает. Например, PyMongo использует список кортежей вместо словаря (вероятно, потому что dict в Python не сохраняет порядок ключей), чтобы указать, какие поля будут возвращены find(): (честно говоря, это был, вероятно, единственный разумный способ чтобы сделать это - но это является следствием не использования строкового языка, такого как SQL)
  • Оболочка MongoDB: db.test.find({}, {a:1})
  • PyMongo: db.find({}, fields=[(a,1,)]

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

Answer 3

Возможные недостатки:

1. Вы работаете в организации, которая использует только реляционные базы данных SQL. У вас нет разрешения или поддержки для использования базы данных NoSQL.
2. Вы никогда не управляли кластером MongoDB; есть кривая обучения, как и во всех технологиях.
3. Ваши данные действительно реляционные (например, у одного пользователя много вопросов; у вопроса много ответов), и вы упустили возможность.

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

Answer 4

@ johndodo об использовании памяти. На официальной странице часто задаваемых вопросов говорится, что:

Требуется ли MongoDB много оперативной памяти?

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

Технически, подсистема виртуальной памяти операционной системы управляет Память MongoDB. Это означает, что MongoDB будет использовать столько же свободной памяти как это возможно, замена на диск по мере необходимости. Развертывания с достаточным объемом памяти соответствовать рабочему набору данных приложения в ОЗУ производительность.

Так что я думаю, кривая обучения - это ответ. Чем лучше вы знаете технологию - тем лучше будет ваша система.

Answer 5

Я работал над несколькими системами на базе БД SQL, и после 3 с лишним лет работы mongodb (с драйвером Rails для mongoid) у меня есть три основные причины.

• У меня нет необходимости объединять таблицы, так что это быстрее. Большую часть времени документ содержит все, что мне нужно, если нет, я получаю соответствующий документ - опять же довольно быстро.
• Я получаю документ один раз, затем сопоставляю массив / json для сбора данных и выполнения операций. Таким образом, я получаю доступ к БД меньше, и потому что отображение / сбор данных происходит в памяти намного быстрее. Это становится еще более эффективным, когда я использую встроенные документы.
• Я могу заставить клиентов определять свои собственные поля легко и эффективно. Не стоит пытаться использовать SQL DB.

Answer 6

Добавление к другим приведенным комментариям; выбор хранилища данных (SQL или NoSQL) может сильно зависеть от ваших требований к репликации.

MongoDB следует конфигурации MySQL-esque master-slave-slave- * (1 master, множественные подчиненные). Вы можете написать ТОЛЬКО мастеру.

В географически распределенной системе это может быть неприемлемо (необходимо иметь возможность записи на любой мастер и согласовать серверы).

В таких случаях такие серверы, как Cassandra, Riak, CouchDB будут лучше в таких ситуациях.

При этом, если MySQL подходит для вашего приложения и вы хотите работать с NoSQL, Mongo - идеальное решение.

Answer 7

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

В среде виртуального хостинга нелегко найти поставщика услуг, предлагающего хостинг MongoDB. В отличие от mySql, он стал стандартом плана хостинга.

Answer 8

При определении базы данных для моего проекта я услышал, что mongoDB свободен, тогда я подумал почему бы не mongoDB?

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

1. Сервер сообщества
2. Профессионал
3. Предприятие

На самом деле Сервер сообщества бесплатный , остальные 2 оплачиваютсяпрограммное обеспечение.

Я спросил этого парня -

Где я могу использовать Сервер совместной работы mongodb?

Нижеответ, который я получил по электронной почте:

Сервер сообщества Рекомендуется использовать для среды разработки.Для производственной цели требуется корпоративное предложение.

Пожалуйста, убедитесь, что используете версию.

Надеясь, это поможет вам:)