Причины за и против перехода с SQL-сервера на MongoDB

Question

Я знаю, что это большой вопрос, и это не ответ «да» или «нет», но мы разрабатываем веб-приложения и рассматриваем возможность использования MongoDB для нашего постоянного решения. Объединение MongoDB с NoRM для хранения объектов.

Я хочу спросить, с какими трудностями вы столкнулись при переходе с SQL на монго? Когда mongo просто не является правильным решением и достаточно ли преимуществ mongodb, чтобы перевести разработку с SQL?

Answer 1

По моему мнению, формат ваших данных должен быть основным приоритетом при выборе хранилища данных. У вас есть данные, которые носят реляционный характер? Если да, то может ли это быть хорошей идеей для моделирования данных в документах? Моделирование данных так же важно в базе данных документов, как и в реляционной базе данных, оно просто выполняется по-другому. Сколько типов объектов у вас есть и как они связаны? Может ли DBrefs в Mongodb справиться с задачей или вы пропустите внешние ключи настолько, что это будет больно? Каковы ваши шаблоны доступа к данным? Вы просто выбираете данные одного типа, отфильтрованные по значению поля, или у вас есть сложные режимы выборки?

Вам нужна ACID целостность транзакций? Применяет ли домен множество ограничений к данным? Вам нужен коэффициент масштабируемости базы данных документов или это просто "крутая" вещь, которую нужно иметь?

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

Это все вопросы, которые должны входить в выбор хранилища.

Некоторые впечатления

• Делать подробные отчеты о сохраненных данных может быть сложнее при использовании MongoDB или любой базы данных документов, и в некоторых случаях для этой цели сочетаются СУБД и document-db.
• (Очень) Другая модель запроса. MongoDB также отличается от других document-dbs.
• Гибкость для изменения формата данных / схемы во время разработки
• Неизвестная территория
• различной степени зрелости в драйверах и каркасах
• Fast
• Более простые (во многих отношениях) продукты и инструменты управления (по сравнению со многими продуктами СУБД)
• Нет больше несоответствия импеданса. Хранилище подходит для данных, а не наоборот.
• Меньше трений и более прямой доступ к данным.
• Домен более привязан к постоянству (в зависимости от "уровня" ORM в NoRM, от того, насколько сильно он абстрагируется от внутреннего интерфейса. Я не использовал NoRM, поэтому не могу ответить на него.)

Answer 2

против

1. (отсутствие / разное видение) долговечность (читать http://www.mikealrogers.com/2010/07/mongodb-performance-durability)
2. Нет транзакций
3. Без ограничений
4. Агрегирование с MapReduce происходит медленно, и вам нужно написать код для чего-то вроде group-by
5. Отчетность сложнее, разработчик определяет отношения, но бизнес-аналитики не могут строить свои собственные запросы, они не могут, например, сделать «минус» («кроме» в языке SQL Server)

плюсы

1. Вы можете легко добавлять новые «столбцы» и «таблицы»
2. Скорость
3. шардинг (все еще бета)
4. документ более точно соответствует объекту, чем набор реляционных таблиц, поэтому сопоставление становится проще
5. расширяет кругозор

Answer 3

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

Answer 4

Я возился с этим несколько дней. Вот что я могу сказать по этому поводу:

ЗА:

• Нет больше операторов SQL
• Ваша база данных похожа на ваши классы, а не наоборот
• Ваша "схема" более гибкая
• Весы хорошо
• Очень легко начать работу с
• <мнение> Это круто </ мнение>

ПРОТИВ:

• В настоящее время я пытаюсь реализовать пользовательский поставщик членства и поставщика ролей для моего приложения mongo, но каким-то образом мой пользовательский класс MemberShip имеет поля NULL, когда я пытаюсь извлечь его из mongo.
• Где-то я читал о драйвере C #, который относительно молод, но стабилизируется, поэтому ожидайте некоторых изменений. (Хотя это не будет сдерживать меня)

Одна вещь, которую я заметил, отсутствует в уроках: Инициализируйте свои списки внутри вашего объекта, в противном случае при попытке .save (yourobj) вы получите ошибку. Самое безопасное, что нужно сделать, это написать конструктор в вашем классе, который гарантирует, что у вас нет объектов NULL внутри вашего объекта. Таким образом, вы не получите ошибку, если что-то забудете.

Answer 5

Вы можете найти несколько плюсов и минусов использования базы данных NoSQL (включая MongoDB) в этом Начало работы с NoSQL .Краткое резюме будет следующим: другая модель данных (подумайте, если потребуется сопоставление объектной модели с «этой новой моделью», будет ли она работать хорошо), другая модель запросов (хотя запросы MongoDB довольно эффективны по сравнению с другими)без транзакций (хотя у вас есть несколько элементарных операций).

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

Answer 6

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

• Это смехотворно быстро по сравнению с нашими реляционными базами данных. Я редко вижу документы, возвращенные более чем за 15 мс, включая поездку в оба конца по Европе.
• Мы перестали заботиться о схеме или о ненормализации - мы просто берем наши модели dian-объектов c # и просто сериализуем их в базу данных, и это, похоже, работает довольно хорошо.