Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Разумеется, если происходит интенсивное изменение объектов большим количеством клиентов, кэшу прийдется постоянно обновляться и тратить на это определенные ресурсы (меньшие, однако, чем в случае с РСУБД в такой же ситуации).

Давайте подробнее посмотрим, что будет иметь место при использовании FastObjects. Пусть есть трехзвенка, в которой присутствует несколько серверов приложений (для распределения нагрузки) и один сервер БД. Привожу фрагмент статьи о FastObjects JDO:

Многозвенная архитектура разработана специально для решения задач, связанных с доставкой больших объемов данных очень большому числу пользователей. В этом случае сервер базы данных, как правило, обрабатывает запросы от некоторого четко контролируемого количества серверов приложений. В свою очередь, каждый сервер приложений обрабатывает запросы множества клиентов. С точки зрения сервера базы данных, сами сервера приложений и являются источниками запросов и потребителями выдаваемых по этим запросам данных. Такой иерархический подход к распространению данных позволяет увеличить количество возможных клиентских соединений с базой данных FastObjects. Однако он сам по себе не увеличивает возможности FastObjects по обработке большего количества запросов к базе.
Чтобы сократить количество запросов, перенаправляемых серверу базы данных от серверов приложений, сами сервера приложений должны использовать некоторые механизмы оптимизации их коммуникационного взаимодействия с сервером базы данных. Одна из возможных стратегий состоит в кэшировании данных на сервере приложений вместо типового для клиент/серверных архитектур кэширования на стороне клиента. Такая стратегия может быть эффективной в тех случаях, когда определенное количество клиентов, взаимодействующих с сервером приложений, часто запрашивает одни и те же данные. При использовании FastObjects кэширование на сервере приложений обеспечивается с помощью FastObjects Active Java Cache.
Active Java Cache реализует на стороне сервера приложений механизм, минимизирующий число запросов к серверу базы данных FastObjects в тех приложениях, где основной объем трафика сервера базы данных порождается только чтением. Считанные объекты попадают в локальный кэш сервера приложений. Используя его, сервер приложений может выдать требуемый объект без его повторного считывания из сервера базы данных. Таким образом, для часто запрашиваемых объектов общий трафик сервера базы данных существенно сокращается.
Кэш особенно эффективен при большом объеме считываемых объектов. В то же время, при кэшировании должна обеспечиваться и возможность для эпизодического редактирования объектов, в т.ч. и тех, которые в это время находятся в одном или нескольких кэшах. Важнейшим компонентом FastObjects Active Java Cache является сервис блокировок, который кэширует блокировки по чтению, выставляемые конечными клиентами. Это также уменьшает трафик сервера базы данных, поскольку позволяет кэшу сервера приложений самостоятельно (без дополнительного взаимодействия с сервером базы данных) разрешать блокировки по чтению на объекты при запросах от других клиентов. Когда на сервер базы данных поступает запрос на блокировку по записи, сервис блокировок получает соответствующее уведомление и может быть сконфигурирован так, чтобы снимать все блокировки по чтению, наложенные конечными клиентами. Так что заботиться о содержимом кэша необходимости нет.


Добавлю также, что сам упомянутый выше сервис блокировок можно даже вынести на отдельный сервер при наличии такого желания.
22 фев 05, 15:56    [1338707]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
автор
Так вот, когда вы работаете с реляционной БД, то объем кэшируемой информации будет больше, чем в случае с объектной, т.е. оперативная память исчерпается быстрее. Я ведь не зря указал 1-10 Гб. И я вовсе не имел ввиду, что все 1-10 Гб обязательно попадут в кэш. На практике кэша размером 256 Мб (будь это кэш сервера приложений или кэш клиента имеющего доступ к серверу БД через локальную сеть) вполне может хватить для обслуживания 10 Гб объектной базы (т.е. с вероятностью 90% задачи будут выполняться без обращения к серверу БД). При обычном раскладе РСУБД для такой же задачи потребует гораздо больше места в кэше


Откуда взялась цифра 90%? Что это за вероятность, как вы ее считали?


Вы неправильно меня поняли. Я просто пояснил, что я понимаю под словами "хватать для обслуживания базы". В моей трактовке этому соответствует случай, когда для выполнения типового запроса с вероятностью 90% все необходимые данные можно найти в кэше и обращаться за ними на сервер БД не нужно. Соотвественно, сама цифра 90% здесь взялась как некое опорное значение, которое мне показалось вполне удобным. И к собственно подсчетам этой вероятности в каждом конкретном случае все это не имеет никакого отношения.
22 фев 05, 16:06    [1338731]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Алексей, насчет кеша на уровне сервера приложений (3-х звенка) - все это актуально и логично также и для РСУБД. Собственно, данный подход позволяет кешировать данные и из плоских файлов, и с РСУБД, и с ООСУБД. Но отношения к сравнению РСУБД <> ООСУБД не имеет.

