Есть ли для .NET фреймворк nosql, не зависящий от базы данных?

Я ищу общую структуру доступа к данным, которая обеспечит переносимость между различными базами данных nosql, такими как SimpleDB, Azure Tables, Cassandra, CouchDB, MongoDb и т. Д. Я создаю приложение и хочу, чтобы мои клиенты могли использовать то, что когда-либо nosql они хотят.

В более реляционном сценарии я бы использовал Linq поверх nHibernate или Entity Framework, но я не нашел эквивалентной структуры для баз данных nosql. Все, что я нашел, - это API, специфичные для базы данных, хотя кажется, что они имеют существенное сходство. Есть ли такой? Желательно с LINQ.


person Matt Dotson    schedule 28.06.2010    source источник


Ответы (4)


Нет, это слишком разные и слишком специфические вещи (по крайней мере, сейчас). Если вам нужно что-то действительно простое, например, просто оболочка для объекта, доступ к которому осуществляется только по идентификатору, тогда у вас может быть надежда. Фактически, если вы посмотрите на NoRM, возможно, это удастся адаптировать к различным поставщикам.

Однако, помимо небольшого основного набора функций, эти "NoSQL" базы данных сильно отличаются во многих отношениях. Я имею в виду, как вы агностически реализуете различные функции map / reduce? Как вы реализуете атомарные операции, если они поддерживают разные атомарные операции?

В любом случае, мы слишком рано в жизненном цикле NoSQL, чтобы иметь независимую структуру для всего этого. Azure по сути отказалась от предложения NoSQL в пользу «размещенного SQL-сервера». MongoDB может быть 20 месяцев, CouchDB все еще находится на версии 0.11.x, SimpleDB менее 24 месяцев, Cassandra находится на версии 0.6.2 и, возможно, регулярно используется в течение нескольких лет.

Просто мы еще не достигли цели.

person Gates VP    schedule 28.06.2010
comment
Итак, каков сейчас основной набор общих функций? Это действительно просто объект, доступ к которому осуществляется через его идентификатор объекта? КСТАТИ. В Azure не отказались от таблиц, они просто предложили как реляционные, так и NoSQL. То же самое, что и Amazon с RDS. - person Matt Dotson; 29.06.2010
comment
На этом этапе я думаю, что вы получите базовые операции CRUD. Map / Reduce значительно отличается даже между Couch и Mongo (которые относительно похожи). Некоторые из перечисленных предложений поддерживают управление версиями, но Mongo - нет. У Couch есть концепция представлений, которая играет центральную роль в уменьшении карты, но Mongo просто выбрасывает результаты уменьшения карты в новую коллекцию. Так что возможно, что вы могли бы абстрагироваться от этого, но это много абстрагирования, потому что они делают разные вещи. - person Gates VP; 30.06.2010

Разрабатывается общий язык запросов (называемый UnQL): http://www.unqlspec.org/display/UnQL/Home

person TTT    schedule 11.08.2011

Существуют поставщики LINQ для MongoDB, но я не думаю, что существует общий поставщик linq .net для «всех» nosql db.

Некоторые люди задумывались об общем языке запросов nosql: http://nosql.mypopescu.com/post/731261002/a-common-nosql-query-language

person TTT    schedule 28.06.2010
comment
Итак, структурированный язык запросов без структурированного языка запросов? Хмммм ... вроде упускает суть, не так ли? :-) - person Warren Rumak; 28.06.2010
comment
@ Уоррен, это довольно иронично - person Mocky; 28.06.2010

Если у вас есть только базовые требования к сохраняемости, я поддерживаю общий API кэширования с провайдеры для кэширования Memcached, Redis, InMemory и FileSystem.

Он поддерживает только Redis, но у меня есть C # Redis Client с очень знакомый C # API. Он изначально поддерживает сохраняющиеся типы POCO и предоставляет все расширенные серверные структуры данных Redis как собственные структуры данных .NET IList, ICollection, чтобы их можно было легко использовать в существующих API C #, таких как LINQ и т. Д.

person mythz    schedule 11.09.2010