Считает ли кто-нибудь, что Prevayler и его клоны (Bamboo.Prevalence) являются правильным подходом к OODB? Тем более, что в них появились индексы и даже на XPath?
Здравствуйте, Poudy, Вы писали:
P>Считает ли кто-нибудь, что Prevayler и его клоны (Bamboo.Prevalence) являются правильным подходом к OODB? Тем более, что в них появились индексы и даже на XPath?
И что?
1. Эффективный навигационный доступ возможен только при наличии локальной базы.
2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
Резюме.
Это поделка без каких либо вариантов называться серьезной OODB не может.
Здравствуйте, GlebZ, Вы писали:
GZ>1. Эффективный навигационный доступ возможен только при наличии локальной базы.
Не понимаю довода.
Эффективный — это быстрый или мощный?
навигационный — это просто Select или курсоры?!
локальная база — расположена на моем винчестере?
GZ>2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД.
GZ>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
Насколько я понял, гарантии такие же, как и при использовании РСУБД. Т.е. если РСУБД не упала, всё работает, если упала — ну что тут поделаешь: меняйте провайдера. Транзакций нет.
GZ>Резюме. GZ>Это поделка без каких либо вариантов называться серьезной OODB не может.
Вопрос звучал: правильный ли это подход? Транзакции и изоляцию можно навернуть просто на уровне объектов. Но что насчет подхода?
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, GlebZ, Вы писали:
GZ>>1. Эффективный навигационный доступ возможен только при наличии локальной базы.
P>Не понимаю довода. P>Эффективный — это быстрый или мощный?
Да. P>навигационный — это просто Select или курсоры?!
Курсоры. В случае если она расположена удаленно, ты получаешь ворох межпроцессорных вызовов по сетке. P>локальная база — расположена на моем винчестере?
Да
GZ>>2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
P>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД.
Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных.
GZ>>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
P>Насколько я понял, гарантии такие же, как и при использовании РСУБД. Т.е. если РСУБД не упала, всё работает, если упала — ну что тут поделаешь: меняйте провайдера. Транзакций нет.
Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде. Что касается prevalyar я в принципе не смотрел, есть ли возможность откатов транзакций. И возможна ли работа в виде Read Commited?
GZ>>Резюме. GZ>>Это поделка без каких либо вариантов называться серьезной OODB не может. P>Вопрос звучал: правильный ли это подход? Транзакции и изоляцию можно навернуть просто на уровне объектов.
Не получится. Транзакционный механизм является влияющим на всю архитектуру. Особенно в контексте изолированности и concurency. P>Но что насчет подхода?
Это все и был ответ.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, GlebZ, Вы писали:
GZ>>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных.
V>Не проблема. 64-bit Windows на подходе.
Проблема в отношении стоимости оперативной памяти без которой оно не будет шевелиться и дисковой.
Здравствуйте, GlebZ, Вы писали:
P>>Эффективный — это быстрый или мощный? GZ>Да.
Что да Оба что ли?
P>>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД. GZ>Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
Не верю, что известно. Мне непонятно, откуда может взяться разница.
GZ>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных.
Это так, но дело в том, что РСУБД неэффективно использует место и + хранит много дополнительной информации. Возьмем какую-нибудь процессинговую систему: десять миллионов записей о продажах шириной в 200 колонок должна весить около 16 гигабайт, а что получаем на деле?
GZ>Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде.
Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях.
GZ>Что касается prevalyar я в принципе не смотрел, есть ли возможность откатов транзакций. И возможна ли работа в виде Read Commited?
Всё на уровне объектов. Т.е. если белать базу на Prevalayer, кому-то придется повторить все эти фишки с уровнями изоляции в виде некоторой библиотеки.
GZ>Это все и был ответ.
Паааняааатна.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, GlebZ, Вы писали:
P>>>Эффективный — это быстрый или мощный? GZ>>Да. P>Что да Оба что ли?
Почему бы и нет.
P>>>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД. GZ>>Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
P>Не верю, что известно. Мне непонятно, откуда может взяться разница.
Ой, знаешь сколько механизмов сделано ради этого. Наличие свободного пространства — чтобы можно было быстро впихнуть значение, порядок объектов — которые не обязательно упорядочены по некоторому значению (в пределах страницы всегда) но всегда упорядочены по типам, и соответсвенно загрузка происходит не одной страницы, а сразу по нескольким если высока вероятность что будут прочитаны объекты с других страниц. Экстенты. и т.д.
Раньше было в порядке вещей делать свои драйвера для диска. Чтобы класть данные именно в таком порядке, чтобы не перебегать головкой диска с дорожки на дорожку. Сейчас (IMХО) подразумевается что система хранит файл БД в дефрагментированном состоянии. А свап по определению внутри сильно дефрагментирован.
GZ>>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных. P>Это так, но дело в том, что РСУБД неэффективно использует место и + хранит много дополнительной информации. Возьмем какую-нибудь процессинговую систему: десять миллионов записей о продажах шириной в 200 колонок должна весить около 16 гигабайт, а что получаем на деле?
Используется оно в том то и дело, очень эффективно. И занимает место для этой цели, действительно больше.
GZ>>Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде. P>Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях.
Ну-ну. А если база данных распределенная? И состояние на других хостах уже изменено?
Мы используем Prevayler в реальном проекте для хранения кэша на клиенской стороне. Вещь действительно изящная. Но...
Prevayler фактически это не более чем навороченная сериализация (через "транзакции") сложной структуры данных. Следствие — если начали использовать одну структуру — ее уже нельзя менять. А бывает нужно. Из-за этого приходится извращаться, придумывать спец. форматы объектов, промежуточно сначала сериализовать во что-то простое и т.д.
В общем хотим отказаться.
GZ>Здравствуйте, Poudy, Вы писали:
P>>Здравствуйте, GlebZ, Вы писали: P>>>>Эффективный — это быстрый или мощный? GZ>>>Да. P>>Что да Оба что ли? GZ>Почему бы и нет.
P>>>>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД. GZ>>>Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
P>>Не верю, что известно. Мне непонятно, откуда может взяться разница. GZ>Ой, знаешь сколько механизмов сделано ради этого. Наличие свободного пространства — чтобы можно было быстро впихнуть значение, порядок объектов — которые не обязательно упорядочены по некоторому значению (в пределах страницы всегда) но всегда упорядочены по типам, и соответсвенно загрузка происходит не одной страницы, а сразу по нескольким если высока вероятность что будут прочитаны объекты с других страниц. Экстенты. и т.д. GZ>Раньше было в порядке вещей делать свои драйвера для диска. Чтобы класть данные именно в таком порядке, чтобы не перебегать головкой диска с дорожки на дорожку. Сейчас (IMХО) подразумевается что система хранит файл БД в дефрагментированном состоянии. А свап по определению внутри сильно дефрагментирован.
GZ>>>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных. P>>Это так, но дело в том, что РСУБД неэффективно использует место и + хранит много дополнительной информации. Возьмем какую-нибудь процессинговую систему: десять миллионов записей о продажах шириной в 200 колонок должна весить около 16 гигабайт, а что получаем на деле? GZ>Используется оно в том то и дело, очень эффективно. И занимает место для этой цели, действительно больше.
GZ>>>Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде. P>>Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях. GZ>Ну-ну. А если база данных распределенная? И состояние на других хостах уже изменено?
GZ>С уважением, Gleb.
Как человек, самолично реализовавший концепцию Prevayler'a на Питоне отвечу: GZ>1. Эффективный навигационный доступ возможен только при наличии локальной базы.
В целом верно. Prevayler и не должен решать проблему удаленного доступа, он слишком прост для таких задач. Посмотрите, впрочем, поддержку репликации, которую они там пытаются всандалить. GZ>2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
Тоже верно. Никаких сомнений/возражений. Однако немало задач есть где это не так уж критично. Зато скорость GZ>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
Неверно. Зависит от реализации механизма транзакций. Как это нет гарантии, что была зафиксирована ??? Очень даже есть гарантия....
GZ>Резюме. GZ>Это поделка без каких либо вариантов называться серьезной OODB не может.
В целом верно. "Серьезной" ООБД — не может. Но серьезных ООБД вообще не существует — эта область плохо проработана. Тем не менее для определенного круга задач — гениальное решение.
Здравствуйте, Borisman2, Вы писали:
GZ>>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие. B>Неверно. Зависит от реализации механизма транзакций. Как это нет гарантии, что была зафиксирована ??? Очень даже есть гарантия....
На тот момент, когда я просматривал Prevayler, гарантировалися только моменты сериализации объектов. Что-то изменилось?
GZ>>Резюме. GZ>>Это поделка без каких либо вариантов называться серьезной OODB не может. B>В целом верно. "Серьезной" ООБД — не может. Но серьезных ООБД вообще не существует — эта область плохо проработана. Тем не менее для определенного круга задач — гениальное решение.
Абсолютно согласен. У него есть достаточно большой круг задач где он действительно полезен. Но просто упор делался ООБД. В котором две последние буквы не очень вписываются в концепцию.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Borisman2, Вы писали:
GZ>>>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие. B>>Неверно. Зависит от реализации механизма транзакций. Как это нет гарантии, что была зафиксирована ??? Очень даже есть гарантия.... GZ>На тот момент, когда я просматривал Prevayler, гарантировалися только моменты сериализации объектов. Что-то изменилось?
Ничего не изменилось. Сериализация транзакции перед выполнением и есть ее фиксация.
GZ>Абсолютно согласен. У него есть достаточно большой круг задач где он действительно полезен. Но просто упор делался ООБД. В котором две последние буквы не очень вписываются в концепцию.
Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
Здравствуйте, GlebZ, Вы писали:
GZ>Ой, знаешь сколько механизмов сделано ради этого. Наличие свободного пространства — чтобы можно было быстро впихнуть значение, порядок объектов — которые не обязательно упорядочены по некоторому значению (в пределах страницы всегда) но всегда упорядочены по типам, и соответсвенно загрузка происходит не одной страницы, а сразу по нескольким если высока вероятность что будут прочитаны объекты с других страниц. Экстенты. и т.д.
Ну и хорошо, что сделано. IMHO, такие вещи относятся вообще к DB, а не только к RDBMS.
GZ>Раньше было в порядке вещей делать свои драйвера для диска. Чтобы класть данные именно в таком порядке, чтобы не перебегать головкой диска с дорожки на дорожку. Сейчас (IMХО) подразумевается что система хранит файл БД в дефрагментированном состоянии. А свап по определению внутри сильно дефрагментирован.
Ну и хорошо, что подразумевается. Я не вижу никаких причин, препятствующих организовать своп таким же эффективным образом.
P>>Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях. GZ>Ну-ну. А если база данных распределенная? И состояние на других хостах уже изменено?
Да нет, всё нормально будет. Ну послушай еще раз: перед собственно выполнением операции на всех хостах, она сериализуется: сама операция сериализуется. Все запросы сначала попадают на диск, а потом уже выполняются. При восстановлении от сбоя все эти запросы прогоняются вновь на сериализованном когда-то в момент снапшота графе объектов.
Здравствуйте, denis_krg, Вы писали:
_>Мы используем Prevayler в реальном проекте для хранения кэша на клиенской стороне. Вещь действительно изящная. Но... _>Prevayler фактически это не более чем навороченная сериализация (через "транзакции") сложной структуры данных. Следствие — если начали использовать одну структуру — ее уже нельзя менять. А бывает нужно. Из-за этого приходится извращаться, придумывать спец. форматы объектов, промежуточно сначала сериализовать во что-то простое и т.д.
Интересно. А разве с таблицами не возкитает такой же подставы? Я вижу проблему в том, что хранилище данных объектов — это просто куча мусора без нормальной структуры, которую можно было бы просматривать и редактировать.
_>В общем хотим отказаться.
По-моему идея Prevalayer никак не нарушится от того, что данные объектов будут храниться в RDB. Ведь идея не в сериализации, ну правда же... Сохраняя объекты в обычную базу вы можете выиграть в обоих направлениях.
Здравствуйте, Borisman2, Вы писали:
B>Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
Полностью согласен. Сколько не читал про эти ООБД и ООСУРБД — никто толком даже не смог объяснить, каким боком они собираются всунуть в эти БД наследование в понятии ООП. По моему, народ услышал термин ООП, разобрался в нем и теперь пытается запихать это ООП куда не поподя. Ну почему движок должен быть обязательно встроен в БД? Разве не достаточно какого-нибудь фреймворка над РБД? Мой ответ — вполне.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Borisman2, Вы писали:
B>>Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
R3>Полностью согласен. Сколько не читал про эти ООБД и ООСУРБД — никто толком даже не смог объяснить, каким боком они собираются всунуть в эти БД наследование в понятии ООП. По моему, народ услышал термин ООП, разобрался в нем и теперь пытается запихать это ООП куда не
Думаю, что здесь ты не прав. Первые ООСУБД появились в середине восьмидесятых. Когда и ООП не был таким раскрученным брендом, да и SQL еще не стал промышленным стандартом.
R3> поподя. Ну почему движок должен быть обязательно встроен в БД? Разве не достаточно какого-нибудь фреймворка над РБД? Мой ответ — вполне.
Не согласен. Во-первых, на реляционные таблицы тяжело отображать, например, наследование и некоторые типы атрибутов объектов (вектора). Во-вторых, разбиение объекта на ряд реляционных отношений при записи в БД и сборка его из этих отношений при чтении снизят производительность такой настройки. А ООСУБД осуществляют запись/извлечения объекта целиком, что позволяет им получать большую производительность по сравнению с РСУБД (но для объективности нужно сказать, что не для всех задач ООСУБД подходят).
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Во-первых, на реляционные таблицы тяжело отображать, например, наследование и некоторые типы атрибутов объектов (вектора).
Согласен, но после создания некоторой оболочки над БД (фреймворка) всё становится просто. Другой вопрос: объясни мне что такое наследование в понятии ООБД?
E> Во-вторых, разбиение объекта на ряд реляционных отношений при записи в БД и сборка его из этих отношений при чтении снизят производительность такой настройки.
И тут нам поможет оболочка.
E> А ООСУБД осуществляют запись/извлечения объекта целиком, что позволяет им получать большую производительность по сравнению с РСУБД (но для объективности нужно сказать, что не для всех задач ООСУБД подходят).
Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД.
P.S. Замечу, что я не спорю, а пытаюсь разобраться.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Borisman2, Вы писали:
B>>Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
R3>Полностью согласен. Сколько не читал про эти ООБД и ООСУРБД — никто толком даже не смог объяснить, каким боком они собираются всунуть в эти БД наследование в понятии ООП. По моему, народ услышал термин ООП, разобрался в нем и теперь пытается запихать это ООП куда не поподя. Ну почему движок должен быть обязательно встроен в БД? Разве не достаточно какого-нибудь фреймворка над РБД? Мой ответ — вполне.
Не всем подходит твой ответ.
Встречаются такие проекты, где стоимость отображения объектной модели приложения на RDBMS превышает разумные пределы.
Там первое требование — персистить сложную объектную модель в неизменном виде, чтобы потом на ее основе генерировать многочисленные трудоемкие отчеты.
Вот что еще пишет один из участников этого проекта:
My experience (9 years) is with GemStone/S. It is an object repository
*with* behavior. The query interface is the richest I have seen; it is
the full power of Smalltalk. I have also used RDBMS extensively (Oracle
and Sybase). I find them adequate for fairly static knowledge
management, but I would hate to have to try and make them work in an
environment that changes daily, like trading applications, for example.
Здравствуйте, Real 3L0, Вы писали: R3>Согласен, но после создания некоторой оболочки над БД (фреймворка) всё становится просто. Другой вопрос: объясни мне что такое наследование в понятии ООБД?
Оно имеет тот же самый смысл, что и в обычном ООП. R3>Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД.
Стоит. ООБД оперирует понятиями более высокого порядка, и потому сокращает объем ручной работы. Правда, современные ООБД по большей части вынуждают разработчика потратить сэкономленное время на попытки добиться приемлемой производительности. Но в идеале работа с ООБД будет намного комфортнее, чем с РБД.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
R3>>Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД. S>Стоит. ООБД оперирует понятиями более высокого порядка, и потому сокращает объем ручной работы.
Ладно, откинем производительность. Выходит так:
ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля.
Я правильно мыслю?
