Объектные базы как они есть - Философия программирования

Здравствуйте, eao197, Вы писали:

V>>------------
V>>Как неплохую полумеру, я бы рассмотрел пока надежный движок РСУБД, который можно было бы ембеддить прямо в свою программу. Причем, открыть доступ к данным не только посредством SQL-запросов, но и для обычного алгоритмического сканирования и обработки. Да, тут уже за эффективность "плана" запроса будет отвечать сам программист, однако при наличии очень большого радиуса кривизны рук, можно получить весьма эффективную систему, сочетающую все, что нужно сочетать...

E>По-моему, есть такие готовые ООСУБД.

V>>я бы не отказался в коде писать нечто (некий С++ — подобный язык, например):

E>Что-то похожее на то, что ты описал, поддерживали ООСУБД, в которых была поддержка C++. Насколько мне помниться, похожие возможности предоставлял POET (в последствии FastObjects).

Действительно очень похоже на FastObjects — особенно на FastObjects .NET (там тоже все модификаторы прямо в коде описания классов). Да и названные вами характеристики (ембеддить прямо в свою программу) — это тоже именно про FastObjects.

Здравствуйте, Cyberax, Вы писали:

C>eao197 пишет:

>> Значит возможностей РСУБД в этом направлении с лихвой хватает. И
>> совсем не факт, что супер-пупер ООСУБД (если такое вообще возможно)
>> сделает прорыв в этой области. А Java я упоминул, потому, что там, как
>> мне помниться, в J2EE были работы по прозрачной сериализации
>> Java-объектов в БД и по такому же прозрачному подъему из БД.

C>Тут разве еще не говорили? http://www.hibernate.org/ — OR-mapping для
C>Java. Поддерживает отображение отношений, _полиморфзм_ (он замечательно
C>ложится на РСУБД, кстати) и еще кучу фич.

C>И что характерно — все работает и реально используется.

Посмотрите этот бенчмарк: http://www.middlewareresearch.com/torpedo/results.jsp

Так что, как видно из результатов, Hibernate не так уж и хорош...

GZ>Что касается билетов. Была некоторая рекламная статья, от какой-то OODB. Какая не помню (давно было), но прикольно то что они как раз и обналичивали кассы авиабилетов. Вобщем замена Oracle на OODB дало очень большой прирост в производительности. Но чего-то сразу ее не нашел. Так что, верьте на слово.

Вот например, такая информация:

Versant in Transportation: Air France

Air France selected Versant and the Sabre Availability Processor (SAP) in 1997 to deploy a next generation yield management application to optimize global revenue by 1-2%
Versant’s object database management system was chosen because it could model a complex array of worldwide fares, inventory and schedules and calculate costs on an individual seat level, critical requirements that a relational database could not handle
Using Versant and SAP, Air France continues to generate incremental revenue streams while guaranteeing response times of under 2 seconds

“The Versant and SAP based solution extends the life of our mainframe system by processing transactions off the mainframe. The application is even faster than we expected and will generate returns that impact our bottom line.”

Pierre Gandois
Air France, Yield Management Project Manager

Versant in Transportation: British Airways

Versant ODBMS is the core database for BA’s Yield Management System used to maximize revenues. Delivered on time and within budget
Why BA selected Versant
Performance: Versant proved to be the best performing DB (40X) in benchmarks against RDBs and other ODBs
Scalability: Proven scalability of data volumes, transaction rates. 1500 flights per day vs 50 for an RDB.
24x7 capability: High availability support including online DB admin and online schema evolution, HA Backup.
Support & professional services: Highly capable and responsive support staff

Подробнее о ООСУБД Versant как всегда здесь

AR>Во-первых, чувствуется слабость оптимизаторов (особенно это касается FastObjects). Как результат приходтся более внимательно писать приложение и часть работы по оптимизации выполнять самому, не надеясь на то, что оптимизатор выберет наилучшее решение. Но главное — нужно так строить сами объектные структуры, чтобы заменить запросы прямой навигацией. Ко всему и ограниченность имеющегося языка запросов (FastObjects) не способствует тому, чтобы было желание запросы активно использовать. Как ни странно, указанный подход вполне срабатывает. ООСУБД предлагают достаточно инструментов, которые реально замещают запросы во многих ситуациях.

