Я знаю, что это большой вопрос, и это не ответ "да" или "нет", но мы разрабатываем веб-приложения и изучаем использование MongoDB для нашего решения настойчивости. Объединение MongoDB с NoRM для хранения объектов.
То, что я хочу спросить, это то, что вы испытывали при переходе с SQL на mongo? Когда mongo просто не является правильным решением и является преимуществом mongodb, достаточным для перемещения разработки из SQL?
По моему мнению, формат ваших данных должен быть основной проблемой при выборе хранилища. У вас есть данные, которые являются реляционными по своей природе? Если да, может ли это и хорошо ли моделировать данные в документах? Моделирование данных так же важно в базе данных документов, как и в реляционной базе данных, это просто сделано по-другому. Сколько типов объектов у вас есть и как они связаны? Может ли DBrefs в Mongodb сделать трюк или вы будете скучать по иностранным ключам, так это будет больно? Каковы ваши шаблоны доступа для данных? Вы просто извлекаете данные одного типа, отфильтрованные по значению поля, или у вас запутанные режимы выборки?
Вам нужна целостность транзакций ACID? Предоставляет ли домен большое количество ограничений на данные? Вам нужен коэффициент масштабируемости базы данных документов или это просто "крутая" вещь?
Каковы ваши требования к целостности и целостности данных? Некоторые решения NoSQL и MongoDB, в частности, совершенно свободны от последовательности записи, чтобы получить производительность. NoSQL не является однородным ландшафтом и другими продуктами, например. CouchDB имеет другие характеристики в этом отделе. Некоторые также настраиваются.
Это все вопросы, которые должны войти в выбор хранилища.
Некоторые впечатления
против
профи
Я уже несколько дней выкарабкался с ним. Вот что я могу сказать об этом:
FOR:
ПРОТИВ:
Одна вещь, которую я заметил, что отсутствует в учебниках: Инициализируйте свои списки внутри своего объекта, иначе он выкинет ошибку при попытке .save(yourobj). Самое безопасное, что нужно сделать, это написать конструктор в своем классе, который гарантирует, что у вас нет объектов NULL внутри вашего объекта. Таким образом, вы не получите ошибку, если что-то забыли.
Ваш пробег может отличаться, но это быстрый график, который я собрал, чтобы сравнить скорость обновления нескольких "строк таблицы" (неиерархический плоский документ в MongoDB) с индексом и без него, чтобы дать нам представление о том, как это сделать будет масштабироваться для нашего приложения.
Вы можете найти несколько плюсов и минусов использования базы данных NoSQL (включенной MongoDB) в этом Начало работы с NoSQL. Краткое резюме было бы: другая модель данных (подумайте, нужно ли сопоставление объектной модели с "этой новой моделью", будет ли она работать хорошо), другая модель запросов (запросы MongoDB довольно эффективны, хотя по сравнению с другими), никаких транзакций (у вас есть некоторые атомарные операции, хотя).
В любом случае, с моей точки зрения, наиболее важным изменением является модель данных и то, как вы разрабатываете свое приложение с помощью этого нового подхода.