Почему бы не mongodb?

Ответ 1

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

MongoDB не подходит для приложений, которые нуждаются:

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

Ответ 2

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

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

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

• хранилище не сжимается автоматически при удалении записей. Пространство, которое выделяется на каждую коллекцию, будет выделено до тех пор, пока вы не будете repair DB или не сбросите коллекцию. И он выделяется в огромных кусках на уровне БД (файлы данных), которые затем выделяются в коллекции при необходимости (экстенты). Тем не менее внутри выделенного пространства коллекции документы, которые удаляются, освобождают место для других документов в одной коллекции. Это хорошее объяснение понятий: 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 - мне нравится использовать его, и он оказался надежным и эффективным инструментом. Но чтобы правильно использовать его, вам нужно узнать о его управлении пространством.

Ответ 3

Возможные минусы:

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

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

Ответ 4

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

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

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

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

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

Ответ 5

Я работаю над несколькими системами на базе SQL DB, и после 3 лет работы mongodb (с Rong Mongoid Driver) у меня есть три основные причины.

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Все, что сказано, если MySQL подходит для вашего приложения, и вы хотите работать с NoSQL, Монго - идеальное решение.

Ответ 8

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

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

• Сервер сообщества
• Профессиональный
• Предприятие

Фактически Сервер сообщества бесплатный, а другие 2 - платные.

Я спросил парня -

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

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

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

Перед использованием версии убедитесь в этом.

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