в ответ на это можно привести сообщение с SQL.ru:

Как-то в поледнее время гложит мысль, что cost-based оптимизатор — не обязательно есть польза. Просто у нас тут баальшая база, ну и куча запросов естественно. Мого времени тратится на переписывание уже давно написанных запросов. При этом цикл примерно сделующий:

Хорошо еще , если из этого цикла есть выход по условию, являющийся естественно полной фиксацией плана запроса в виде хинтов , forceplan ("прибивает гвоздями" порядок обработки таблиц в запросе, если кто не знает) и прочей лабуды (если она вообще есть у сервера, вон говорят в DB2 вообще нет хинтов).

Вот и задумываюсь я. Вроде бы как cost-based оптимизатор — стандарт для Enterprise-систем. И вижу я впереди полный беспросвет в виде вышеприведенного бесконечного цикла. Выхода нету. Все.

Простите за англ язык, вот, напрмер, такая информация:

Versant in Transportation: Air France

Air France selected Versant and the Sabre Availability Processor (SAP) in 1997 to deploy a next generation yield management application to optimize global revenue by 1-2%
Versant’s object database management system was chosen because it could model a complex array of worldwide fares, inventory and schedules and calculate costs on an individual seat level, critical requirements that a relational database could not handle
Using Versant and SAP, Air France continues to generate incremental revenue streams while guaranteeing response times of under 2 seconds

“The Versant and SAP based solution extends the life of our mainframe system by processing transactions off the mainframe. The application is even faster than we expected and will generate returns that impact our bottom line.”
Pierre Gandois
Air France, Yield Management Project Manager

Versant in Transportation: British Airways

Versant ODBMS is the core database for BA’s Yield Management System used to maximize revenues. Delivered on time and within budget
Why BA selected Versant

Performance: Versant proved to be the best performing DB (40X) in benchmarks against RDBs and other ODBs

Scalability: Proven scalability of data volumes, transaction rates. 1500 flights per day vs 50 for an RDB.
24x7 capability: High availability support including online DB admin and online schema evolution, HA Backup.

Support & professional services: Highly capable and responsive support staff

Про VDS можно почитать здесь

V>я бы не отказался в коде писать нечто (некий С++ — подобный язык, например):
V>

V>[key<number>]
V>[persist]
V>struct MyDocRow : DbRow {
V>    int number;

V>    [index(SortAsc)]
V>    date docDate;

V>    int state;
V>};

V>[persist]
V>struct MyDocDetail : DbRow {
V>    refRow<MyDocRow> doc;
    
V>    money rowSum;
V>};


V>bool filter1(MyDocRow& docRow) { return state==5; };

V>struct filter2 {
V>   money threshold;
V>   filter2(money threshold) {this.threshold = threshold; }
V>   bool operator()(MyDocDetail& docDetail) { return rowSum>=threshold; }
V>}

V>[...]

V>struct DocSums : TmpRow {
V>    int docNumber;
V>    money docSum;    

V>    static Calculate(MyDocRow& docRow, Enumerator<MyDocDetail> detail) {
V>        docNumber = row.number;
V>        docSum = agregate_sum<MyDocDetail::rowSum>(detail);
V>    }
V>}

V>// целевой алгоритм
V>Enumerator<DocSums> GetDocSums(money threshold, date date1, date date2) {
V>    Enumerator<MyDocRow> docEnumerator = sort<MyDocRow::number, SortAsc>(seek(ByIndex<MyDocRow::docDate>(date1, date2)), filter1);
V>    NestedEnumerator<MyDocRow, MyDocDetail> docWithDetailEnumerator = join<MyDocDetail::doc>(docEnumerator, filter2(threshold));

V>    return transform<DocSums>(docWithDetailEnumerator, DocSums::Calculate);
V>}
V>

