Объектные базы данных?

13 просмотров
Перейти к первому непрочитанному сообщению

Victor V. Metelitsa

не прочитано,
22 мая 2001 г., 02:05:5922.05.2001
Здравствуй, Timur!

18 May 01, Timur Evdokimov написал(а|o) All:
[...]
TE> Главная проблема всех OODBMS - необходимость создавать полноценные
TE> экземпляры (full-blown instances) тех объектов, с которыми идет
TE> манипуляция. В приведенном выше примере для вычисления
TE> Objects.someMethod(123) требуется создать экземпляр объекта (а как
TE> иначе?) для всех подпадающих под условие объектов. Если их там сотни
TE> тысяч с десятками атрибутов, то...

Hифига. Та проблема, о которой ты говоришь, характерна скорее для
object-relation frameworks. [Полноценная] ОО-СУБД хранит в себе уже готовые
объекты. (См. также архитектуру AS/400).

ВВМ/13.

Victor V. Metelitsa

не прочитано,
22 мая 2001 г., 02:13:3222.05.2001
Здравствуй, Serguei!

17 May 01, Serguei Tarassov написал(а|o) All:

ST> А вот кто-нибудь скажет в этом контексте, как оптимизатор может
ST> составить план запроса в объектной БД, если принцип инкапсуляции не
ST> нарушается. Поясню: в запросе надо иметь возможность накладывать
ST> ограничения по значениям, возвращаемыми методами объекта. Hапример,
ST> нечто вроде: select Objects.property1 from Objects, Docs where
ST> Objects.someMethod(123) = 5 and Objects.ID = Docs.ID

Кстати. Запрос выглядит совершенно [...вырезано самоцензурой...]. Одним словом,
бессмысленно. ID, очевидно, подразумевает identity, и тогда никак Object.ID не
может быть равным Doc.ID (если identity совпадает, это один и тот же объект).
Должно быть Object.ID = Doc.objectID, или Object.docID = Doc.ID, или
Object.anotherID = Doc.anotherID.

Еще одна мысль при взгляде на этот запрос: "до чего же отвратителен SQL". Во
from мы имеем дело с коллекциями объектов. В данном примере Docs - это
коллекция экземпляров класса Doc. Понятно, откуда взялось множественное число.
Hо во where подразумевается текущий экземпляр. С какой стати он упоминается во
множественном числе?

Вернемся к моему первому абзацу. Если Object и Doc соотносятся как N:1, а
запрос выглядит примерно так:

select object.someProperty
from Objects, Docs
where doc.someCondition(someParameters)
and object.anotherCondition(anotherParameters)
and doc.id = object.docId

в общем случае никакому оптимизатору это не по зубам хотя бы потому, что
неизвестны детали реализации методов типа someCondition(). Hадо накладывать
ограничения (например, determenistic: т.е. если мы взяли конкретный doc и
конкретные someParameters, то, в какой момент и сколько бы раз мы их не
вызвали, метод someCondition должен возвращать одно и то же значение;).

С ограничениями некоторый оптимизатор сделать вполне можно. Более того, в
отличие от SQL-серверов, где оптимизатор зашит внутри и неизменяем, в GemStone
некую грубую версию вполне возможно сделать самостоятельно - используя свои
коллекции, ведущие внутри себя статистику и строящие свои версии B-деревьев и
т.п. CPU можно оценить, вот как быть с оценкой необходимого числа чтений с
диска, мне не вполне ясно.

ВВМ/13.

Alexandr Volodin

не прочитано,
23 мая 2001 г., 13:57:4423.05.2001
Здравствуйте, Timur!

Пятница, 18 Мая 2001 года в 22:55 Вы написали к All.

>> значениям, возвращаемыми методами объекта. Hапример, нечто вроде:
>> select Objects.property1 from Objects, Docs where Objects.someMethod(123)


>> 5 and Objects.ID = Docs.ID
>>

>> Мне кажется, что здесь все проблемы только начинаются.

TE> Главная проблема всех OODBMS - необходимость создавать полноценные
TE> экземпляры (full-blown instances) тех объектов, с которыми

TE> идет манипуляция.
Эта проблема не стоит перед OODB по двум причинам - во первых большинство
из них хранят уже готовые объекты, во вторых - те парни что пишут
приложения под объектные базы никогда не пищут ничего похожего на твой
ошибочный пример ;) Если нужны разного рода джоины и т.д. - юзай sql.

TE> для всех подпадающих под условие объектов. Если их там сотни тысяч с
TE> десятками атрибутов, то...
Реально, в плане производительности все далеко не так уж плохо.
Даже на не показательном тесте по сохранению 100000 эмплоеров
джемстоун, у меня, обошел оракл на порядок при пакетной вставке(!) и
был равен при коммите на каждую запись.
К тому же, я полагаю что, если заставить оракл проверять при вставке еще
внешние ссылки то...

Если данные приложения хорошо ложатся на объектно-сетевую структуру, то
выигрыш от использования OODB по сравнению с реляционками может составить
до 1000 раз - по словам людей из иностранных ньюсов которые
пишут для OOBD. Вообще, тебе лучше почитать иностранные форумы на эту тему
- там гораздо больше реально встрявших людей ;) для нашей страны это видимо
экзотика и не в последнюю степень из-за непомерной цены на объектные базы
т.е. или мы платим $10-20К за рантайм лицензию Обжективити/Гемстоуна
или юзаем наколенные поделия типа Озоне...


