Встраиваемый нереляционный (nosql) хранилище данных

Я подумываю об использовании/внедрении какого-либо встроенного хранилища ключей (или документов) для моего рабочего стола Windows. Я хочу иметь возможность хранить различные типы данных (например, треки GPS), и, конечно, можно запросить эти данные. Объем данных будет таким, чтобы он не мог одновременно загружаться в память.Встраиваемый нереляционный (nosql) хранилище данных

Я думаю об использовании sqlite в качестве механизма хранения для хранилища ключей, что-то вроде y-serial, но написанного на .NET. Я также читал около FriendFeed's usage of MySQL to store schema-less data, что является хорошим указателем на использование RDBMS для нереляционных данных. sqlite кажется хорошим вариантом из-за его простоты, мобильности и размера библиотеки.

Вопрос в том, есть ли другие варианты встроенного нереляционного хранилища? Его не нужно распространять, и он не должен поддерживать транзакции, но он должен быть доступен из .NET и должен иметь небольшой размер загрузки.

ОБНОВЛЕНИЕ: Я нашел статью под названием SQLite as a Key-Value Database, которая сравнивает sqlite с DB Berkeley, которая является встроенной библиотекой хранилища ключей.

источник

2010-01-17 Igor Brejc

Лично я бы пошел на SQLite с NHibernate (и Fluent NHibernate). NHibernate может автоматически генерировать схему базы данных для ваших классов, поэтому вам просто нужно указать, какие классы вы хотите сохранить, и это довольно просто с Fluent NHibernate. Кроме того, вы можете искать определенные объекты, и вам не нужно загружать все данные в память.

источник

2010-01-17 15:20:07

Но он хотел магазин без схемы .... –

Атор прав: Я хочу избежать реляционной модели. Я хочу иметь возможность хранить практически любые данные без предварительной подготовки схемы базы данных. Кроме того, наличие строгой реляционной модели может быть проблематичным, если структура данных изменится позже - мне нужно будет написать сценарии смены SQL для существующих данных в хранилище. –

Я знаю, что он ищет, но такие инструменты, как NHibernate с генерацией схемы, почти полностью скрывают реляционный аспект. Вам не нужно определять какую-либо схему, но только сопоставление для вас классов (что действительно прямо с Fluent NHibernate), и когда ваши классы меняются, вам нужно будет сделать какое-то обновление в любой стратегии сохранения. –

Windows имеет встроенный нереляционный магазин. Он называется ESENT и используется несколькими приложениями Windows, включая Active Directory и Windows Desktop Search.

http://blogs.msdn.com/windowssdk/archive/2008/10/23/esent-extensible-storage-engine-api-in-the-windows-sdk.aspx

Если вы хотите .NET доступа вы можете использовать ManagedEsent слой на CodePlex.

http://managedesent.codeplex.com/

Этот проект имеет PersistentDictionary класс, который реализует хранилище ключ-значение, которое реализует интерфейс IDictionary, но поддерживается базой данных.

источник

2010-02-23 00:59:02

@ Laurion, я видел ESENT и изначально был очень взволнован. Единственная проблема в том, что это только Windows (думаю, Mono + Linux/Mac). –

Применяя принцип KISS к вашей проблеме, я бы рекомендовал вам использовать файлы.

Как и в имени файла, это ключ. Содержимое файла - это значение. Папка Windows - это индекс.

Простой, быстрый, эффективный, гибкий и надежный (при условии, что дураки имеют низкий интеллект).

источник

2010-02-23 02:45:59

Хороший подход, хотя я считаю, что использование файлов для хранения значений будет немного превышать верхние значения для простых значений (например, одного целого). –

Вопрос о том, что то, что хранится, может быть тихим большим (документы/слишком много данных для загрузки в память). Одним из преимуществ файлового подхода является то, что вы получаете бесплатный набор классов обработки потоков бесплатно, что очень полезно при работе с большими кусками данных и намного чище, чем, например, разделение данных на произвольные nMB-капли и сохранение их в база данных. –

Правда. Как насчет физических пределов файловой системы? Как будет вести себя такой магазин, когда количество записей достигает 100 000? Также: когда я говорил о «слишком большом количестве данных», я имел в виду базу данных _whole_ - я упомянул об этом, чтобы избежать ответов, таких как сериализация дерева объектов и тому подобное. –

