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

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

Честно говоря, не вижу и принципиальных отличий от любой нормальной rdbms с хранением в блобах json-сериализованных объектов (и полей для индексов).

george33отличие в объектности. документ в док-ориентированной субд правится единым целым, здесь же документ - один из вариантов работы.

Хм, судя по документации, тут запись вида документ мы также меняем целиком. И это - единственный "объектно-ориентированный" вариант. Поля типа "flat" от обычной РСУБД вообще ничем не отличаются.
Используемые механизмы ссылок от индексов в РСУБД также фактически не отличаются.

паутину объектов размером в терабайты - вот из-за этого я интересуюсь.
Если не секрет, что за предметная область, где терабайты объектных данных, но при этом можно использовать плохоподдерживаемую СУБД?

george33,
почитал описание внимательно.

В качестве маленькой примитивной embedded базы данных вполне может составить конкуренцию какой-нибудь sqllite, может даже побыстрее будет, если хорошо понимать, как устроена работа с диском в OrientDB и аккуратно настраивать стратегии кэширования и индексы.
По сравнению с любой большой БД и на больших объемах - будет заметно проигрывать, в первую очередь из-за примитивной схемы кэширования и примитивной схемы работы с диском.

Для Java для больших проектов связка ehcache+большая БД будет заметно производительнее.

george33,
вы лучше конкретную задачу опишите. Я с трудом представляю в реальном продакшене нишу для ООБД.

Когда мне нужно работать с сложными документами, я сериализую их в блобы (Jackson, Spring jdbcTemplate и, собственно, все). Если производительность не критична, то можно обойтись каким-нибудь Hibernate и вообще не думать, что там на урове СУБД.

george33,
Ну и в чем проблема?
Конкретный элемент недвижимости - объект какого-то конкретного класса, вполне себе сериализуется в блоб (Jackson), нужен обычно целиком. Jackson вполне себе умеет работать с наследуемыми параметрами сериализации, все там просто.

Те поля, по которым происходит поиск - вытаскиваются в отдельные поля, на них все равно придется вешать индекс. Но этих полей сравнительно мало, на самом-то деле.

Если нужен полнотекстовый поиск - то все равно SOLR прикручивать.

Если нужен очень сложный поиск - то, в любом случае, придется ручками делать.

При этом ровно то же самое придется делать в любой ООП базе - отдельно создавать индексы по тем полям, по которым ищешь и все остальное хранить "as is". В лучшем случае в ООБД сможешь упростить добавление "индексного поля" в обмен на поиск глюков и поддержку малоизвестной СУБД.

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

george33DPH3,
джейсон знаю, Jackson - это про что?

Это библиотека сериализации/десериализации Java-объектов в JSON. Быстрая и гибкая.

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

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

А уж сложностей с добавлением одной колонки к БД я ни в одной приличной БД не видел (ну, в Оракле - 9ке был баг, но это давно уже было).

Это не пугает, главное чтобы база нигде не чинила для этого препятствия. в объектной я могу выбрать объекты, имеющие поле новое xx, даже если я добавил их после определения схемы, xx не учитывающей. без лишнего кашля.

Не совсем верно. Это возможно только если добавлено простое поле, если устраивает table scan по всем объектам класса и т.п. Ну или нужно создавать индексное поле - тогда поиск будет за разумное время.
По сложности организации - точно также, как и в реляционной БД.
И в любом случае придется разбираться, а как оно все устроено на нижнем уровне, без этого и данные будут теряться и тормозить все будет. Но только по РСУБД обычно документация лучше :)

можно ли от Н2 поиметь хоть треть этой гибкости?
А зачем H2? Глючно и малофункционально. БД нужно искать исходя из наличия DBA. Postgress/DB2/Oracle/MySQL и т.п. Но всякую экзотику на коммерческом продакшене - нафиг, нафиг.

george33можно ли на работающей РСУБД безопасно добавить поле, и поменять что-либо меня волнует по-взрослому. и на какой именно. определиться нужно уже как-то.

Ну, гарантированно безопасно (т.е. без остановки БД и без блокировок вообще) добавить nullable поле. В некоторых БД, насколько я помню, некоторые расширения типа - также делаются только на уровне метаинформации.

Остальные операции (удаление полей, изменения типа и т.п.) - безопасны для данных, но могут требовать блокировки таблицы на время операции. Если таблица реально большая (миллионы записей, например), то операция может занять довольно много времени.
В больших БД типа Oracle и DB2 есть возможность и операции по изменению структуры делать практически без блокировки (некоторой хитрой магией, нужен осмысленный DBA, время блокировки единицы секунд или менее). Про Postgress и MySQL - не в курсе, думаю, что в Postgress есть, а в MySQL нет.

И, да, надежность популярных РСУБД на данный момент заметно выше, нежели любых NoSQL решений. Те NoSQL, которые говорят о высокой надежности - требуют для нее каких-то неочевидных настроек. По крайней мере, все мне известные инсталляции той же монго страдали от потери данных (зачастую по вине dba, но это тоже печальный симптом).

Так что лучше использовать проверенные решения :)