Кэш особенно эффективен при большом объеме считываемых объектов. В то же время, при кэшировании должна обеспечиваться и возможность для эпизодического редактирования объектов, в т.ч. и тех, которые в это время находятся в одном или нескольких кэшах. Важнейшим компонентом FastObjects Active Java Cache является сервис блокировок, который кэширует блокировки по чтению, выставляемые конечными клиентами. Это также уменьшает трафик сервера базы данных, поскольку позволяет кэшу сервера приложений самостоятельно (без дополнительного взаимодействия с сервером базы данных) разрешать блокировки по чтению на объекты при запросах от других клиентов. Когда на сервер базы данных поступает запрос на блокировку по записи, сервис блокировок получает соответствующее уведомление и может быть сконфигурирован так, чтобы снимать все блокировки по чтению, наложенные конечными клиентами. Так что заботиться о содержимом кэша необходимости нет.

В РСУБД уже есть встроенный диспетчер блокировок. И не нужно ставить отдельный сервис, который будет общаться с серверами приложений, сервером СУБД и разруливать между ними блокировки.
Помимо этого, если у ООСУБД попадает в сферу телекома, встраиваемых решений (и проч.), то это это сферы с большим потоком информации на изменение данных (например, тот же биллинг) и там отнюдь не эпизодическое изменение данных. Как будут синхронизироваться кеши на разных серверах приложений (!) с содержимым БД. Хочется услышать обоснование вот этой фразы
Разумеется, если происходит интенсивное изменение объектов большим количеством клиентов, кэшу прийдется постоянно обновляться и тратить на это определенные ресурсы (меньшие, однако, чем в случае с РСУБД в такой же ситуации).
22 фев 05, 16:33    [1338822]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
Алексей, насчет кеша на уровне сервера приложений (3-х звенка) - все это актуально и логично также и для РСУБД. Собственно, данный подход позволяет кешировать данные и из плоских файлов, и с РСУБД, и с ООСУБД. Но отношения к сравнению РСУБД <> ООСУБД не имеет.


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

AAron

В РСУБД уже есть встроенный диспетчер блокировок. И не нужно ставить отдельный сервис, который будет общаться с серверами приложений, сервером СУБД и разруливать между ними блокировки.


В ООСУБД FastObjects отдельный сервис ставить можно, но не обязательно.
А вот в обработке блокировок объектными и реляционными системами есть серьезные различия (которые могут проявиться при использовании СУБД в ряде вполне конкретных сфер). И этот вопрос в общем то стоит разобрать отдельно. Предлагаю рассмотреть случай обновления сложного объекта, различные атрибуты которого разбросаны по нескольким таблицам.


AAron

Помимо этого, если у ООСУБД попадает в сферу телекома, встраиваемых решений (и проч.), то это это сферы с большим потоком информации на изменение данных (например, тот же биллинг) и там отнюдь не эпизодическое изменение данных. Как будут синхронизироваться кеши на разных серверах приложений (!) с содержимым БД.


О биллинге уже была некоторая дискуссия с ЛП. Почитайте.

AAron

Хочется услышать обоснование вот этой фразы
Разумеется, если происходит интенсивное изменение объектов большим количеством клиентов, кэшу прийдется постоянно обновляться и тратить на это определенные ресурсы (меньшие, однако, чем в случае с РСУБД в такой же ситуации).



Все просто. Когда вы обращаетесь к хранимому объекту (или набору хранимых объектов), сначала приложение пытается отыскать все эти объекты в своем локальном кэше (кэше сервера приложений, если речь идет о приложении, запущенном на сервере приложений), если их там нет или они устарели (были изменены кем-то другим), то происходит обновление (пакетное обновление) этих объектов путем загрузки новых данных с сервера БД (из его кэша или, если объектов нет и там, из хранилища данных). Ключевым здесь является "новых данных". Т.е. обновляться будут только те объекты, которые были изменены. Логика работы кэша в реляционных системах иная и ориентирована на кэширование страниц, которые могут содержать массу информации не подвергшейся изменению, но обновляться будут все-равно целиком. Вот что я имею ввиду, когда говорю о меньших затратах на обновление кэша при кэшировании на уровне объектов. Разумеется это справедливо только для систем, которые и обрабатывают информацию пообъектно.
22 фев 05, 17:09    [1338949]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Я уж извиняюсь, но без сравнения с РСУБД никак нельзя.
Почему? Ну а как же, надо же с чем-то сравнивать, иначе как-то нехорошо получится: первый парень на деревне, а в деревне один дом :))

