АлексейС1) попробовал orientdb утром еще помучать запросами. Напомню: в базе на данный момент 44 млн строк. Оказалось, что строки clusterPosition от 0 до определённого nnn он нормально выдаёт, а вот после определённого, он уже уходит в вечный цикл. То есть повторяется история с sql,java запросами, которые также не работают. Похоже какая-то проблема с индексом. Единственный способ получить записи - идти итеративно по всей базе)) Итог: действительно глючно и бажно, у меня всё внутри испытывает тревогу по поводу этой базы в продакшене. Поковыряю исходники, потому что здравые идеи там есть, но использовать не буду.

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

АлексейСВот это да... я про эту базу от оракла не знал... Если она по скорости будет нормальной, то это ж то что надо! Правда я вот не понял, а что у неё с лицензией? Оракл - это всё-таки очень уж коммерческая организация и я не уверен, что они прямо так уж отдали, даже community edition.
Имхо, очень стрёмная вещь. Оракл кроме своей основной базы, на которой и выехал, толком больше ничего не разрабатывал, всё остальное скупалось вместе с потрохами. У меня сложилось неоднозначное впечатление об оракловских продуктах. Если корпоративной палкой не нагибают под оракл, то многие стараются держатся подальше от него. В этой базе внутри беркли. О ней немало хреновых отзывов. Вот например из последних. Оракл сейчас пытается своей жопой накрыть все стулья, даже свою версию хадупа предлагает.

АлексейСVoldemort тестировал не я, а коллеги и оный был признан как тормознутая надстройка над leveldb. Я им доверяю, так что пока тестировать не буду. Насчёт JDBM2 спасибо, посмотрю, хотя не сейчас, потому как сервера с ним всё-равно нет, а если его писать, то неважно для какой базы. Насчёт orient - да, использовать в production я бы его не стал... но об этом ниже. Tarantool - всё-таки совсем не то, что нужно. Это именно продакшн база, а не небольшое k-v решение, которое мне нужно. Впрочем для общего развития поковыряться интересно))
Я так понимаю, что требования или желания для проекта серьёзные. Такие конторы как mail.ru или яндекс прошли путь от многих sql-баз, включая и оракл с его рак-ом и всякими TimesTen, до вывода о том, что с оперативными данными вынуждены работать только в ОЗУ. Поэтому вынуждены велосипедить, как с Tarantool-ом.
Так что, весьма рекомендую оценить такой подход.

По поводу Voldemort. Вы уверены, что он тестировался именно с leveldb? По умолчанию вроде он работает поверх беркли, альтернатива у них какой-то Krati, что фактически та же беркли, но не на деревьях, а на хэшах. Вроде есть какой-то эксперимент поверх leveldb, но на оригинале от гугла, т.е. не жабский порт. К тому же, как я понял, основная цель там в использовании leveldb - это задействование его snapy-сжатия, что естественно снижает скорость.

Имхо, странно, что Voldemort признан тормозным, при этом нравится, как работает Cassandra. Кстати, имхо, судьба касандры сейчас под большим вопросом, когда фейсбук на неё фактически положил свой болт. Сейчас, похоже, всякие "фейсбуки" вдарились в хадуп - то ещё счастье, как по мне, и слава Богу, что меня пока пронесло с ним связываться.
Так вот, повторюсь, что, если я не ошибаюсь, то в "одноклассниках" используется Voldemort в паре с тарантулом - т.е., если бы он был проблемным местом, то профита от использования базы в ОЗУ не было бы.
Сейчас, скорее всего, распределенность не нужна, но вдруг потом понадобится? Имхо, если не получится прикрутить Voldemort, то готовое решение навряд ли найдется.

И неплохо, имхо, оценить JDBM2 - чем проще, тем надёжнее.

Алексей, по поводу своей возни с orientdb отпишитесь на ее местном форуме. Вроде там ее авторы оперативно реагируют, честно говорят о проблемах, может что-то толковое всплывет.

P.S. С миллиардами записей, имхо, без горизонтального распределения по нодам уже не обойтись.

АлексейСPSV100,
Насчёт ориента - напишу, надо им сообщить, вы правы.

Проблема в том, что чтобы горизонтально всё отмасштабировать, нужен такой большой парк серверов, что сказать страшно. У нас проектов много и для каждого своя большая база.

Petro123,
Допустим в базе 1 млрд строк. В качестве id выступает инкрементный long, гарантированно уникальный. Приходит пользователь и заносит в систему свои данные, они обрабатываются и на основе этих данных делается выборка по n ключей. Выбирается, допустим, тысяча, с ними производятся мат. вычисления с целью наиболее удачные данные расположить вначале, а неподходящие в конце. В некоторых случаях возможна простая сортировка по value. Если данных не выбирается достаточное количество, то производится еще n запросов, n<5. При этом данные могут в любой момент дополняться, примерная минимально-необходимая скорость около десяти тысяч строк в секунду. Для оптимальной загрузки по оп скорость должна быть около 40ка тысяч строк в секунду.
По поводу ориента, уже очевидно, что налягать на него не стоит. Ребята из TrackStudio намекали, что их доставала поломка баз. Я надеялся, что ситуация уже существенно продвинулась, но похоже, ещё не судьба. Если при наличии времени пообщаетесь с разработчиками, то, имхо, польза будет. Просто по-человечески очень жалко, если такой проект не взлетит, таких вещей очень мало в реальной жизни.

