vybegalloНу что, посмотрел я одним глазком на этот самый Versant, точнее, на его документацию.
С точки зрения обработки больших объемов данных - фуфло.
1. Нет параллельного архивирования - восстановления.
2. Оптимизатор явно на коленке написан, "For performance
reasons, Versant recommends the use of b-tree indexes–even for
queries— when there are more than 100,000 instances of a particular class." Конечно, никаких партишн элиминэйшн, read ahead, битных индексов, роллапов и datawarehouse фишек.
3. Разграничение прав доступа - курям на смех. Юзеру можно дать доступ (тотальный) и отобрать доступ. Все.

Из документации FastObjects:

В FastObjects могут использоваться различные способы доступа к объектам. Принципиально различают два основных типа: по ссылкам и по значениям. Поскольку FastObjects является объектной базой данных, то во всех случаях лучшие показатели производительности достигаются при отслеживании взимосвязей между объектами (т.е. ссылок). Доступ по значению в общем случае необходим только для отыскания корневых объектов и других точек входа в объектную сеть (граф), объекты которой уже должны выбираться с использованием найденных ссылок на них. В следующих разделах мы несколько подробнее рассмотрим особенности этих двух типов доступа.
Будучи объектной базой данных, FastObjects обладает полными описаниями всех хранимых классов, объектов, их данных и взаимосвязей. Именно поэтому самым быстрым и естественным способом выборки объектов является непосредственная навигация по объектным сетям с использованием межобъектных ссылок.
Метод доступа по значению, в отличие от описанного выше, не предполагает использования каких-либо знаний о структуре модели. В этом случае, один или несколько искомых объектов выбираются исходя из соответствия значений их атрибутов заданным условиям. В реляционных базах данных возможность прямой навигации по объектным связям отсутствует. При работе с ними обращения ко всем данным происходят только с использованием выборки по значению. Поэтому такой метод может показаться вполне естественным для тех разработчиков, которые не имеют опыта использования объектных баз данных. И как результат — для выборки необоснованно используются запросы, в то время как доступ на основе прямой навигации остается невостребованным.
Даже при использовании объектных баз данных, возникают ситуации когда выборка объектов должна производиться исходя из значений их атрибутов. При этом запросы (queries) — это только один из доступных механизмов, позволяющий найти все объекты, удовлетворяющие заданным условиям. В FastObjects поддерживается несколько способов выборки объектов по значению. К таким способам относятся: поиск объектов по значениям их идентификаторов (ID) или ключам, фильтруемые пространства классов (extents) и запросы. Поиск объектов по значениям ключей предполагает наличие предопределенных индексов. Фильтруемые пространства классов и запросы не требуют обязательного наличия индексов, но могут использовать их в своей работе. Во многих случаях поиск и фильтрация обеспечивают гораздо более высокую производительность по сравнению с запросами.


Таким образом, если сравнивать быстродействие только лишь запросов, то FastObjects проиграет реляционным системам и с этим никто не спорит.
Что же касается возможностей FastObjects, то он расчитан на использование в приложениях среднего масштаба. Для больших систем Versant позиционирует другой продукт - Versant Developer Suite, обладающий более широким набором функций, но и более сложный в эксплуатации и обучении.

www.fun4me.narod.ruА объектов там сколько заливается?

Тысячи и даже десятки тысяч транзакций в секунду, миллионы объектов и тысячи одновременно работающих пользователей - не проблема.
Например, на базе Versant VDS созданы:
некоторые военные системы (анализ данных радаров, прогнозирование воздушной обстановки, управление боевыми действиями в воздухе), которыми оснащаются крейсеры класса "Эгида" (Aegis);
система прогнозирования погоды в масштабах всей планеты на базе поступающих в реальном времени данных с десятков спутников и сотен наземных станций.
Возможности FastObjects несколько меньше, но они также впечатляют и вполне достаточны для подавляющего большинства бизнес-систем.

Константин Лисянский

Мало залить 2 Терабайта. Если их потом не трогать, то можно и подливать в день по 2 ГБ. Проблем тоже не видно. Да и двумя терабайтами уже давно никого не удивишь. В настоящее время объёмы крупнейших хранилищ данных (на реляционных СУБД) уже считаются десятками и сотнями терабайт. Так что, восклицательные знаки можно убирать :)

А что ещё можно сравнивать кроме запросов? В РСУБД кроме запросов больше ничего нет. Всё запросами делается.

http://lissianski.narod.ru

Ну про Versant могу сказать, что на базе VDS вполне успешно работают базы объемом более 20 Тб. Ну а уж если говорить пр БД вообще, то знаете ли вы где и на чем лежит САМАЯ БОЛЬШАЯ в мире база данных ?

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

Stanford Linear Accelerator использует объектную СУБД Objectivity/DB , весьма популярную в научных кругах. Кстати сейчас объем этой базы уже превысил петабайт.