автор
Так вот, когда вы работаете с реляционной БД, то объем кэшируемой информации будет больше, чем в случае с объектной, т.е. оперативная память исчерпается быстрее. Я ведь не зря указал 1-10 Гб. И я вовсе не имел ввиду, что все 1-10 Гб обязательно попадут в кэш. На практике кэша размером 256 Мб (будь это кэш сервера приложений или кэш клиента имеющего доступ к серверу БД через локальную сеть) вполне может хватить для обслуживания 10 Гб объектной базы (т.е. с вероятностью 90% задачи будут выполняться без обращения к серверу БД). При обычном раскладе РСУБД для такой же задачи потребует гораздо больше места в кэше

Что-то я все же не пойму:
Значит, для того, чтобы запихать 1Гб в память используя ООСУБД, нужно 256 Мб, а чтобы запихать столько же, но используя РСУБД, столько памяти ну никак не хватит. Однако странно!

автор
Я просто пояснил, что я понимаю под словами "хватать для обслуживания базы". В моей трактовке этому соответствует случай, когда для выполнения типового запроса с вероятностью 90% все необходимые данные можно найти в кэше и обращаться за ними на сервер БД не нужно.

Это полностью справедливо и для РСУБД.
И для любого другого среднего звена - при чем тут ООСУБД?

автор
Чтобы сократить количество запросов, перенаправляемых серверу базы данных от серверов приложений, сами сервера приложений должны использовать некоторые механизмы оптимизации их коммуникационного взаимодействия с сервером базы данных. Одна из возможных стратегий состоит в кэшировании данных на сервере приложений вместо типового для клиент/серверных архитектур кэширования на стороне клиента. Такая стратегия может быть эффективной в тех случаях, когда определенное количество клиентов, взаимодействующих с сервером приложений, часто запрашивает одни и те же данные. При использовании FastObjects кэширование на сервере приложений обеспечивается с помощью FastObjects Active Java Cache.

Вот там выделено жирным - это полностью справедливо и для РСУБД. Часто используемые данные лежат в кэше и достать их оттуда не составляет никаких затрат и времени.
В случае же со средним звеном, вам еще нужно проверять, не изменились ли они. Причем в обязательном порядке - если серьезно относиться к разработке.
И справедливо это все и для любого другого среднего звена - при чем тут ООСУБД?

-- Tygra's --
22 фев 05, 17:26    [1339007]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
мне кажется, что вы путаете (или постоянно подменяете) понятия кеша СУБД и локального кеша сервера приложений (application server).
Все просто. Когда вы обращаетесь к хранимому объекту (или набору хранимых объектов), сначала приложение пытается отыскать все эти объекты в своем локальном кэше (кэше сервера приложений, если речь идет о приложении, запущенном на сервере приложений), если их там нет или они устарели (были изменены кем-то другим), то происходит обновление (пакетное обновление) этих объектов путем загрузки новых данных с сервера БД (из его кэша или, если объектов нет и там, из хранилища данных). Ключевым здесь является "новых данных". Т.е. обновляться будут только те объекты, которые были изменены
Абсолютно все сказанное относится в равной степени как к РСУБД, так и ООСУБД. Это достаточно общий подход к проектированию кеша на уровне сервера приложений: "если есть, отдаем, если нет - загружаем и отдаем". Разницы никакой нет.
Логика работы кэша в реляционных системах иная и ориентирована на кэширование страниц, которые могут содержать массу информации не подвергшейся изменению, но обновляться будут все-равно целиком.

Но задача ведь кеша максимально быстро отдать информацию. Причем тут измененная или не измененная информация?.

Кстати, размер страницы как правило согласуется с размером блока на диске, что значительно увеличивает скорость загрузки страниц. В то же время, объект скорее всего "размазан" по диску в силу его специфики. А значит и при чтении его с диска на ООСУБД "просядет" дисковых операциях . Что уж говорить о записи, ведь в любом случае ООСУБД должна держать синхронными данные в кеше СУБД и на диске (иначе проблема с отказоустойчивостью).

Итак, если мы сравниваем кеши ОО и Р СУБД, то надо отказаться от попутного сравнения кеша application server'a (среднего звена) и РСУБД, т.к это некорректно. А пока, утверждение, что кеш ООСУБД работает быстрее, чем у РСУБД - голословно.

PS. сервер приложений, кстати, может также как и РСУБД оперировать множествами, а не объектами. Имейте это ввиду.
22 фев 05, 17:37    [1339073]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
vybegallo
Guest
Alexey Rovdo