А, судя по описанной ситуации, можно только посочувствовать, ибо, скорее всего, придётся конкретно велосипедить. Voldemort, похоже, не спасёт. Также как и оракловская база. Всё-таки их основной функционал - распределялка по нодам.

С базами получается такая картина:

- беркли-дб, как самая распространенная штуковина, с поддержкой, с информацией, которую можно откопать по разным местам;

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

Пока здесь гуру лучше не предложили. Жабская leveldb - пока вроде официально ещё не релиз, и очень слабо распространена, имхо, гонять ее тоже нужно хорошенько. Вам сейчас виднее.
Еще вспоминается такой толковый товарищ как Константин Книжник. В своё время он накатал кучу всяких баз под разные платформы, что-то перешло в коммерцию под маркой mcobject. Может есть смысл глянуть туда.
Также полно всяких neo4j, db4o и пр. и т.д. Перепробовать всё - не хватит времени, к тому же это будет такая экзотика, что ни инфы толковой не будет, не людей не найти, кто собак с ними наелся.

По поводу netty. На глаза попадается немало инфы об успешном использовании. Вот здесь есть маленькое сравнение с mina, но имхо очень по делу. Также сейчас многие хвалят ZeroMQ, но под жабой вроде только обвертка для нативного кода, имхо, есть смысл связываться, если нужно взаимодействие с другими нежабскими системами.

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

В общем, когда познаете нирвану, обязательно поделитесь своим мнением.

Valery ShiskinЯ скачал Oracle NoSql. Там и документация и исходники. jar-файлы тянут совсем немного. Мне кажется, что АлексеюС следует на нее посмотреть. В прочем, достаточно почитать ее Getting Started (небольшой).
Посмотреть конечно стоит. Но лично я бы с ней связываться не рискнул бы. Пока я увидел только один интересный момент в ней, который сейчас непонятный и его нужно подробно разложить по полкам - это то, как там реализуется целостность данных. База новая, оракловцы могли насмотреться на уже используемые решения, и, как я понял, им не очень нравится принцип отложенной согласованности, когда правильность данных устанавливается во время их чтения - т.е. кворум содержания данных по нескольким нодам (данные должны быть обязательно продублированы не на одной ноде), разрешение конфликтов разных версий данных и т.д., что сейчас используют во многих NoSql. Оракловцы хотят сделать упор на согласовании данных при записи, пусть даже ценой небольших задержек, но что там именно - нужно разбираться, возможно здравые техники там есть. Сейчас, как пример, тот же гугл тоже у себя пытается применять транзакционную целостность (судя по разной доступной инфе в инете).
А так, базу пока толком мало кто использует, она гвоздями прибита к беркли, которая имеет неоднозначную славу. К тому же, Алексею вроде распределение по нодам не нужно. Хотя, задача подробно не описана, неясен момент, как обеспечивается сохранность данных. Возможно, оперативные данные держатся в MySQL и там организовывается резервное копирование. А может, как раз и не помешало бы дублирование данных по нодам, в этом случае вполне можно смотреть на оракл и вольдеморт.

В идеале, если Алексей реализовал бы свой сервер/фреймворк, без привязки к конкретной СУБД (но с первой версией - jdbm), где транспортный уровень поверх netty, внутренняя архитектура в стиле Disruptor-а (я смотрю, что сейчас реализация многопоточности поверх очередей становится модным трэндом вместо акторов в стиле эрланга), да поделился бы с общественностью, то эх... ;)

Valery ShiskinИ, разумеется, очень жаль, что OrientDb не имеет достаточно большого комьюнити (пока). Посмотрим, что будет в первом релизе (планируется середина апреля).
В OrientDb пока одни разочарования. Релиз планировался ещё в прошлом году, а для реальной эксплуатации, особенно распределенной, стоит ждать версии минимум 1.1 (там обещают реально необходимые вещи). Имхо, основная беда в том, что у разработчиков нет своих задач, где ее они сами уже использовали бы. Ту же jdbm, как я понял, разработали для внутренних нужд (как встраиваемое решение для больших и быстрых баз в астрономической отрасли) и потом поделились с обществом. Сейчас самое "массовое" использование OrientDb - это некий TinkerPop, система для анализа данных на основе графовых баз со своим язычком для граф-запросов. Ни на сверх-огромные массивы данных, ни на массовую нагрузку эта система вроде не расчитана. Авторы OrientDb пытаются построить бизнес именно на самой СУБД. До этой базы они занимались немало времени другими какими-то объектными базами, нащупали какой-то эффективный алгоритм деревьев и решили податься с ним на жабу-платформу. И их шоу-замашки действительно портят картину. Здесь на форуме "Йуный джавистЪ" постебался над ней, это конечно не оценка продукта, но доля правды в этом есть. Вот недавно они публиковали презентацию, где рассказывали, что собираются заменить master-slave репликацию на master-master (что очень хорошо) - но это сплошное шоу, а не техническое описание, что нужно реально для пользователей продукта.
Одним словом, жаль, что за спиной продукта нет какого-нибудь "фейсбука", кто пилил бы базу, прежде всего, для своих потребностей, толку было бы больше.