Каковы некоторые "умственные шаги", которые разработчик должен предпринять, чтобы начать переходить с SQL на NO-SQL (CouchDB, FathomDB, MongoDB и т.д.)?

У меня есть ум, прочно связанный с реляционными базами данных и эффективный код для них. Большая часть моего опыта связана с MySQL и SQL. Мне нравятся многие вещи, которые я слышу о базах данных на основе документов, особенно когда кто-то из недавних подкастов упоминал о огромных преимуществах производительности. Итак, если я собираюсь пойти по этой дороге, каковы некоторые из умственных шагов, которые я должен предпринять, чтобы перейти от SQL к NO-SQL?

Если это имеет значение в вашем ответе, я разработчик С# в первую очередь (сегодня, во всяком случае). Я привык к ORM, как EF и Linq to SQL. До ORM я катал свои собственные объекты с помощью дженериков и datareaders. Возможно, это важно, может быть, нет.

Вот некоторые более конкретные:

Как мне нужно думать о присоединениях?
Как я могу запросить без инструкции SELECT?
Что происходит с моими существующими хранимыми объектами, когда я добавляю свойство в свой код?

(не стесняйтесь добавлять свои вопросы здесь)

Ответ 1

Во-первых, каждый магазин NoSQL отличается. Так что это не нравится выбор между Oracle или Sql Server или MySQL. Различия между ними могут быть огромными.

Например, с CouchDB вы не можете выполнять ad-hoc-запросы (если хотите, динамические запросы). Он очень хорош в онлайновых сценариях и достаточно мал, чтобы работать на большинстве устройств. Он имеет интерфейс RESTful, поэтому нет драйверов, нет библиотек ADO.NET. Чтобы запросить его, вы используете MapReduce (теперь это очень часто встречается в пространстве NoSQL, но не повсеместно) для создания представлений, и они написаны на нескольких языках, хотя большая часть документации для Javascript. CouchDB также предназначен для сбоя, то есть если что-то пойдет не так, он просто перезапускает процесс (процесс Erlang или группу связанных процессов, а не весь экземпляр CouchDB).

MongoDB спроектирован так, чтобы быть высокопроизводительным, иметь драйверы и, по-видимому, менее скачкообразно для многих людей в мире .NET. Я считаю, что в ситуациях сбоя можно потерять данные (он не обеспечивает одинаковый уровень транзакционных гарантий вокруг записей, которые делает CouchDB).

Теперь обе эти базы данных документов, и поэтому они совместно используют то, что их данные неструктурированы. Нет таблиц, не определена схема - они схематичны. Однако они не похожи на хранилище с ключевыми значениями, поскольку они настаивают на том, что данные, которые вы сохраняете, понятны им. С CouchDB это означает использование JSON, а с MongoDB это означает использование BSON.

Есть много других различий между MongoDB и CouchDB, и они рассматриваются в пространстве NoSQL, чтобы быть очень близкими в их дизайне!

Помимо баз данных документов, это сетевые решения, такие как Neo4J, столбчатые хранилища (ориентированные на столбцы, а не на строки, ориентированные на то, как они сохраняют данные) и многие другие.

Что-то общее в большинстве решений NoSQL, кроме MapReduce, заключается в том, что они не являются реляционными базами данных, и большинство не используют синтаксис стиля SQL. Типичный запрос следует за императивным режимом программирования, а не с декларативным стилем SQL.

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

Мой совет любому, кто хочет использовать решение NoSQL, должен сначала понять требования, которые у них есть, понять SLA (какой уровень латентности требуется, насколько последовательной должна быть эта латентность по мере масштабирования решений, какой масштаб нагрузки Ожидается, будет ли согласованная нагрузка или будет ли она всплесками, насколько последовательным является представление пользователей о данных, должны ли они всегда видеть свои собственные записи при их запросе, если их записи будут немедленно видны всем другим пользователям и т.д..). Поймите, что у вас не может быть всего этого, прочитайте теорему Brewers CAP, в которой говорится, что вы не можете иметь абсолютную консистенцию, 100% -ную доступность и быть толерантными к разделам (справляться, когда узлы не могут общаться). Затем рассмотрите различные решения NoSQL и начните устранять те, которые не предназначены для удовлетворения ваших требований, понимают, что переход из реляционной базы данных не является тривиальным и связан с ним связанными с ним расходами (я нашел стоимость перемещения организации в это направление, с точки зрения встреч, дискуссий и т.д.) очень велико, что не позволяет сосредоточиться на других областях потенциальной выгоды). В большинстве случаев вам не понадобится ORM (часть R этого уравнения просто пропала без вести), иногда просто двоичная сериализация может быть в порядке (например, с DB4O или хранилищем для ключей), такие вещи, как Newtonsoft JSON/Библиотека BSON может помочь, как и automapper. Я нахожу, что работа с С# 3 - это определенная стоимость по сравнению с работой с динамическим языком, например Python. С С# 4 это может немного улучшиться с такими вещами, как ExpandoObject и Dynamic из DLR.

Чтобы посмотреть на свои 3 конкретных вопроса, все зависит от решения NoSQL, которое вы принимаете, поэтому один ответ невозможен, однако с этим оговоркой в общих чертах:

Если вы сохраняете объект (или, скорее всего, совокупность) в целом, ваши соединения обычно будут в коде, хотя вы можете сделать некоторые из этого через MapReduce.
Опять же, это зависит, но с помощью Couch вы выполняете GET через HTTP против определенного ресурса или против представления MapReduce.
Скорее всего ничего. Просто следите за сценариями сериализации, десериализации. Трудность, которую я обнаружил, заключается в том, как вы управляете версиями своего кода. Если свойство предназначено исключительно для нажатия на интерфейс (GUI, веб-сервис), то это, как правило, менее проблематично. Если свойство является формой внутреннего состояния, на которое будет опираться поведение, тогда это может стать более сложным.

Надеюсь, это поможет, удачи!

Ответ 2

Просто перестань думать о базе данных.

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