Все просто. Когда вы обращаетесь к хранимому объекту (или набору хранимых объектов), сначала приложение пытается отыскать все эти объекты в своем локальном кэше (кэше сервера приложений, если речь идет о приложении, запущенном на сервере приложений), если их там нет или они устарели (были изменены кем-то другим), то происходит обновление (пакетное обновление) этих объектов путем загрузки новых данных с сервера БД (из его кэша или, если объектов нет и там, из хранилища данных). Ключевым здесь является "новых данных". Т.е. обновляться будут только те объекты, которые были изменены. Логика работы кэша в реляционных системах иная и ориентирована на кэширование страниц, которые могут содержать массу информации не подвергшейся изменению, но обновляться будут все-равно целиком. Вот что я имею ввиду, когда говорю о меньших затратах на обновление кэша при кэшировании на уровне объектов. Разумеется это справедливо только для систем, которые и обрабатывают информацию пообъектно.


И как клиент узнает, что его данные устарели ? Путем опроса сервера по TCP? Вы представляете, во сколько раз этот вариант медленнее по сравнению с РСУБД, которая просто проверяет флажок буфера в памяти, чтобы определить, изменялась ли данная страница или нет ?
22 фев 05, 17:46    [1339110]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron

мне кажется, что вы путаете (или постоянно подменяете) понятия кеша СУБД и локального кеша сервера приложений (application server).


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

AAron

Но задача ведь кеша максимально быстро отдать информацию. Причем тут измененная или не измененная информация?


Но что кэш сервера РСУБД должен отдать в кэш сервера приложений? И по какому принципу объявлять данные в кэше сервера приложений измененными (требующими обновления)? Мы либо должны зеркально отображать кэш сервера БД на кэш сервера приложений, либо вводить промежуточные механизмы, которые будут следить за состоянием объектов в кэше сервера приложений и одновременно как-то отслеживать моменты изменения именно этих объектов в самой БД. Распространенные средства O/R-мэппинга решают эту проблему, но за счет введения в модель данных дополнительных полей (и таблиц).

AAron

Кстати, размер страницы как правило согласуется с размером блока на диске, что значительно увеличивает скорость загрузки страниц. В то же время, объект скорее всего "размазан" по диску в силу его специфики. А значит и при чтении его с диска на ООСУБД "просядет" дисковых операциях . Что уж говорить о записи, ведь в любом случае ООСУБД должна держать синхронными данные в кеше СУБД и на диске (иначе проблема с отказоустойчивостью).


Тут вы ошибаетесь. Каждый объект в ООСУБД хранится в едином кластере и не размазывается по диску. А вот при использовании O/R-мэппинга сложные объекты, размазанные по нескольким таблицам, как раз таки и оказываются размазанными по диску и их чтение/запись происходит значительно медленнее.

Ну а вопросы отказоустойчивости решаются в ООСУБД и РСУБД примерно одинаково.

AAron

PS. сервер приложений, кстати, может также как и РСУБД оперировать множествами, а не объектами. Имейте это ввиду.


Может. И именно это я и имею ввиду, когда дописываю:
Разумеется это справедливо только для систем, которые и обрабатывают информацию пообъектно.
22 фев 05, 18:01    [1339172]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
vybegallo

И как клиент узнает, что его данные устарели ? Путем опроса сервера по TCP? Вы представляете, во сколько раз этот вариант медленнее по сравнению с РСУБД, которая просто проверяет флажок буфера в памяти, чтобы определить, изменялась ли данная страница или нет ?


Вы что-то не так трактуете. Флажок буфера где находится (в какой памяти) и в какой момент он изменяется? И как клиент получает доступ к этому флажку?
Поясните, чтобы я мог квалифицированно ответить.
22 фев 05, 18:05    [1339188]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
vybegallo
Guest
Alexey Rovdo
vybegallo

И как клиент узнает, что его данные устарели ? Путем опроса сервера по TCP? Вы представляете, во сколько раз этот вариант медленнее по сравнению с РСУБД, которая просто проверяет флажок буфера в памяти, чтобы определить, изменялась ли данная страница или нет ?


Вы что-то не так трактуете. Флажок буфера где находится (в какой памяти) и в какой момент он изменяется? И как клиент получает доступ к этому флажку?
Поясните, чтобы я мог квалифицированно ответить.


Это вы "что-то неправильно трактуете". То, что вы называете "кэш на клиенте", у нормальных людей :-) называется переменными. Выполнили запрос, результаты сохранили в переменных. И пользуемся, пока нас не волнует, что результаты могли поменяться. Если нас это волнует - то есть несколько вариантов, от блокировок до обработки исключений. А как поступает FastObject ? Всегда проверяет актуальность данных (даже если пользователя устаривают неактуальные), или проверку надо специально программировать ?
22 фев 05, 18:18    [1339236]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Тузик
Guest
"Это вы "что-то неправильно трактуете". То, что вы называете "кэш на клиенте", у нормальных людей :-) называется переменными"

