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

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
ROWID не рекомендуется использовать в приложениях (технически это ВОЗМОЖНО) по вполне понятным причинам. ОНИ МОГУТ ИЗМЕНИТЬСЯ. Например после экспорта/импорта. ЭТО ФИЗИЧЕСКИЙ АДРЕС. Приложение не должно использовать его, в противном случае, она будет очень сильно привязана к физике. Думаю, что эти рассуждения справедливы и для ООСУБД.


Но ООСУБД автоматически отслеживают и изменяют физический адрес во всех ссылках при перемещении самого объекта-назначения ссылки. На самом деле такое перемещение имеет место не так уж часто, как может показаться (тем более, что в архитектуру ООСУБД закладываются специальные механизмы, снижающие вероятность этого). Приложение же при работе с ООСУБД вообще имеет дело только с указателями (ссылками) на объекты в памяти (т.е. приложение однозначно предполагает, что все объекты уже находятся в оперативной памяти) - их выборку из БД в нужный момент драйвер соединения с сервером ООСУБД осуществляет автоматически в теневом режиме.
21 фев 05, 16:50    [1336171]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Фактически сказанное Вами означает ПОЛНЫЙ перерассчет всех ROWID после каких-то подвижек в базе. В Oracle эта проблема решается перестроением индексов, но найти и исправить все ROWID в ДАННЫХ нереально.
21 фев 05, 16:59    [1336210]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
Фактически сказанное Вами означает ПОЛНЫЙ перерассчет всех ROWID после каких-то подвижек в базе. В Oracle эта проблема решается перестроением индексов, но найти и исправить все ROWID в ДАННЫХ нереально.


