Перемещение хранилища в интернет-магазине NoSQL.

Question

Если бы у вас было решение для интернет-магазина, основанное на реляционной БД SQL Server, что было бы причиной, если таковые имеются, для перехода на хранилище NoSQL? Имеет ли смысл даже переносить хранилища данных, которые сильно зависят от отношений с NoSQL? Если вы начнете с нуля, вы бы предпочли решение NoSQL реляционному для проекта интернет-магазина, который через некоторое время снова получит набор таблиц, таких как Статьи, Классификации, Налоговые ставки, Прайс-листы и т. Д., И величину отношений между ними.

Какова поддержка .NET (4.0) для MongoDB или MongoDB для .NET 4.0? Могу ли я рассчитывать на богатые инструменты генерации кода, подобные мастеру EF, мастеру L2SQL и т.д. для MongoDB?

Потому что, как я уже прочитал, NoSQL в основном подходят для хранения документов, более простых объектных моделей.

Ваш ответ на этот вопрос поможет мне принять правильные решения по проектированию инфраструктуры.

ОБНОВЛЕНИЕ: Если бы я разрабатывал свое решение для ASP.NET MVC и в значительной степени полагался на классы Model, был бы самый простой способ выбрать DB4o для простой сериализации и десериализации моих объектов в хранилище данных и из хранилища данных?

Answer 1

Ну, вполне открытый вопрос.

Миграция в NoSQL-хранилище данных для существующего программного обеспечения

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

Имеет ли смысл даже переносить хранилища данных, которые сильно зависят от отношений с NoSQL?

Хорошо, вы должны учитывать, что три технологии (Document-DB, RDBMS, Object Database) очень отличаются друг от друга.

• В реляционном мире вы нормализуете данные и объединяете их во время выполнения. Это прекрасно работает, пока размеры данных не слишком велики. Здесь часто начинаются проблемы: когда у вас много нормализованных данных, вам нужно выполнить много объединений, что приводит к высокой производительности. И, конечно, отображение между вашими объектами и таблицами может быть довольно сложным.
• В объектной базе данных каждый объект хранится индивидуально, а «отношения» хранятся в виде указателей. Поэтому, когда объект A имеет ссылку на объект B, база данных объектов сохраняет эту ссылку. Таким образом, для извлечения «отношения» не требуется никаких операций соединения. Поэтому «отношения» дешевы. В заключение, объектные базы данных действительно хороши в обработке отношений.
• В базе данных документов, такой как MongoDB, полный граф объектов хранится в виде документа. База данных документов работает с уровнем документа. Так что здесь нет настоящих «отношений». Вы обычно просто храните / загружаете документы. Поэтому, когда вы можете смоделировать свои сценарии так, чтобы большинство ваших операций работали только с одним документом, это очень производительно и просто.

Вот хорошее сообщение в блоге , в котором сравниваются различия в дизайне MongoDB (база данных документов) и db4o (база данных объектов)

В конце ваша модель должна соответствовать вашей базе данных. Например, не пытайтесь использовать модель для базы данных отношений и сохраняйте ее 1: 1 в базе данных документов. См. Также Блог Айенде о моделировании для базы данных объектов .

Какова поддержка в .NET (4.0) для MongoDB или в MongoDB для .NET 4.0?

Гейтс VP уже ответил на это для MongoDB . .NET 4.0-версия db4o находится в разработке. Между тем версия 3.5 также отлично работает на основе 4.0.

Могу ли я рассчитывать на многофункциональные инструменты генерации кода, подобные мастеру EF, мастеру L2SQL и т. Д. Для MongoDB?

Для MongoDB и db4o вам не нужно генерировать код. Ваши классы являются схемой. Вы просто храните свои объекты, а все остальное заботится база данных. См. Также Ответ Гейтса VP

Потому что, как я уже прочитал, NoSQL в основном подходят для хранения документов, более простых объектных моделей.

Ну, диапазон довольно большой. От действительно простых хранилищ значений ключей до более совершенных баз данных документов, баз данных, ориентированных на столбцы, баз данных графов и баз данных объектов.

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

Answer 2

ОК, это много вопросов, давайте посмотрим, на какие из них я действительно могу ответить.

Имеет ли смысл переносить существующие реляционные хранилища данных?

Нет, если только у вас не очень большая проблема с производительностью. Дело в том, что проблемы с производительностью в масштабе сети обычно решаются путем денормализации. MongoDB - это изначально денормализованная база данных.

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

Да. MongoDB очень подходит для типичных веб-проектов. Однако, если у вас есть большой опыт работы с SQL, вы, вероятно, сочтете эту отчетность немного неловкой.

.NET 4.0 поддержка? Могу ли я рассчитывать на богатые инструменты генерации кода, подобные мастеру EF, мастеру L2SQL и т. Д. Для MongoDB?

В Mongo есть драйвер для .NET.

Там нет мастера L2SQL или EF для Mongo, но на самом деле не должно быть. Честно говоря, больше всего вам будет не хватать Enterprise Manager для анализа БД.

MongoDB на самом деле не нуждается в мастере EF. EF - это решение MS для «несоответствия импеданса» между БД и объектами. MongoDB не имеет «несоответствия импеданса», просто заполняет объекты в БД и уходит. Многое из этого относится и к L2SQL. Люди создали некоторую поддержку Linq (просто быстрый Google), но такие вещи, как объединения, не будут работать, потому что Монго не делает объединений.

С точки зрения «объектов данных», Mongo нужна только очень легкая структура. Честно говоря, это так же просто, как вставить свойства в БД. Если вы хотите «добавить столбец», вы просто добавляете свойство к своему объекту, и оно начинает сохраняться в БД. Таким образом, такие вещи, как L2SQL, становятся действительно ненужными.

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