Спасибо за Ваше упоминание о y_serial ... точнее, это модуль Python:

объектов складской Python с SQLite

«Сериализация + :: в настойчивость несколько строк кода, сжимают и аннотировать объекты Python в SQLite, а затем восстановить их хронологически по ключевым словам без какого-либо SQL. Самый полезный «стандартный» модуль для базы данных для хранения данных без схемы."

http://yserial.sourceforge.net

По моему опыту, SQLite является более быстрым и надежным выбором, чем в большинстве баз данных (в том числе PostGreSQL и Berkeley DB) для большинства проектов - и, конечно же, он не нужен демон сервера .

yserial очень легко реализовать (и гораздо быстрее, чем «имя файла содержимое ключ/файла является значение» подход ;-)

источник

2010-03-03 17:11:53 code43

Да, мне очень нравится подход y-serial, тем более, что он использует sqlite. Продолжайте хорошую работу! Может быть, когда я получу некоторое время из других моих проектов, я попытаюсь сделать что-то подобное в C# :) –

Не могли бы вы создать простую базу данных SQLite с двумя столбцами:

==documents== 
id|data

и данные будут json-данными.

Вы также можете создать таблицу ключей, которая была бы:

==keys== 
keyname|keyvalue|id

, которые будут проиндексированы на обозначение и KeyValue для быстрого поиска.

Один файл db может быть коллекцией, и вы можете создать несколько файлов db для нескольких коллекций.

Вы можете использовать папки как «DBS», чтобы соответствовать иерархии MongoDB по db-> галерею-> документ

источник

2010-04-01 23:59:41 RobKohr

Просто заметьте: вы создадите файл sqlite-файла шаблона и скопируете его в любое время, необходимое для создания новой коллекции , Если кто-то хочет создать php-установку для обработки этого и с открытым исходным кодом, дайте мне знать. Я думаю, это было бы здорово, но никогда не потрудилось сделать это сам. – RobKohr

Ваши предложения направлены на то, как y-serial делает вещи. Вы видели это? http://yserial.sourceforge.net/ –

Нет, но я ищу php-решение самостоятельно. – RobKohr

Взгляните на RavenDB. Это выглядит так, как будто он может быть встроен и schemaless и работает с .NET

С сайта:

масштабируемая инфраструктура: Raven устанавливается поверх существующей, проверенной и масштабируемой инфраструктуры
Простая конфигурация для Windows : Raven прост в настройке и запуске на окнах в качестве сервиса или веб-сайта IIS7.
Транзакция: поддержка ворона System.Transaction с транзакциями ACID. Если вы поместите в него данные, эти данные останутся там
Map/Reduce: легко определить индексы карты/уменьшения с помощью запросов Linq
.NET Client API: Raven поставляется с полностью функциональным .NET-клиентским API, который реализует Единица работы и многое другое
RESTful: Raven построен вокруг RESTful API

источник

2010-05-30 06:29:27 Jafin

Это старый вопрос, но я думал, что я хотел бы добавить ответ в случае, если кто-нибудь натыкается на него. Моя компания только что выпустила встроенную базу данных XML с открытым исходным кодом для платформы .NET под названием Nxdb. Он находится под лицензией Apache 2.0 и уже несколько лет разрабатывается и используется внутри компании. Это в основном привязка к кросс-скомпилированной (с использованием IKVM) версии BaseX (фантастической базы данных Java XML), а также дополнительной функциональности для встроенного варианта использования и среды .NET. Страница проекта находится здесь: https://dracorp.assembla.com/spaces/nxdb

XML хорошо подходит для хранилища данных такого типа, учитывая, что до тех пор, пока контент, который вы пытаетесь сохранить, сериализуется в текст, вы можете хранить сложные иерархические деревья. Фактически, если вы напрямую обращаетесь к базе данных, вам даже не нужно прикасаться к «XML». Он также может быть запрошен с помощью XQuery, мощного и полного языка запросов.

источник

2012-03-13 16:35:29 daveaglick

Вы можете попробовать этот https://github.com/mdsoftware/mData. Маленький, свободный и довольно необычный.Lisp-подобный язык запросов данных, компилятор выражений, высокопроизводительная двоичная сериализация, все включено.

источник

2013-05-20 12:10:54

Встраиваемый нереляционный (nosql) хранилище данных

ответ

Смежные вопросы