1) Реально в ООСУБД.
2) В ООСУБД это, в принципе, делать не обязательно. Посмотрите на состав данных объектного идентификатора в FastObjects. Там есть и физический адрес и уникальный логический идентификатор (object's surrogate). Т.е. можно, например, при обращении по ссылке сначала искать объект по физическому адресу, если же по какой-то (редкой) причине объект переместился, то система должна находить его по уникальному идентификатору и исправлять саму использованную ссылку, помещая в нее новый правильный физический адрес (все эти действия система может выполнять автоматически без участия приложения).

Как поступает FastObjects я на самом деле точно не знаю (скорее всего по п.1). Но тут возникает главный вопрос. А с какой стати объекту в ООСУБД вообще менять свой физический адрес (расположение в файле БД)? В голову приходят только разнообразные административные мероприятия (типа дефрагментации и импорта/экспорта), но тогда и связанные с ними издержки много перекрывают издержки, порождаемые п.1 как таковым. Более сложный случай связан с изменением класса объекта. В этом случае в FO может понадобиться восстановление целостности ссылок с помощью самого приложения.
21 фев 05, 17:27    [1336313]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
автор
com.poet.jdo.Extents.setFilter( iter,
"WHERE this.day = \"01.01.2005\" and this.flight.startpoint.name = \"A\" " +
"and this.flight.endpoint.name = \"B\" " );


Мне это все больше и больше не нравится. :( Попытаюсь объяснить почему. Ссылки, насколько я понимаю, однонаправлены. А JOIN-ны работают....мммм... в обе стороны. То есть, выполняя кусок
this.flight.startpoint.name
система вынуждена просмотреть все объекты класса, что бы найти в них ссылки (и преобразовать их в какие-то дисковые смещения) на другие объекты, которые также содеражат ссылки (тут второй круг) - и никак иначе, потому что ссылки однонаправленны, потому что, вследствии однонаправленности ссылок, нельзя найти объекты которые ссылаються на объект, для атрибутов котрого задано это условие
name = \"A\" name = \"B\"
. А JOIN - он симметричный, что позволяет раскручивать цепочку связей начиная с условия и оканчивая результатом, что, вкупе с индексами, ИМХО даст меньший объем работ с диском.

Или я неправ?
21 фев 05, 17:28    [1336320]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...
автор
com.poet.jdo.Extents.setFilter( iter,
"WHERE this.day = \"01.01.2005\" and this.flight.startpoint.name = \"A\" " +
"and this.flight.endpoint.name = \"B\" " );


Мне это все больше и больше не нравится. :( Попытаюсь объяснить почему. Ссылки, насколько я понимаю, однонаправлены. А JOIN-ны работают....мммм... в обе стороны. То есть, выполняя кусок
this.flight.startpoint.name
система вынуждена просмотреть все объекты класса, что бы найти в них ссылки (и преобразовать их в какие-то дисковые смещения) на другие объекты, которые также содеражат ссылки (тут второй круг) - и никак иначе, потому что ссылки однонаправленны, потому что, вследствии однонаправленности ссылок, нельзя найти объекты которые ссылаються на объект, для атрибутов котрого задано это условие
name = \"A\" name = \"B\"
. А JOIN - он симметричный, что позволяет раскручивать цепочку связей начиная с условия и оканчивая результатом, что, вкупе с индексами, ИМХО даст меньший объем работ с диском.

Или я неправ?


В FO ссылки действительно однонаправленные (в VDS есть двунаправленные). Но в данном случае ваши рассуждения верны (частично по физике процесса, но не сами выводы) только в том случае, если в модели данных не определено соответствующего индекса, по которому должен происходить отбор нужных объектов без раскручивания всех ссылок. В этом смысле ссылки в общем то идентичны FOREIGN KEY в реляционных СУБД (посмотрите как будет без индексов работать запрос со множеством JOIN в любой РСУБД - там ведь тоже прийдется раскручивать цепочки записей из нескольких таблиц, причем искать нужную запись прийдется не по физическому, а по логическому указателю). Симметричность JOIN иногда действительно позволяет ускорить обработку запросов в РСУБД, начав с конца (выборка всех записей в крайней JOIN-таблице, удовлетворяющих критерию поиска). Решение принимает оптимизатор на основе статистики и существующих индексов. Но в ООСУБД аналогичный оптимизатор на основе аналогичной статистики и состава существующих индексов может принять ровно такое же решение (искать сначала объекты в классе City, удовлетворяющие условию поиска, а затем в классе Flight выбрать объекты, содержащие ссылки на уже найденные объекты класса City). Отличие лишь в том, что оптимизатор ООСУБД неизбежно должен учитывать, что поиск в обратном направлении будет происходить не по физическим адресам, а также как в РСУБД - по логическим идентификаторам объектов (что медленнее, т.е. в ООСУБД порядок обработки связанной цепочки объектов имеет значение для скорости обработки запроса, в отличие от симметричного JOIN в РСУБД).
21 фев 05, 17:57    [1336409]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
если в модели данных не определено соответствующего индекса

Опа!...индексы в модели данных?... Или Вы что-то не так назвали, или это не модель, а "смешались в кучу...."
21 фев 05, 19:12    [1336644]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
"если в модели данных не определено соответствующего индекса, по которому должен происходить отбор нужных объектов без раскручивания всех ссылок"

В этой фразе я, конечно, перебрал.
Имелось в виду практически то, что и написано ниже. Если оптимизатор решит, что это лучше, он может использовать существующие индексы вместо обращения по физическим адресам.
21 фев 05, 19:20    [1336659]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

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


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

Поэтому я и говорю, что можно просто проверять в каждом конкретном случае, что можно выжать из СУБД. В разных случаях могут получиться разные результаты. Т.е. говорить о преимуществах в производительности одного над другим на все случаи сложновато.
22 фев 05, 01:58    [1336955]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
2 Alexey Rovdo

>Я бы все-таки говорил о сравнении быстродействия JOIN-запросов в РСУБД(предполагающих некий поиск при их выполнении) с быстродействием непосредственной навигации в ООСУБД (в принципе тоже предполагающей некий поиск).

Ну и я о том же. Только в этом мало смысла.

>Пока остановились на том, что необходимо продолжить эксперименты на оракловой базе с большим объемом данных. Обязательно продолжим, а пока времени нет.

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

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

ИМХО это нереально. В который раз повторяю: проще попытаться продемонстрировать превосходство ОО модели на каком-то классе задач. В идеале - дать пример такой задачи.
22 фев 05, 02:18    [1336960]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Alexey Rovdo
Gluk (Kazan)
Фактически сказанное Вами означает ПОЛНЫЙ перерассчет всех ROWID после каких-то подвижек в базе. В Oracle эта проблема решается перестроением индексов, но найти и исправить все ROWID в ДАННЫХ нереально.


1) Реально в ООСУБД.


Это не столь важно. РСУБД имеет многое из того чего не имеет subj ;)
22 фев 05, 08:07    [1337055]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

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


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

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


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

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

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

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


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

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

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

>Пока остановились на том, что необходимо продолжить эксперименты на оракловой базе с большим объемом данных. Обязательно продолжим, а пока времени нет.

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



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

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

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

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

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

ИМХО это нереально. В который раз повторяю: проще попытаться продемонстрировать превосходство ОО модели на каком-то классе задач. В идеале - дать пример такой задачи.


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

Что же касается ОО-модели, то я решил рассмотреть преимущества/недостатки ОО-подхода на вполне конкретной задаче (как я и обещал выше, так что ждите), но без использования ООСУБД (на базе общераспространенной РСУБД). Любопытно, что вы скажете тогда? Именно в такой ситуации уже будет совершенно очевидно, что вся критика и все обсуждение касаются ООСУБД постольку-поскольку, а речь идет исключительно об ООП как таковом.
22 фев 05, 10:34    [1337431]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)