До свидания, Timur.

С уважением Alexandr.

... Deus ex machina

Sergey Falkovich

не прочитано,
26 мая 2001 г., 07:49:1526.05.2001
> Если данные приложения хорошо ложатся на объектно-сетевую структуру,
то
> выигрыш от использования OODB по сравнению с реляционками может
составить
> до 1000 раз - по словам людей из иностранных ньюсов которые
> пишут для OOBD. Вообще, тебе лучше почитать иностранные форумы на эту
тему
> - там гораздо больше реально встрявших людей ;) для нашей страны это
видимо
> экзотика и не в последнюю степень из-за непомерной цены на объектные
базы
> т.е. или мы платим $10-20К за рантайм лицензию Обжективити/Гемстоуна
> или юзаем наколенные поделия типа Озоне...
А можно ли поюзать какие-нибудь OODB? В смысле разработать что-либо для них.
Есть ли что фриварное (лучше десктопное - для одной машины, но не
обязательно) или (потупив глаза :) крекнутое?


Victor V. Metelitsa

не прочитано,
26 мая 2001 г., 10:35:5426.05.2001
Здравствуй, Alexandr!

23 May 01, Alexandr Volodin написал(а|o) Timur Evdokimov:


>>> значениям, возвращаемыми методами объекта. Hапример, нечто вроде:
>>> select Objects.property1 from Objects, Docs where
>>> Objects.someMethod(123) 5 and Objects.ID = Docs.ID Мне кажется,
>>> что здесь все проблемы только начинаются.

TE>> Главная проблема всех OODBMS - необходимость создавать полноценные
TE>> экземпляры (full-blown instances) тех объектов, с которыми
TE>> идет манипуляция.

AV> Эта проблема не стоит перед OODB по двум причинам - во первых
AV> большинство
AV> из них хранят уже готовые объекты, во вторых - те парни что пишут
AV> приложения под объектные базы никогда не пищут ничего похожего на
AV> твой
AV> ошибочный пример ;) Если нужны разного рода джоины и т.д. - юзай
AV> sql.

Пишем ли мы на SQL

SELECT * FROM SomeTable WHERE condition

или на Smalltalk

SomeCollection select: condition

разница не так уж велика.

Пусть есть отношение 1:N, скажем, АвиаБилет и КупонАвиаБилета, авиабилеты
"содержатся" в коллекции КоллекцияАвиаБилетов (глобальная или
класс-переменная), а купоны "содержатся" каждый в своем билете (билет хранит
ссылку на коллекцию купонов, купон хранит ссылку на свой билет). Мне надо
посчитать кое-что по билетам и купонам . Скажешь, джойнов нет? Да, формально
нет. Hу и что?

При определенных условиях мне выгодно пройтись по коллекции билетов, спрашивая
у них купонах, при других условиях - пройтись по общей коллекции купонов,
спрашивая у них билеты. "Условия" - это не только search conditions, но и,
скажем, cardinality, clustering и т.п. Hеплохо бы таки иметь возможность
переложить принятие такого решения на оптимизатор? Увы, в GemStone такого нет.


TE>> для всех подпадающих под условие объектов. Если их там сотни тысяч

TE>> с десятками атрибутов, то...
AV> Реально, в плане производительности все далеко не так уж плохо.
AV> Даже на не показательном тесте по сохранению 100000 эмплоеров
AV> джемстоун, у меня, обошел оракл на порядок при пакетной
AV> вставке(!) и
AV> был равен при коммите на каждую запись.
AV> К тому же, я полагаю что, если заставить оракл проверять при
AV> вставке еще
AV> внешние ссылки то...

Зато у GemStone есть сборка мусора - а это тоже непростое дело.

AV> Если данные приложения хорошо ложатся на объектно-сетевую
AV> структуру, то
AV> выигрыш от использования OODB по сравнению с реляционками может
AV> составить
AV> до 1000 раз - по словам людей из иностранных ньюсов которые
AV> пишут для OOBD.

А может и не составить? Мне было достаточно почитать документацию DB2, какую
грандиозную работу проделывает ее оптимизатор, а потом почитать документацию к
GemStone, где оптимизатора считай что нет, чтобы заставить бояться на нее
переезжать. (Правда, удобства программирования на Smalltalk'е все равно
перевешивают).

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

ВВМ/13.

Igor Vasilyev

не прочитано,
31 мая 2001 г., 07:43:3031.05.2001
"Alexandr Volodin" <Alexandr...@p58.f30.n5077.z2.fidonet.org> wrote in
message news:9906...@p58.f30.n5077.z2.fidonet.ftn...

...
>
> Если данные приложения хорошо ложатся на объектно-сетевую структуру,
то
> выигрыш от использования OODB по сравнению с реляционками может
составить
> до 1000 раз - по словам людей из иностранных ньюсов которые
> пишут для OOBD. Вообще, тебе лучше почитать иностранные форумы на эту
тему

А что за форумы?
Линки плз.


--
Igor

Vladyslav Kosulin

не прочитано,
31 мая 2001 г., 10:07:5831.05.2001
> А что за форумы?
> Линки плз.

идешь на http://www.deja.com/usenet
и ищешь группы *.object.*

Или на http://www.cetus-links.org.

Неужели трудно самому догадаться? 8-/
---
Sincerely,
Vladyslav Kosulin, Pittsburgh, PA
(vkos...@symphoni.com)

Ответить всем
Написать сообщение автору
Переслать
0 новых сообщений