В ООСУБД (например, Versant'овских) так есть.
Грубо говоря, поставилди классу persistant, он сохранился...

Здравствуйте, BaZa, Вы писали:

BZ>Performance: Versant proved to be the best performing DB (40X) in benchmarks against RDBs and other ODBs
Да. Очень похоже что именно это я и видел. Меня просто поразила данная цифра, потому и запомнил.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, BaZa, Вы писали:

BZ>Вот и задумываюсь я. Вроде бы как cost-based оптимизатор — стандарт для Enterprise-систем. И вижу я впереди полный беспросвет в виде вышеприведенного бесконечного цикла. Выхода нету. Все.
В большей степени — это проблема больше надумана. Я ни разу в жизни в рабочих проектах не использовал настройки оптимизатора для полноценных баз типа MS SQL 2000 или Oracle. Эти базы имеют достаточно хороший оптимизатор. Изменение плана выполнения в базах, чрезвычайно маловероятная вещь. Хотя и для этого много чего придумано. А управление планом выполнения через добавление индексов или темповых таблиц — считаю более правильным методом.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Джентельмены, давайте я примерно обрисую как я вижу применение OQL.
Итак. Опишем примерно стандартный сервер приложений
Стандартный сервер приложений состоит как минимум из трех слоев.
1. Фасад. То с чем общается клиент.
2. Бизнес-логика. Набор объектов и серверов.
3. Хранилище объектов. Сама БД.
Слой типа DACL я не буду упоминать, так как они в принципе к разговору не имеют отношения и реализуется любой ORM или ООБД системой. Остальные тоже поскольку не имеют отношения к разговору.
Начнем с самого верха, с фасада. У него много названий, иногда называется Remoting Facade. Одна из проблем, даже сказал бы наиболее существенная проблема решаемая им, гранулярность вызова. То есть, при вызове сервера приложений клиент старается одним вызовом сделать максимум нужной работы. Для используются два пути: 1 путь — добавление максимального кол-ва параметров в функцию вызова, 2 путь — pattern комманд. При реализации паттерна command обычно используется OQL подобный язык запросов. Так в чем-же дело?
Второе уровень. Бизнес-логика. Бизнес-логика — это набор классов отвечающих за функционирование самой логики бизнес приложений. Его можно построить используя навигационный доступ(что и делается в большинстве систем). В данном случае — OQL также имеет некоторый смысл. Коли у нас есть элементарные команды приходящие из фасадного уровня, многие команды могут быть собраны из этих элементарных команд.
Для третьего уровня OQL не нужен. Он вообще не должен быть виден прикладному программисту. Чем меньше программист знает о физическом уровне хранения, тем лучше спят остальные. Это уже чистая пререгатива логики БД. Однако — из чего состоит эта логика. Исполнение OQL зависит от этого уровня. Чем выше будет hit ratio выполнения OQL команды, тем эффективнее будет сервер. Тут нужна предсказательная логика основанная на статистике выполнения функций бизнес-логики. И чем более глубоко можно будет залезть в эту логику, тем быстрее будет выполнен запрос. Это и есть самая большая сложность. Но плюсы по сравнению с теперешними системами — будут огромны.

Итого, при нормальной реализации языка, можно вполне говорить о том, что ООБД — уже готовый сервер приложений.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

GZ>Итого, при нормальной реализации языка, можно вполне говорить о том, что ООБД — уже готовый сервер приложений.

Можно обсудить тогда реализации OQL. Я лично работал только с одной — VQL (Versant Query Language). Если кому инетересно могу рассказать.

Кстати, VDS имеет два уровня возможностей построения запросов:

VQL: объектные запросы выполняются на стороне сервера, с поддержкой навигации, курсоров и параллельных запросов...........

SQL: с поддержкой ODBC и JDBC, которая позволяет использовать инструменты построения отчетов для генерирования нерегламентированные запросов к VDS. (этот инструмент дает возможность использования ХП)

Здравствуйте, BaZa, Вы писали:

GZ>>Что касается билетов. Была некоторая рекламная статья, от какой-то OODB. Какая не помню (давно было), но прикольно то что они как раз и обналичивали кассы авиабилетов. Вобщем замена Oracle на OODB дало очень большой прирост в производительности. Но чего-то сразу ее не нашел. Так что, верьте на слово.

BZ>Вот например, такая информация:

BZ>Versant in Transportation: Air France
BZ>Versant in Transportation: British Airways

На эту же тему, но уже относительно ObjectStore:

ANA Airlines

Major Japanese airline All Nippon Airways Co., Ltd. (ANA) advocates the principle that "customers come first." To instantiate that philosophy, ANA chose ObjectStore to integrate its disparate customer databases into a single customer system that drives the ANA Mileage Club, its frequent flier program. As a result, the program participation has doubled within three years. Read the case study (PDF).

Delta Airlines

ObjectStore provides crucial data services to key DNS applications, helping to track in-flight aircraft positions by capturing and correlating data received from both Delta systems and FAA sources. Additionally, data caching services from ObjectStore are used to enable flight controllers to quickly assemble views of the overall system status, delivering responsiveness that simply was not available from its relational data stores.

Взято отсюда: http://www.objectstore.com/customers/index.ssp

И еще:

The ObjectStore ODBMS is used in SouthWest Airline's Home Gate to provide self service to travelers through the Internet. This allows them to plan trips and purchase tickets on SouthWest Airlines.

Взято отсюда: http://www.service-architecture.com/object-oriented-databases/articles/odbms_faq.html

Вообще, если заглянуть в разделы customers крупных поставщиков ООСУБД, то можно увидеть массу совершенно различных применений:
ObjectStore: http://www.objectstore.com/customers/index.ssp
ObjectivityDB: http://www.objectivity.com/AboutUs/AboutUsCustomers.shtml
http://www.objectivity.com/AboutUs/AboutUsCustomersStories.shtml
http://www.objectivity.com/AboutUs/AboutUsCustomersStories2.shtml
http://www.objectivity.com/AboutUs/AboutUsCustomersStories3.shtml
http://www.objectivity.com/AboutUs/AboutUsCustomersStories4.shtml
Matisse: http://www.matisse.com/customers/us/
http://www.matisse.com/customers/international/
GemStone: http://www.gemstone.com/partners/customers.php
Versant: http://www.versant.com/about/37

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, Poudy, Вы писали:

P>Лень заставляет говорить меня следующие вещи:
Моя лень заставляет меня молчать, желательно, в постели с бокалом коньяка(ну и все остальное).

P>я не думаю, что нужно реализовывать подмножество какого-то там языка. если уж язык управляемый, то стоит использовать именно его самого, а не имитацию. существуют permissions на код. код должен исполняться на сервере. известна проблема полиморфности. поднимать объекты из базы при выборке — страшные тормоза. значит нужно хранить объекты в памяти.
Что касается проблемы полиморфности, то сейчас уже много вещей можно делать. Например, тем чем занимается Sinclair.
В остальном — Объектные базы как сервера приложений

P>я тоже думаю, что OODB обязана быть сервером приложений. для этого нужно реализовать транзакции на уровне оперативной памяти. т.к. всё очень лень, мне кажется лучше дописать mono'вский jitter для этих вещей.
Да на здоровье, используй MTS. Он тоже менеджер транзакции в оперативной памяти. Но по моему ты плохо представляешь полноценный механизм транзакций. Как только мы наступаем на конкурирующие транзакции, то в алгоритме тривиальность пропадает. И начинается куча проблем которые приходится решать в зависимости от бизнес-логики. И механизмов гарантирующих любую транзакцию (если он не построен на конкретной бизнес-логике), я не видел.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, vdimas, Вы писали:

V>СУБД — это ср-во хранения больших объемов данных на ВНЕШНЕМ носителе таким образом, чтобы обеспечивать быстое извлечение необходимых данных в оперативную память. Для организации этого мы используем ЛОГИЧЕСКОЕ проедставление данных, ключи, индексы (уменьшающие размер ВНЕШНЕЙ памяти, требуемый для поиска) и пр.
Ошибка. Индексы предназначены не только для увеличения hit-ratio. Индексы — это способ убыстрения доступа к данным со сложностью O(NlogN) или O(1) для хешей. Это говорит о обязательности индекса при наличии большого количества объектов. А БД работает именно с большим кол-вом объектов.

V>Вполне возможно, что в какой-то момент времени в выч. системах оперативная память будет:
V>а) обладать персистентностью (типа flash).
V>б) быть "необходимого" размера.
Хорошо бы.

