Во-первых, каждое хранилище NoSQL отличается.Так что это не то же самое, что выбирать между Oracle, Sql Server или MySQL.Различия между ними могут быть огромными.
Например, с CouchDB вы не можете выполнять специальные запросы (динамические запросы, если хотите).Он очень хорош в онлайн - оффлайн сценариях и достаточно мал, чтобы работать на большинстве устройств.Он имеет интерфейс 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 библиотека может помочь, как может Autopper.Я считаю, что работа с C # 3 требует определенных затрат по сравнению с работой с динамическим языком, например, Python.В C # 4 это может немного улучшиться с такими вещами, как ExpandoObject и Dynamic из DLR.
Чтобы взглянуть на ваши 3 конкретных вопроса, все это зависит от принятого вами решения NoSQL, поэтому ни один ответ невозможен, хотя и с таким предостережением, в очень общих чертах:
Если вы сохраняете объект (или, скорее, агрегируете) в целом, ваши объединения обычно будут в коде, хотя вы можете сделать это через MapReduce.
Опять же, это зависит, но с помощью Couch вы выполняете GET через HTTP для определенного ресурса или для представления MapReduce.
Скорее всего, ничего. Просто следите за сериализацией, сценариями десериализации. Трудность, с которой я столкнулся, заключается в том, как вы управляете версиями своего кода. Если свойство предназначено исключительно для передачи в интерфейс (GUI, веб-сервис), то это, как правило, менее проблематично. Если свойство является формой внутреннего состояния, поведение которого будет зависеть, то это может стать более сложным.
Надеюсь, это поможет, удачи!