Объектные базы данных?
Victor V. Metelitsa
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
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
Пятница, 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
то
> выигрыш от использования OODB по сравнению с реляционками может
составить
> до 1000 раз - по словам людей из иностранных ньюсов которые
> пишут для OOBD. Вообще, тебе лучше почитать иностранные форумы на эту
тему
> - там гораздо больше реально встрявших людей ;) для нашей страны это
видимо
> экзотика и не в последнюю степень из-за непомерной цены на объектные
базы
> т.е. или мы платим $10-20К за рантайм лицензию Обжективити/Гемстоуна
> или юзаем наколенные поделия типа Озоне...
Есть ли что фриварное (лучше десктопное - для одной машины, но не
обязательно) или (потупив глаза :) крекнутое?
Victor V. Metelitsa
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
message news:9906...@p58.f30.n5077.z2.fidonet.ftn...
...
>
> Если данные приложения хорошо ложатся на объектно-сетевую структуру,
то
> выигрыш от использования OODB по сравнению с реляционками может
составить
> до 1000 раз - по словам людей из иностранных ньюсов которые
> пишут для OOBD. Вообще, тебе лучше почитать иностранные форумы на эту
тему
А что за форумы?
Линки плз.
--
Igor
Vladyslav Kosulin
> Линки плз.
идешь на http://www.deja.com/usenet
и ищешь группы *.object.*
Или на http://www.cetus-links.org.
Неужели трудно самому догадаться? 8-/
---
Sincerely,
Vladyslav Kosulin, Pittsburgh, PA
(vkos...@symphoni.com)