V>------------
V>Как неплохую полумеру, я бы рассмотрел пока надежный движок РСУБД, который можно было бы ембеддить прямо в свою программу. Причем, открыть доступ к данным не только посредством SQL-запросов, но и для обычного алгоритмического сканирования и обработки. Да, тут уже за эффективность "плана" запроса будет отвечать сам программист, однако при наличии очень большого радиуса кривизны рук, можно получить весьма эффективную систему, сочетающую все, что нужно сочетать...
Почти OODB. Только за план запроса отвечает автоматика.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

Здравствуйте, Sinclair, Вы писали:

E>>Например, если БД содержит огромное количество структурированной измерительной информации (Objectivity в CERN, как мне помниться, как раз для этого и применялась), то большинство объектов в ней вообще не нуждаются в методах.
S>Как, впрочем, и в объектах. Я плохо знаком с тем, что хранит CERN. Подозреваю, что у них с теми объектами, которые мы привыкли видеть в ООП, общего мало или вообще ничего.
S>Кстати, я встречал такое мнение, что ООБД — это "способ придания семантики данным типа BLOB".

Вот, нашел ссылку на проект, в котором используется одна из самых больших в мире объектных БД: http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, eao197, Вы писали:

E>Вот, нашел ссылку на проект, в котором используется одна из самых больших в мире объектных БД: http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml

