LevelDB не подходит под твою задачу. Бери MongoDB - у нее JSON <=> BSON сериализация налету. Рекомендую всетаки прочитать это http://en.wikipedia.org/wiki/LevelDB#Performance

Если что у монго ограничение на размер одного документа - 16Мб, у тебя какие цифры? И твои данные чисто JSON ?

Или JSON или BLOB. Больше вариантов по сути нет.

Данные простой текст, цифры маленькие.

MongoDB хм сразу вспоминается boost для сборки, mongodb не слижком тяжело и круто для базы приложения?

И эти люди (любители nosql) потом ругают SQL когда сами ущербны :(

MongoDB хм сразу вспоминается boost для сборки, mongodb не слижком тяжело и круто для базы приложения?

Ну если для gui и нужен embed, то есть форк http://ejdb.org/

Если такой вариант не очень, то сериализацию делать надо будет руками. В качестве ключей - наиболее удобный и простой способ, есть unixtime тебя устраивает, то норм. Далее [де]сериализация B(J)SON <=> текст, это и будет value.

Хм, круто, в ejdb есть даже свой find, в отличии от leveldb который дает только итератор. Спсибо, будем смотреть.

И все таки не mongo, a mongodb-like, но

EJDB is the C library based on modified version of Tokyo Cabinet.

JSON если пофиг на эффективность хранения, protobuf если нет

Если нужна схема, то я бы взял protobuf. Тогда будет обратная совместимость при условии добавления optional полей.

Если нужно именно schemaless, то bson/json.

ЗЫ. А не сравнивали с другим отпрыском dbm-а, с Kyoto Cabinet?

msgpack

если в BLOB хранить файлы XML/JSON в несколько КБ?

и что там написано про производительность? То что в бенчмарках искусственно деградирована производительность SQLLite? И дальше что?

Некрофилия, ай-яй-яй

если в BLOB хранить файлы XML/JSON в несколько КБ?

Храни, пожалуйста. Когда понадобится делать поиск по этим данным, естественно надо будет их сохранить в твоей любимой БД и там уже делать поиск. А старая БД (какая бы она не была, хоть файлы) останется до конца света. Это нормальный мммм... кодинг.

Дальше то, что кроме LevelDB появилось куча аналогов, которые ничем не хуже, а местами лучше. Вот исходя из этих «мест» и случаев, надо выбирать подходящее себе решение.

Или ты один из тех, у кого лучшее тождественно равно «в то, что я верю»? Я верю, что LevelDB не идеальна, т.к. делали её не идеальные люди.

какие у LevelDB есть альтернативы, кроме Basho LevelDB/HyperLevelDB/RocksDB

Допустим key сделаем unixtime

это не всегда удачный вариант, если у тебя key-value типа dynamodb и будут запрашиваться чаще последние данные (что часто бывает), то сам себе сделаешь хотспот

Данные простой текст, цифры маленькие.

а что с ними делать надо? в смысле поиск какой надо (раз уж текст) или просто по ключу отдавать?

мне по ключу отдавать.

а какая задача (по треду не нашел)?

хранить файлы (XML/JSON/TXT/..) и их метаданные, сохранять/отдавать/удалять их через Rest API. Сервер на Node.JS. Желательна репликация Mutli-Master.

Я выбрал LevelDB. Что я сделал не так?

Я выбрал LevelDB. Что я сделал не так?

а что не устраивает?

У меня организованно 2 Store: одно с метаданными (value = JSON), другое с файлами (value = binary).

Зы. MongoDB поддерживает Multi-Master-репликацию?

мульти-мастер репликация в Node.js.

Есть multi-master-merge, level-replicator, forkdb. Но непонятно, что нужно использовать. Что работает? Перебирать их все? На основании ско-ва звездочек и скачиваний?

что-то у Вас мысль скачет, никак не пойму какую цель Вы преследуете

MongoDB поддерживает Multi-Master-репликацию?

вроде бы да, но сам не пользовался

У меня организованно 2 Store: одно с метаданными (value = JSON), другое с файлами (value = binary).

это все очень зависит от того что нужно сделать, какие нагрузки и какие потребности, в каких-то случаях такое решение будет правильным

Исходная постановка задачи:

Необходимо реализовать Rest сервис на Node.js, который управляет документами и их версий: загрузить новую версию документа, отдать последнюю версию, отдать заданную версию, удалить последнюю версию. Название документа уникально и служит ключом.

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

Желательна репликация Mutli-Master.

Я выбрал LevelDB. Что я сделал не так?

This. LevelDB - библиотка для встраеваемых баз

средний размер документа

не больше 2-3 Мб

максимальный размер документа

Килобайт и меньше

оценка сверху количества документов

несколько (десятков) тысяч

вот что посоветовал мне консультант по Node.js, то и выбрал.

А каковы вообще критерии выбора?

Мне тупо нужно отображение: ключ - значение. Значение - JSON/Binary, по нему искать не нужно.

Это означает, что нужны key-value store, а не документ-ориентированная MongoDB.

Что у нас есть из key-value? Redis. Там сервер. Там in-memory. А хранимость вообще опциональна. А мне нужно тупо: открыть базу, поместь/извлечь/удалить значение по ключу.И все.

библиотка для встраеваемых баз

ты так говоришь, как будто это что-то плохое. У меня один на сервере крутится один Node процесс. Которые открывает LevelDB в монопольном режиме. И что в этом плохого? То что я не смогу запусть на этой машине второй Node-процесс с моим сервером? А зачем?

Я не знаю твоей ситуации. Серваки тоже падают, но если это не проблема для данной задачи и достаточно одной машины - ок