Не смешите - кэш на стороне клиента "изобретение" достаточно древнее... И с технологией БД не связан никак!
22 фев 05, 18:36    [1339269]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
автор
....Каждый объект в ООСУБД хранится в едином кластере и не размазывается по диску. А вот при использовании O/R-мэппинга сложные объекты, размазанные по нескольким таблицам....


Вот как то мне глубоко непонятно, что имеет виду эта фраза. То есть чисто внешне - да, кажеться, что так оно и есть. Однако если вдуматься..... Вспомним эту структуру. Что я вижу? Я вижу связанные однонаправленными ссылками простейшие объекты, состояшие из нескольких полей. То есть сложный объект есть совокупность или если хотите суперпозиция элементарный объектов. Структура каждого такого элементарного объекта в общем то не сложней, чем структура аналогичной записи таблицы SQL-сервера. То есть этот объект конечно храниться в кластере (кста! точно так же в кластере будет храниться SQL -запись). Но ведь входящие в его структуру ссылки указывают на другой элементарный объект, который скорее всего храниться в дугом кластере....и т.д. А что касается оформленных в виде однонаправленных ссылок связей между объектами - то это мы вчера прошли.

Кстати - что такое "двунаправдленная ссылка"? Это опять что-то оченьтруднопредставляемое. Насколько я понимаю, речь идет о том, что в ODMG называется "back reference" - но это не двунаправленная ссылка а пара однонаправленных(навстречу друг другу) ссылок, причем каждую из них надо определять отдельно. Кста - эта идея мне вообще в принципе не нравиться, потому что я должен определять в общем-то одну связь в программе двух местах (а вдруг я чё-нить забуду?). Вот было бы так - одну ссылку определил, и получай по ней данные в обе стороны :) - это было бы круто
22 фев 05, 18:39    [1339272]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vybegallo
Guest
Тузик
"Это вы "что-то неправильно трактуете". То, что вы называете "кэш на клиенте", у нормальных людей :-) называется переменными"

Не смешите - кэш на стороне клиента "изобретение" достаточно древнее... И с технологией БД не связан никак!


И чем же "кэш на стороне клиента" отличается от сохранения данных в переменных (массивах, объектах, структурах) и их повторного использования ?
22 фев 05, 18:57    [1339306]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
От кеша мы конечно уже отклонились, но в целом пока я не увидел преимуществ у ООСУБД, а вот к хранению данных вернулись
Каждый объект в ООСУБД хранится в едином кластере и не размазывается по диску. А вот при использовании O/R-мэппинга сложные объекты, размазанные по нескольким таблицам
Это может быть некий логический кластер. Я же говорю о физической реализации. Например, для блок данных, который вычитывается с диска - 64К, что кратно размеру страницы - 8К (SQL Server), для Oracle, DB2 - это размер меняется. Таким образом вся страница (а может даже и несколько подряд идущих) вычитывается за одно чтение. Рассмотрим объект, который "размазан" или состоит из нескольких. Во-первых его размер некратен размеру блока данных в общем случае и может как превышать, так и быть существенно меньше него. Во-вторых, сложный объект может как "содержать" в себе более простые, так и хранить ссылки на них. В зависимости от способа объект будет по разному храниться в памяти (а значит и на диске), что также ведет к увеличению фрагментации файла данных, и, следовательно, к увеличению стоимости операций чтения и записи объектов.
22 фев 05, 19:12    [1339328]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
Каждый объект в ООСУБД хранится в едином кластере и не размазывается по диску. А вот при использовании O/R-мэппинга сложные объекты, размазанные по нескольким таблицам
Это может быть некий логический кластер. Я же говорю о физической реализации. Например, для блок данных, который вычитывается с диска - 64К, что кратно размеру страницы - 8К (SQL Server), для Oracle, DB2 - это размер меняется. Таким образом вся страница (а может даже и несколько подряд идущих) вычитывается за одно чтение. Рассмотрим объект, который "размазан" или состоит из нескольких. Во-первых его размер некратен размеру блока данных в общем случае и может как превышать, так и быть существенно меньше него. Во-вторых, сложный объект может как "содержать" в себе более простые, так и хранить ссылки на них. В зависимости от способа объект будет по разному храниться в памяти (а значит и на диске), что также ведет к увеличению фрагментации файла данных, и, следовательно, к увеличению стоимости операций чтения и записи объектов.


Нет, в ООСУБД это именно физический кластер. Причем, если в FO на следующем уровне кластеризации все объекты одного класса размещаются в одном кластере (друго класса, соответственно, в другом и т.д.), то VDS мы уже можем группировать объекты именно таким образом, чтобы размещать в одном кластере связанные объекты разных классов и затем разделять эти кластеры по партишенам (т.е. VDS более гибок в этом отношении). Физическое чтение данных с диска в ООСУБД разумеется также происходит в соответствии с размерами блоков файловой системы. Что же касается размера самого объекта, то ведь ООСУБД заранее знает его размер еще до начала чтения, поскольку знает класс того объекта, который она хочет считать, и следовательно, производит чтение нужного объема данных (страниц/блоков).
22 фев 05, 19:32    [1339369]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...