Это не столь важно. РСУБД имеет многое из того чего не имеет subj ;)


Без сомнения. Но не во всех задачах все это многое действительно востребовано.
22 фев 05, 10:36    [1337444]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Нууу без агрегирующих функций (и аналитики кстати) мне было-бы ОЧЕНЬ неуютно в любой задаче. А партиционирование в моей текущей задаче скажем просто ЖИЗНЕННО необходимо :)
22 фев 05, 10:43    [1337473]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Gluk (Kazan)
Нууу без агрегирующих функций (и аналитики кстати) мне было-бы ОЧЕНЬ неуютно в любой задаче. А партиционирование в моей текущей задаче скажем просто ЖИЗНЕННО необходимо :)


Все это есть в Versant Developer Suite.
FastObjects больше ориентирован на маленькие базы данных (1-10 Гб). Вот когда, например, сервер приложений имеет достаточно памяти, чтобы закэшировать практически всю базу (те объекты, к которым пользователи обращаются чаще всего), скорость будет просто феноменальная. А на базах порядка 10-100 Гб применение FastObjects достаточно ограничено (в т.ч. по названным вами причинам).
22 фев 05, 10:52    [1337501]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Вот когда, например, сервер приложений имеет достаточно памяти, чтобы закэшировать практически всю базу (те объекты, к которым пользователи обращаются чаще всего), скорость будет просто феноменальная.

Я вам больше скажу: когда сервер РСУБД имеет достаточно памяти, чтобы закэшировать в нее всю БД, то скорость будет просто третьей космической - и опять ООСУБД проиграют :)) Тогда смысл в ООСУБД опять пропадает?

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

-- Tygra's --
22 фев 05, 11:13    [1337591]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Я вам больше скажу: когда сервер РСУБД имеет достаточно памяти, чтобы закэшировать в нее всю БД, то скорость будет просто третьей космической - и опять ООСУБД проиграют :)) Тогда смысл в ООСУБД опять пропадает?

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


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

Ко всему прочему я это писал без всякого сравнения с РСУБД, а вы как обычно читаете между строк что-то типа "А вот на РСУБД этого неполучится ... ха-ха". Больное, однако, воображение.
22 фев 05, 11:27    [1337658]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Если БД целиком кешируется, эти различия НЕ ПРИНЦИПИАЛЬНЫ
22 фев 05, 11:48    [1337746]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
tygra
Member

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

Вы уже 20 страниц подряд пытаетесь сравнивать ОО и Р, что в другом контексте ваши высказывания почти не понимаются.

Ну а по поводу, чего быстрее.... Я лично не сравнивал, не знаю, может указатели С кривые окажутся, может еше чего... :))
Ну а из-за призрачной мечты (или надежды?) делать еще и третье звено!!! Когда хватит и двух! Это не очень рационально получается. А техника считай та же самая.

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

Откуда: Москва
Сообщений: 4324
просто по приколу - когда база располагается в памяти :).
Я делал эксперимент - создавал виртуальный диск на 2ГБ и располагал базу на этом диске. А потом запускал апп-сервер. Так вот на типовых операциях с БД скорость в на порядок больше, что в общем-то и неудивительно. Общий прирост производительности системы был 3-4 кратным.
А вы говорите - закешировать БД в памяти. Тут просто файлы в память положить, уже значительный прирост будет.
22 фев 05, 12:53    [1338052]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
AAron
просто по приколу - когда база располагается в памяти :).
Я делал эксперимент - создавал виртуальный диск на 2ГБ и располагал базу на этом диске. А потом запускал апп-сервер. Так вот на типовых операциях с БД скорость в на порядок больше, что в общем-то и неудивительно. Общий прирост производительности системы был 3-4 кратным.
А вы говорите - закешировать БД в памяти. Тут просто файлы в память положить, уже значительный прирост будет.


Я надеюсь все понимают, что мы сейчас обсуждаем именно тот случай, когда база данных достаточно мала по определению.

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

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

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

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

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

Не расказывайте сказки. Если у вас происходит интенсивное изменение объектов большим количеством клиентов, то локальный кеш будет постоянно синхронизироваться с сервеным кешем для каждого клиента. Откуда взялась цифра 90%? Что это за вероятность, как вы ее считали? Попробуйте прикинуть затраты на синхронизацию и обслуживание блокировок при множестве клиентов.
22 фев 05, 15:36    [1338610]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить