АлексейСвстроенный язык построения запросов у меня отказался работать. Запрос просто запускается и такое ощущение, что начинается вечный цикл. Не дебажил. Пробовал запрос на java и sql, итог один. В общем смог получить только get запрос, который, к слову, там тоже через одно место.

Я так понимаю, объектная обёртка и особенно sql - пока самые непроработанные места. К тому же, если работать через сервер, то и там могут быть глюки вокруг ядра СУБД. Имхо, для себя лучше работать с самым низким level-api, так по скорости лучше и ближе по духу к key-value.

АлексейСО, а вот и логическое объяснение. База разделена на куски по 500 метров. Соответственно файл мапится в память и данные загружаются в него, а потом через некоторое время дампятся, вот он и жрёт 500 метров +- немного. Не знаю правда как это всё дело будет вести себя при конкурентной нагрузке, проверю.

Хм..., когда я orientdb немного щупал, то больших расходов оперативки не замечал. Вот вываливание всяких непонятных эксцепшинов на ровном месте - вполне хватало. Также заметил затыки на массовом удалении данных - может оказаться проблемой (хотя, если для задачи рассматривается leveldb, то наверное массовых удалений и модификаций записей не ожидается). Я не помню, был ли тогда mmap в потрохах (и в целом, я в потроха мало влазил), но по поводу памяти у них на форуме периодически появлялись всякие обсуждения, похоже до сих пор ещё экспериментируют.

Одним словом, похоже с сыростью ещё не покончено. Имхо, штука ещё стрёмная. С другой стороны, вроде есть сторонние энтузиасты, которые пилят API для скалы и кложуры. Значит, уже как-то используют. Там на местном форуме вроде есть наши ребята, которые пилят какую-то индексацию для коллекций внутри документов (если я не ошибаюсь), может есть смысл с ними связаться, скажут чего-нибудь по делу.

Как альтернатива для orientdb можно глянуть на Neo4j - вроде эту штуку уже используют, но там нужно смотреть на лицензии, а также, вроде, orientdb уделывает по перфомансу и пр. эту графовую базку (так утверждают те, кто гонял orientdb).

И сугубо моё личное имхо по поводу NoSql. Я не спец в этих вопросах и пока не решился на nosql-использование (и не было пока задач, чтобы нагнуло для этого), но я наблюдаю такую картину:

- эффективная реализация nosql на java - пока под большим вопросом. Если я не ошибаюсь, то в той же cassandre внедряется управление памятью через нативный код. Можно почитать с какими проблемами столкнулись при разработке JGit (гита на жабе) и почему по перфомансу не догнать оригинал, на какие хаки пошли в disruptor и почему теперь не всё работает на семёрке, и пр.

- сейчас видна тенденция применения leveldb в качестве бакэнда для ряда nosql, причём вместо более традиционных dbm-подобных систем. Значит, профит есть, нужно хорошенько оценить.

- если для решения задачи необходимы дисковые операции, то есть смысл оценить "ускорители" уже проверенных традиционных баз, типа HandlerSocket для MySQL (для постгресса что-то делал скайп, но вроде в основном для "распределялки" данных).

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

Алексей, обратитесь на форум Tarantool-а. Как я понял, они там у себя в mail.ru или одноклассниках используют стек Voldemort + Tarantool, логи баз и их снэпшоты потихоньку в фоновом режиме перекачивают в обычные СУБД и воюют с ними дальше отдельно. Может их модель что-то полезное покажет.

По поводу Voldemort. Как я понял "хеш-распределялка" особо не нужна, но всё-таки это готовое, причём используемое, сетевое решение. Может есть смысл его повертеть с разных сторон на предмет правильной его готовки, и бакэнды к нему разные прикручиваются (сам я на него не смотрел).

А так, чтобы и лёгкая СУБД была и готовый лёгкий сетевой сервис, кроме orientdb толком ничего не вспоминается.
Когда-то на глаза попадалась ограниченная реализация SQLite на чистой жабе, но ссылку быстро найти не удалось, и не помню я, был ли там сервер или это просто эмуляция JDBC-драйвера.

Алексей, если для своей задачи что-то погоняете (эту orientdb, leveldb, здесь ещё указанную JDBM2, Voldemort и пр.) и поделитесь с общественностью, то мы все здесь на форуме будем признательны, ибо реальная практика по всяким NoSql весьма редкое явление.

Вот только что случайно наткнулся на ресурсы по поводу jdbm:

- автор http://www.mailinglistarchive.com/html/general@db.apache.org/2012-02/msg00000.html]предлагает включить проект в апачевские лавры;

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

- сам проект jdbm3. Пока ещё альфа.

Как я понимаю, библиотекой пользуются, возможно для жабы очень производительное решение. Но нужен свой "сервер".

Valery ShiskinАлексейС,

Мы все почему-то забыли об Oracle key/value NoSQL.

Я тоже о ней ничего не слышал. Сейчас бегло посмотрел, что за хренотень такая. На сайте оракула какая-то мутная инфа, даже про лицензии ничего не увидел. Почитал этот блог вместе с комментариями. Как я понял, это жабская беркли-дб на стероидах, т.е. с хеш-распределялкой по нодам + репликация и прочие плюшки. Имхо, ТС-ру не подойдёт. Судя по описаниям та же jdbm2 ощутимо быстрее берклей и по лицензии приятней. Да и не нужна распределенность. Имхо, если orientdb пройдёт конкурс по неглючности (в чём я сомневаюсь), то это будет лучше выбор. А так чувствую, что дело закончится Voldemort + leveldb или jdbm2 (что возможно лучше, чем пока мало используемый порт на жабу leveldb), или всё-таки придётся реализовать свой сервак под те же либы.