АлексейС,

LevelDb тестировалась под свои требования? Очень интересны ощущения от ее использования. Лично я эту либу в руках не вертел, но как-то натыкался в инете на какой-то блог (ссылки не сохранил), где LevelDb гонялась в сравнении с SQLite-ом (также, если не ошибаюсь, это обсуждалось и на оф. форуме скулайта). Всего не помню, но выводы такие: гугловский тест SQLite-а на сайте LevelDb - некорректный, в реальности по перфомансу LevelDb от sqlite ушла не далеко, а на ряде операций она хуже sqlite-а (это даже при наличии sql-слоя, также те тесты показали, что и у скулайта не всё гладко, причём не по причине sql). К тому же, как я понял, LevelDb эффективна только при маленьком размере value-части.

Valery ShiskinАлексейС,
Посмотрите на OrientDb. Мне было бы любопытно узнать Ваше мнение
Присоединяюсь к OrientDb. Я баловался с ней год назад, концептуально интересна, но показалась очень сырой, были всякие непонятные глюки. В то время поинтересовался у ребят из TrackStudio, они пытались её заюзать для своей системы - из-за глюков и поломок баз её забросили. Но вроде, судя по местному форуму, пилят ее активно, потихоньку начинают использовать, но проектов что-то не видно пока.
Кто-то OrientDb уже гонял по-серьёзному ?

АлексейСLevelDb понравилась тем, что вместила 1 млрд строк, при этом вела себя весьма скромно в плане памяти оперативной и локальной, правда в тот момент сравнивалась она с cassandra, которая вообще очень прожорлива. Надо будет затестить снова, но вообще очень приятная базка. У коллеги она работает в продакшене в виде кэша, но кэш тот дёргается редко, так что не сказал бы что это тест в хвост и в гриву.

Тут важно еще посчитать сколько конкурентных запросов база может переварить на большом количестве конкурентных записей и чтений и для меня это тоже очень важный параметр. Если база записывает чуть медленнее, но выдержит более высокую постоянную нагрузку, то это круче для меня
Как я понимаю, конкурентность запросов к базе перекладывается на плечи своего "сервера". Если я не ошибаюсь, leveldb фактически однопоточная штука для контроля действий в своём приложении (т.е. один поток как минимум при записе, иногда создаются служебные вспомогательные потоки, например, при перекомпоновке файлов). Имхо, с leveldb нужно очень осторожно смотреть на конкуренцию. Я cassandr-у тоже не юзал, но на глаза попадались отзывы о том, что при интенсивной нагрузке возня с перекомпоновкой данных по уровням (файлам), как и у leveldb, ощутимо сказывается на производительности.
Как дела у OrientDB с сетевым стеком - я уже не помню, но мне показалось, что её родной сервер - фактически учебный пример. Для своего приложения над конкурентностью нужно хорошенько кумекать под свои задачи.

АлексейС, если погоняете leveldb и OrientDB - плиз, поделитесь своими выводами.

P.S. На всякий случай: здесь есть JNI-интерфейс для leveldb, здесь какой-то любительский порт leveldb на чистую жабу (сам ничего не использовал).

АлексейСLevelDb у нас на индексации данных работала на 16ти потоках, это при очень интенсивной записи, причём это была её java версия. Но она как-то была принята в использование де-факто, без особого тестирования... и вот как-то угадалось)))

Cassandra у меня на тестах валилась под нагрузкой 600-700 одновременных коннектов к базе. Это количество записей и чтений в один момент времени через thrift. И вообще эта база - моя любимая. Но не без изъянов, конечно. Как и все базы.....
А java-версия leveldb - это тот порт, который я указал, или есть какая-то разработка от самого гугла ?

P.S. Имхо, OrientDB - неплохая альтернатива, выглядит очень привлекательно. Раньше с надёжностью было тяжко, сейчас может уже получше. Пилят ее мало народу (в основном, ее автор), но с прицелом на коммерческую поддержку, уже какую-то контору создают для всяких "облачных полётов" на её основе. Так что, имхо, до юзабельного состояния должны уже довести, вроде близок релиз первой версии.

АлексейСвстроенный язык построения запросов у меня отказался работать. Запрос просто запускается и такое ощущение, что начинается вечный цикл. Не дебажил. Пробовал запрос на 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), или всё-таки придётся реализовать свой сервак под те же либы.