Это и есть самая большая база данных в мире (уже польше петабайта). Работает на базе ООСУБД Objectivity/DB, которая довольно популярна в научной среде.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Здравствуйте, eao197, Вы писали:

E>>Вот, нашел ссылку на проект, в котором используется одна из самых больших в мире объектных БД: http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml

AR>Это и есть самая большая база данных в мире (уже польше петабайта). Работает на базе ООСУБД Objectivity/DB, которая довольно популярна в научной среде.

Да я знаю

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

... << RSDN@Home 1.1.4 beta 4 rev. 303>>

Здравствуйте, GlebZ, Вы писали:

GZ>Что касается проблемы полиморфности, то сейчас уже много вещей можно делать. Например, тем чем занимается Sinclair.
GZ>В остальном — Объектные базы как сервера приложений
IMHO, генерить такой SQL, как делает Sinclair — сложная и странная задача. Допустим, были бы у него исходники написанного им же RDBMS сервера. Неужели он стал бы генерировать SQL? Сейчас я смотрю на это как на попытку транслировать, допустим, C# в AST-tree, чтобы оптимизировать его для работы с ... данными на диске, грубо говоря.

P>>я тоже думаю, что OODB обязана быть сервером приложений. для этого нужно реализовать транзакции на уровне оперативной памяти. т.к. всё очень лень, мне кажется лучше дописать mono'вский jitter для этих вещей.
GZ>Да на здоровье, используй MTS. Он тоже менеджер транзакции в оперативной памяти. Но по моему ты плохо представляешь полноценный механизм транзакций. Как только мы наступаем на конкурирующие транзакции, то в алгоритме тривиальность пропадает. И начинается куча проблем которые приходится решать в зависимости от бизнес-логики. И механизмов гарантирующих любую транзакцию (если он не построен на конкретной бизнес-логике), я не видел.
Да и не только MTS. Но я не понимаю уникальности проблемы. Предположим есть MTS, который складывает каждое обращение с полю объекта в базу данных, и читает всегда оттуда же. Мне кажется, что все проблемы с изоляцией останутся.

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, GlebZ, Вы писали:

GZ>>Что касается проблемы полиморфности, то сейчас уже много вещей можно делать. Например, тем чем занимается Sinclair.
GZ>>В остальном — Объектные базы как сервера приложений
P>IMHO, генерить такой SQL, как делает Sinclair — сложная и странная задача. Допустим, были бы у него исходники написанного им же RDBMS сервера. Неужели он стал бы генерировать SQL? Сейчас я смотрю на это как на попытку транслировать, допустим, C# в AST-tree, чтобы оптимизировать его для работы с ... данными на диске, грубо говоря.
Тут я думаю он сам ответит.

GZ>>Да на здоровье, используй MTS. Он тоже менеджер транзакции в оперативной памяти. Но по моему ты плохо представляешь полноценный механизм транзакций. Как только мы наступаем на конкурирующие транзакции, то в алгоритме тривиальность пропадает. И начинается куча проблем которые приходится решать в зависимости от бизнес-логики. И механизмов гарантирующих любую транзакцию (если он не построен на конкретной бизнес-логике), я не видел.
P>Да и не только MTS. Но я не понимаю уникальности проблемы. Предположим есть MTS, который складывает каждое обращение с полю объекта в базу данных, и читает всегда оттуда же. Мне кажется, что все проблемы с изоляцией останутся.
Я наверно неправильно выразился. Я хотел противопоставить MTS и реальные проблемы изоляции что было тобой сразу подмечено.

С уважением, Gleb.

... << RSDN@Home 1.1.4 beta 4 rev. 358>>

GlebZ wrote:

> C>В хранилище ООБД инкапсюляции нет, как и в RDB.
> В хранилище нет. В ООDB да. В хранилище ООБД только состояние объектов.

Ну так и рассматривайте RDB как _хранилище_ информации, с которой вполне
можно работать в ООП-стиле.

> C>Наследование и
> C>полиморфизм замечательно выражаются в RDB в виде объединенных по PK
> C>таблиц (возможно с полями-дискриминаторами).
> Это всего лишь один из самых простых и самых неэффективных способов
> маппирования объектов в RDBMS.

В ООБД оно представляется точно таким же образом

> C>То есть на практике объектные модели (за исключением самых извращенных)
> C>вполне прилично ложатся в RDB.
> Ну почти да. Только для этого нужно очень много дописать. И учитывая
> удаленность хранилища и самой системы эффективности достойной ООДБ ты
> точно не получишь

Ничего особо не нужно на практике. Берется Hibernate, пишется
mapping-файл (этот шаг можно пропустить и сгенерировать его из описания
БД или из Java-классов). Удаленность БД, конечно, сказывается, но далеко
не фатально — в реальности все работает более чем удовлетворительно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Sinclair wrote:

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

http://www.hibernate.org/hib_docs/reference/en/html/queryhql.html
Пункт 11.6 "Polymorphic queries"

Кроме того, рекомендую прочитать документацию по Hibernate, чтобы потом
не натыкаться на такие "несуществующие" решения.

> C>вполне прилично ложатся в RDB.
> Нормальный полиморфизм ты в RDB запаришься складывать. Точнее,
> внесение малейших изменений потребует перетряхивания значительной
> части схемы.

Я _уже_ год _на_ _практике_ работаю с полиморфными объектами в БД.
Никаких особых проблем.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

От:	Alexey Rovdo	http://ru.linkedin.com/in/rovdo
Дата:	08.04.05 06:23
Оценка:

	От:	BaZa
	Дата:	08.04.05 06:34
	Оценка:

	От:	BaZa
	Дата:	08.04.05 07:45
	Оценка:	62 (3)

	От:	BaZa
	Дата:	08.04.05 08:44
	Оценка:

	От:	BaZa
	Дата:	08.04.05 08:52
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	08.04.05 11:09
Оценка: