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 и т.п. Но всякую экзотику на коммерческом продакшене - нафиг, нафиг.