Вот как то мне глубоко непонятно, что имеет виду эта фраза. То есть чисто внешне - да, кажеться, что так оно и есть. Однако если вдуматься..... Вспомним эту структуру. Что я вижу? Я вижу связанные однонаправленными ссылками простейшие объекты, состояшие из нескольких полей.


В этой структуре нет по настоящему сложных объектов. В ней действительно только связанные ссылками простейшие объекты. Кстати не всюду они однозначно однонаправленные. Так классы Item и Ticket имеют встречные ссылки, что в общем то является излишним и не есть хорошо, но несколько ускоряет работу и упрощает написание запросов для этой модели.


Мимо пробегал...

То есть сложный объект есть совокупность или если хотите суперпозиция элементарный объектов. Структура каждого такого элементарного объекта в общем то не сложней, чем структура аналогичной записи таблицы SQL-сервера. То есть этот объект конечно храниться в кластере (кста! точно так же в кластере будет храниться SQL -запись).


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

Мимо пробегал...

Кстати - что такое "двунаправдленная ссылка"? Это опять что-то оченьтруднопредставляемое. Насколько я понимаю, речь идет о том, что в ODMG называется "back reference" - но это не двунаправленная ссылка а пара однонаправленных(навстречу друг другу) ссылок, причем каждую из них надо определять отдельно. Кста - эта идея мне вообще в принципе не нравиться, потому что я должен определять в общем-то одну связь в программе двух местах (а вдруг я чё-нить забуду?). Вот было бы так - одну ссылку определил, и получай по ней данные в обе стороны :) - это было бы круто


В VDS двунаправленная ссылка - это просто предопределенный класс объектов, для которого поддерживается ряд сервисных функций (отслеживание целостности, двусторонняя навигация, ... ) и определять ее можно в одном месте, впрочем использовать двунаправленные ссылки вовсе не обязательно. Так что все именно так, как вы и пишете в конце.
22 фев 05, 19:49    [1339403]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
vybegallo

И чем же "кэш на стороне клиента" отличается от сохранения данных в переменных (массивах, объектах, структурах) и их повторного использования ?


Да тем, что при помещении такого объекта в кэш внутри транзакции, на сервере на него выставляется блокировка по чтению (по-умолчанию). И она там будет стоять либо до окончания транзакции, либо до тех пор, пока приложение явно эту блокировку не снимет. А когда снимет, а потом захочет воспользоваться этим объектом повторно в новой транзакции (т.е. с гарантией, что это последняя версия данных, а не локальная копия неизвестной давности), фоновый механизм управления кэшем сначала запросит сервер о том, изменялся ли этот объект и в зависимости от ответа сервера, либо считает последнюю версию данных, либо воспользуется уже имеющейся локальной копией. Похожим образом будут работать и блокировки по записи.
22 фев 05, 19:56    [1339415]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Тузик
Guest
vybegallo

И чем же "кэш на стороне клиента" отличается от сохранения данных в переменных (массивах, объектах, структурах) и их повторного использования ?


Ну, уважаемый... Вам даже это надо объяснять? Основное отличие в том, что он управляется не приложением, а "слоем доступа"...
Ну а ежели Вы в ГЛОБАЛЬНОМ МАСШТАБЕ, то ест-но и ядро ОС, и драйвер и прочю - сиречь ПРОГРАММЫ со своими переменными, массивами, проч. :-)))
22 фев 05, 19:58    [1339417]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Далее, когда мы считываем сложный объект, состоящий из набора элементарных объектов (записей), то обращаемся ко множеству разных таблиц и влияем на реляционный кэш (на мой взгляд) совершенно непонятным образом. С ООСУБД все просто - мы можем выбрать всю группу связанных объектов за одно обращение к серверу и наполнить/обновить кэш именно теми объектами (и больше никакими другими), которые мы и выбирали.

Так кто мешает использовать несколько выходных рекордсетов и получать все данные за одно обращение к СУБД?
Вы опять переключили контекст с обсуждения физического чтения РСУБД с диска, на логические чтения приложением из кеша ООСУБД. Вы можете внятно изложить, как хранятся сложные объекты на диске и как они вычитываются/сохраняются?

Ладно, за сим, я прекращаю обсуждение данного вопроса. Возможно по ходу топика у меня возникнут другие, тогда и поучаствую.
22 фев 05, 19:59    [1339418]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Тузик

Не смешите - кэш на стороне клиента "изобретение" достаточно древнее... И с технологией БД не связан никак!


Так то оно так, но эффективность такого кэша и быстродействие всей цепочки "Приложение-БД" при объектной обработке данных в приложении будет сильно зависеть именно от технологии самого сервера БД.
22 фев 05, 19:59    [1339419]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Тузик
Guest
Alexey Rovdo

Так то оно так, но эффективность такого кэша и быстродействие всей цепочки "Приложение-БД" при объектной обработке данных в приложении будет сильно зависеть именно от технологии самого сервера БД.


Про быстродействие всей цепочки - не знаю. Но эффективность кэша зависит от его внутренней огранизации, выбранных алгоритмов свопинга и т.д., но никаким образом не от самих кэшируемых данных.
Если говорить о кэше на стороне клиента - то туда попадают только результаты запроса к БД и ничнго лишнего! А уж как эти данные структуированы - кэшу похрену...
22 фев 05, 20:36    [1339461]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alexey Rovdo

Практика Versant показывает, что многие закзчики пришли к ООСУБД именно через тестирование на конкретных примерах, имеющих непосредственное отношение к их предметной области. Тут конечно можно привести умопомрачительные цифры (в 2, 5, 10 ... раз быстрее), но это конечно будут только пресс-релизы, их реальную подоплеку здесь полностью раскрыть нереально.

Тут на форуме некоторые парни получали умопомрачительные цифры (в 2, 5, 10 ... раз быстрее), сравнивая Оракл с Ораклом. Причина - не качественное сравнение. Я однажды, тоже нарвался на то, что якобы 9 Оракл медленне 8 при сравнение запросов к одной и той же табле. Даже на форуме спрашивал. А потом обнружил, что по блокам таблы не равны - разный процент заполнения у них указан, хотя записи одни и те же. Поэтому и сомневаюсь все еще в том, кто и как сравнивал. Встречался и ситуацией когда парни две недели не могли ничего сделать с БД, которая 15 минут выполняла запрос после того, как там стало 30 млн записей. На деле удалось довести до 2 секунд. Я еще раз подчеткиваю, что если речь о сравнении производительности, то надо сравнивать где и РМД и ООМД хорошо подходят как модели. В противном случае есть кое-что похуже производительности для ИС.



Alexey Rovdo

Но все такие ухищрения (некоторые из которых я бы отнес уже к объектной функциональности, та самая буквочка "О" в термине ОРСУБД)


То что я приводил нельзя отнести к ухищрениям, тем более к ОРСУБД, поскольку это все никак не нарушают РМД. Это физические аспекты реализации. Разные алгоритмы - это естественно. В таком случае в компах много ухищрений - например, Кеш память. ОРСУБД - это ответ не на производительность, а на не адкватность РМД для некоторых спец приложений. Т.е. там уже дело не в производительности. Наоборот, из-за вопросов призводитнельности Объектные возможности пока вызывают некоторыеопасения - будет ли к ними можно применять то, что Вы назвали ухищрениями?

Alexey Rovdo

Их ведь действительно в некоторых случаях может оказаться 100. И как с этим работать ? Общепринятая позиция РСУБД-ков - это такая неправильная модель, в которой может появиться 100 JOIN-ов, т.е. надо делать "правильную" модель и все будет Ок. На практике это приводит к банальной необходимости упрощать исходную модель предметной области вводя в нее некоторые ограничения, которые действительно часто позволяют добиться резкого сокращения числа таблиц (и количества JOIN-ов в запросах).

Вот для этой правильной модели ОРСУБД предназначено, чтобы не упрощать. Такое упрощение уже можно считать ухищрениями. Но все равно с производительностью и со 100 таблами может и удастся выкрутиться. Работать может и будет быстро. Но модель плоховатая. Ее плохо разрабатывать, сопровождать, в том числе писать запроосы. Т.е. процесс получения нужной инфы усложняется, хотя и не обязательно из-за производительности.
22 фев 05, 20:53    [1339479]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vybegallo
Guest
Alexey Rovdo
vybegallo

И чем же "кэш на стороне клиента" отличается от сохранения данных в переменных (массивах, объектах, структурах) и их повторного использования ?


Да тем, что при помещении такого объекта в кэш внутри транзакции, на сервере на него выставляется блокировка по чтению (по-умолчанию). И она там будет стоять либо до окончания транзакции, либо до тех пор, пока приложение явно эту блокировку не снимет.


И чем это отличается от repeatable read ?

Alexey Rovdo

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


1. Есть ли возможность не опрашивать сервер, если актуальность данных не интересует (dirty read) ?
2. При желании данную возможность можно реализовать самому - завести таблицу с идентификаторами объектов и их текущими версиями и проверять на обновление.
3. Не вижу, почему данная фича не может быть реализована в РСУБД. Почему ее никто пока не реализовал - другой вопрос, Вероятно, потому что и без нее неплохо работает. В отличие от ООСУБД, которая работать без нее не сможет.
22 фев 05, 22:07    [1339537]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Но ведь это вы написали:

А нет бы, к примеру, добавьте добавить пару миллионов записей в таблицы, многое прояснится. Только не используйте МССКЛ, возьмите оракл или ДБ2. Там хеш индексы присутсвуют в явном виде.

Я ведь уже писал вам что меня вполне устроит, если вы согласитесь со мной хотя бы по одной системе для одного конкретного случая (т.е. мои аргументы будут достаточно убедительны). Пока вы все пытаетесь свести к тому, что "а вот в другой СУБД это может быть иначе" и не согласились со мной ни в чем конкретном.


Нет, это Ваша трактовка моих слов. Я же говорил о том (многократно в явной форме повторял и повторяю), что Вы ДЕЛАЕТЕ ЗАВЕДОМО БЕССМЫСЛЕННУЮ РАБОТУ. ТАК НИЧЕГО ДОКАЗАТЬ НЕВОЗМОЖНО. Прочитайте последнее предложение раза 3. Мой пример с ораклом и ДБ2 не приглашение к работе, а лишь иллюстрация этой бессмысленности.

c127> Следующий вопрос. Предположим, что Вы докажете что ООБД в данной ситуации ищут быстрее (или что то же, что ВСЕ РСУБД ищут медленнее). Тогда Вам нужно будет доказать что именно эта разница критична в востребованном (а не искуственно придуманном) классе приложений.

>Ну если вы согласны со мной по первому пункту, я готов перейти к рассмотрению второго - показать, ....


Слушайте, Вы издеваетесь или прото тупой? Я сказал: "Предположим, что Вы докажете..." Причем такое перекручивание моих слов повторяется уже в четвертый или пятый раз. Еще раз повторяю. Если Вам удастся доказать (если, а не уже доказали), то это все равно ни к чему не приведет. Но превосходство в скорости еще не доказано, более того, я подозреваю, что будет как раз проигрыш.

>Что же касается ОО-модели, то я решил рассмотреть преимущества/недостатки ОО-подхода на вполне конкретной задаче (как я и обещал выше, так что ждите), но без использования ООСУБД (на базе общераспространенной РСУБД). Любопытно, что вы скажете тогда?

Зачем ждать, я Вам и сейчас скажу. Это очередная глупость. Мы все-таки обсуждаем не просто ОО подход, а ОО подход в хранении данных. У Вас есть ООБД, называетс фастобджектс, которую Вы пропагандируете и которая как раз этим и занимается. Зачем извращаться и строить реляционную схему? Пойдите по простому и логичному пути: возьмите фастобджектс или любую другую объектную и покажите превосходство на примере ООБД. Не нужно сюда приплетать РСУБД.

Почему-то Вы всеми силами уклоняетесь от чистого эксперимента. Я подозреваю, что это из-за того в случае правильного сравнения при Вашей неудаче (а я в ней почти не сомневаюсь, да и Вы по-видимому тоже), Вам будет очень трудно найти аргументы в свою пользу и вопрос будет закрыт. А так всегда можно сказать, ну так это же была РСУБД, а вот если бы мы изначально взяли ООСУБД то все бы летало. Так возьмите ООБД изначально.
23 фев 05, 03:25    [1339728]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Тузик
Alexey Rovdo

Так то оно так, но эффективность такого кэша и быстродействие всей цепочки "Приложение-БД" при объектной обработке данных в приложении будет сильно зависеть именно от технологии самого сервера БД.


Про быстродействие всей цепочки - не знаю. Но эффективность кэша зависит от его внутренней огранизации, выбранных алгоритмов свопинга и т.д., но никаким образом не от самих кэшируемых данных.
Если говорить о кэше на стороне клиента - то туда попадают только результаты запроса к БД и ничнго лишнего! А уж как эти данные структуированы - кэшу похрену...


Но ведь мы говорим не о самих данных, а именно о внутренней организации. Кэш сервера РСУБД работает со страницами, а кэш сервера ООСУБД - с объектами. Если приложение также работает с объектами, то эффективность кэша РСУБД снизится, поскольку он постоянно будет кэшировать лишние данные, ненужные приложению и занимающие место в памяти. Именно поэтому я и писал, что для обслуживания 1-10 Гб объектной базы на практике может хватить кэша 256 Мб (разумеется цифра чисто умозрительная - все зависит от того, насколько различаются запрашиваемые клиентами данные), но при прочих равных в случае РСУБД кэш такого же размера сможет удовлетворить гораздо меньшее число запросов (при условии объектной обработки данных в клиентском приложении).
23 фев 05, 10:02    [1339803]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить