Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 25 26 27 28 29 30 31 [32] 33 34   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

Интересно, если в таблице Child убрать PRIMARY KEY, ситуация сильно поменяется?


Ждать 20 часов я решил нерациональным. Но тендеция увеличения времени по мере роста объема записанных данных ровно та же самая, что и ранее (100тыс за 3-4 минуты при 3-3,5млн. записей). Некоторые отличия трейсов вызваны слегка разными условиями тестирования (объем блока данных, объем доступной памяти).

Generate main complete: 2005-06-14 16:36:17.545
Child 100000 rows complete: 2005-06-14 16:40:08.534
Child 200000 rows complete: 2005-06-14 16:41:06.629
Child 300000 rows complete: 2005-06-14 16:42:55.147
Child 400000 rows complete: 2005-06-14 16:43:16.975
Child 500000 rows complete: 2005-06-14 16:44:57.055
Child 600000 rows complete: 2005-06-14 16:45:45.025
Child 700000 rows complete: 2005-06-14 16:47:02.480
Child 800000 rows complete: 2005-06-14 16:48:59.013
Child 900000 rows complete: 2005-06-14 16:50:55.562
Child 1000000 rows complete: 2005-06-14 16:52:11.548
Child 1100000 rows complete: 2005-06-14 16:53:08.065
Child 1200000 rows complete: 2005-06-14 16:55:04.208
Child 1300000 rows complete: 2005-06-14 16:57:03.429
Child 1400000 rows complete: 2005-06-14 16:59:01.900
Child 1500000 rows complete: 2005-06-14 17:01:11.553
Child 1600000 rows complete: 2005-06-14 17:03:13.991
Child 1700000 rows complete: 2005-06-14 17:05:16.929
Child 1800000 rows complete: 2005-06-14 17:07:17.243
Child 1900000 rows complete: 2005-06-14 17:09:19.353
Child 2000000 rows complete: 2005-06-14 17:11:19.291
Child 2100000 rows complete: 2005-06-14 17:13:19.277
Child 2200000 rows complete: 2005-06-14 17:15:22.996
Child 2300000 rows complete: 2005-06-14 17:17:27.153
Child 2400000 rows complete: 2005-06-14 17:19:31.310
Child 2500000 rows complete: 2005-06-14 17:21:36.279
Child 2600000 rows complete: 2005-06-14 17:24:37.819
Child 2700000 rows complete: 2005-06-14 17:28:31.931
Child 2800000 rows complete: 2005-06-14 17:30:34.041
Child 2900000 rows complete: 2005-06-14 17:32:39.839
Child 3000000 rows complete: 2005-06-14 17:35:25.881
Child 3100000 rows complete: 2005-06-14 17:38:47.560
Child 3200000 rows complete: 2005-06-14 17:40:53.232
Child 3300000 rows complete: 2005-06-14 17:44:52.375
Child 3400000 rows complete: 2005-06-14 17:48:53.486
14 июн 05, 17:53    [1620030]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Foxi - Voxi
Отнюдь. Я просто хочу сказать, что мне известны случаи, когда нужно было в конкретные сроки завершить разработку СУБД - комплекса, и ситуация была спасена именно переходом на ООСУБД. Проект Естественно, пришлось выложить денежку. Обратных случаев я не знаю. Вернее - знаю, когда из-за недопустипого медленного O/R маппинга пришлось вернуться к "традиционному сексу".

Я охотно в это поверю, особенно если командой, которой надо было в конкретные сроки закончить разработку проекта были поставлены невыполнимые задачи, типа сделать проект, работающий со всеми РСУБД, сделать супер пупер 3-х звенный механизм, который все делает сам - и скрипты генерит в РСУБД и клиента строит, а то просто ... не было нормального проектировщика БД, а может и внятного ТЗ. А может люди кодировать очень любили, такие не сильно много запросы могут писать.

Foxi - Voxi
Естественно, масса подводных камней.
Во-первых, ОО - модели (в т.ч. для СУБД) как таковой не существует в природе. Во-вторых, даже уважаемой Versant продукты (Fast Objects *, к примеру) - не ОО - по крайней мере, в том виде, как бы мне хотелось. (Про средства O/R маппинга промолчу из-за известных мне и Вам тормозах при работе - это все от бедности.) Вся мощь ООСУБД проявляется именно при разработке приложений. И если Вы не работали с ними - то и говорить не о чем. Я говорю именно об ОО - проектировании БД с использованием OODB!

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

Foxi - Voxi
ASCRUS
Как то странно, что многие ОО-приверженцы думают, что те, кто проектирует БД на РСУБД делают это исключительно потому, что стары и ничего не понимают в ООП. Очень большое заблуждение, многие именно на нем и начинали с конца 80-х и начала 90-х, когда еще не было не то, что......

Можете назвать пример реализации ООСУБД 80-х годов, которую Вы использовали?

Да без проблем - в 91-ом у меня на TP5.5, в котором появился Object Pascal, была собственная разработка навигационного движка управления данными, который поддерживал через RTTI серилизацию обьектов, у коих были не только данные и методы, но даже и события, правда реализованные через одно место (указателями на процедуры) по причине отсутствия соотвествующих механизмов в Object Pascal. Под это дело были классы визуализации и даже на этой "штуке" были сделаны несколько проектов. Потом я мягко мигрировал в сторону FoxPro 2.0 и Access 2.0, с последующим переползанием на клиент-серверные РСУБД, хотя до сих пор ООП мой основной инструмент для разработки клиентских приложений, компонент, парсеров и прочих вещей, где он идеально подходит.

Foxi - Voxi
ASCRUS
Если посмотреть, то основная масса этих специалистов как раз сейчас на РСУБД и сидит.
...

... так ведь ничего другого и нет!

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

Foxi - Voxi
Попробуйте просто ради экперимента - возьмите реляционную модель "средней тяжести" и переведите ее в любую доступную Вам ООСУБД. Получилось? Получилось! (Или не получилось - т.к. нет скорее всего у Вас доступной ООСУБД). Ну, может, только триггеры/ХП переписать пришлось в терминах языка СУБД.
А теперь берем объектную модель соизмеримой сложности (ну, по количеству классов ~ количеству таблиц - хотя это не совсем, хм, верно) - и переведите ее в реляционную. Ну, и как Вам оно? Я скромно молчу про перевод реализации методов объектов в ХП/Триггеры.

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

Foxi - Voxi
Не говоря о времени разработки - объектная модель будет готова в 10 раз быстрее, т.к. Вы не будете думать о всяких глупостях, вроде организации уникальных индексов для первичных ключей и т.п.

Только вот попробовать Вам не на чем... Беда.

Мечтать никогда не вредно. Будет удовлетворяющее требованиям и выгодное ПО, будет повод и повосхищаться ООП. Пока поводов для этого не видно.

Foxi - Voxi
ЗЫ: Вы не обращайте внимания, это я не с Вами разговаривал.

А вот не надо авторитетно так заявлять, что РСУБД плохо, а ООП хорошо, пока нет конкретных фактов о том, чего еще и нет.
14 июн 05, 17:58    [1620053]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Я бы согласился с Foxi-Voxi с одной оговоркой - все его восторги и примеры справедливы только для определенного круга задач (описание этого круга - отдельная тема).

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

Вопрос не в том какая система лучше ВООБЩЕ. А в том, что лучше для каждой конкретной задачи и тех условий (и возможно даже личных пристрастий и привычек), в которые поставлена группа разработки.

Спор же о круге задач и пристрастиях не для этого форума (ветки). Здесь я (так уж сложилось по ходу дискуссии) просто демонстрирую именно для технарей низкоуровневые примеры реальных ситуаций, в которых четко проявляются преимущества ООСУБД. Быстрая запись сложноструктурированных данных - один из таких примеров. Чтение сложноструктурированных данных станет следующим ...
14 июн 05, 18:13    [1620115]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
serg99
Member

Откуда:
Сообщений: 422
ASCRUS
А я говорю об уровне предметной области, который ООП на текущий момент не может дать смоделировать модель БД один в один модели предметной области. Если у Вас все модели являются простыми, то все в порядке. Иначе полная труба, с сотнями классов, ссылками, коллекциями и прочей лабудой, которая ничего общего с предметной областью не имеет, впрочем как и РСУБД, которые однако скромно хранят и обрабатывают данные, а не пытаются смоделировать вселенную.


Одна ремарка. ООП - это реализация объектно-ориентированного подхода к сфере программирования. Объектно-ориентированный подход к БД совсем не обязательно является калькой с ООП. Более того модель ООБД не должна совпадать с моделью ООП, так как программирование и хранение персистентных данных - это "разные виды спорта".
14 июн 05, 23:54    [1620615]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
Foxi - Voxi

Главное - надежность и скорость при проектировании СЛОЖНЫХ систем. Вот для чего нужны ООСУБД.


А мы строим исключительно простые системы и страшно медленно.

Мы начали это обсуждение со сравнения длины кода Версанта и СКЛ-я. Вам туда. Причем задача была выбрана сторонником и пропагандистом ООБД. Короче недостаточно быть писателем, нужно еще быть читателем, хотя бы изредка.


Alexey Rovdo

Выложите исходники ваших экспериментов. Исходники ASCRUS и мои перед вами. Все эксперименты я проводил именно с ними.


При чем тут исходники, кроме исходников в СКЛ серверах (и вдругих тоже, в том числе наверняка в версанте) есть настройки самого сервера и еще куча всего. Там ищите. Еще может нужно транзакции закрывать чаще или реже. Откуда я знаю что Вы там натворили с сервером.

Предположение о кеше правдоподобное. Версант кеш не использует? Если использует, то где-то должна встретится та же ситуация, версант тормознется и преимущество НА ПОРЯДКИ пропадет.
15 июн 05, 01:03    [1620664]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
c127
Предположение о кеше правдоподобное. Версант кеш не использует? Если использует, то где-то должна встретится та же ситуация, версант тормознется и преимущество НА ПОРЯДКИ пропадет.

Не тормознет - ему кэшировать нечего. Он же сразу при вставке записи знает адрес ее родителя, соотвествующе ему остается только проверить, что родитель существует по указанному адресу и записать обьект, ничего не сканируя. При таком подходе скорость записи у Versant естественно будет выше на операциях записи и чтения сложноструктуированных данных, как впрочем и говорил Алексей. Однако этот же подход ставит крест на обработке множеств большого обьема - здесь любая коммерческая РСУБД, выполняя нерегламентированные сложные запросы, сделает его на раз.
15 июн 05, 08:06    [1620801]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

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


О чем и речь ...
В разных условиях преимущества будут у разных систем.

За сим задачу с записью сложноструктурированных данных считаю закрытой. А c127 рекомендую вернуться в конструктивное русло, а не высказываться в том духе, что дескать "незнаю почему но работать не будет".

PS: Недель через пару постараюсь закончить свои эксперименты с ораклом и выложить результаты сравнения по выполнению тестовых запросов для рассматривавшейся ранее билетной системы.
15 июн 05, 13:42    [1621624]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
x
Guest
ASCRUS
Не тормознет - ему кэшировать нечего. Он же сразу при вставке записи знает адрес ее родителя, соотвествующе ему остается только проверить, что родитель существует по указанному адресу и записать обьект, ничего не сканируя

Чтобы проверить - нужно поднять страницу с объектом в оперативную память (или хотя бы соответствующую индексную страницу).
15 июн 05, 16:08    [1622337]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
За сим задачу с записью сложноструктурированных данных считаю закрытой


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

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

вставка большого количества записей в одну-две таблицы не является задачей с записью сложноструктурированных данных. Быстрее всего в такого рода задачах будет запись в обычный текстовый файл.


Все это уже обсуждалось:
1, 2, 3, 4, 5, 6, ...
15 июн 05, 16:52    [1622554]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Дык я не понял. Получается, что если в таблице SYBASE нет ни ключей , ни индексов, то скорость добавление записей все равно зависит от числа уже вставленных строк? Ну связана она с другой таблицей по FOREIGN KEY, но ведь в этой другой таблице число записей не меняется. ИМХО это какая то чушь.
15 июн 05, 16:54    [1622566]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...
Дык я не понял. Получается, что если в таблице SYBASE нет ни ключей , ни индексов, то скорость добавление записей все равно зависит от числа уже вставленных строк? Ну связана она с другой таблицей по FOREIGN KEY, но ведь в этой другой таблице число записей не меняется. ИМХО это какая то чушь.


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

Впрочем, это мое мнение. Специалисты по Sybase могут меня поправить и предложить эксперименты для уточнения истинного положения вещей.
15 июн 05, 17:09    [1622643]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
x
Guest
Alexey Rovdo
Мне кажется, что объяснение этому лежит в особенностях работы кэша

То есть разница времен объясняется тем, что кэш в FO реализован лучше, чем в SYBASE ?
15 июн 05, 17:49    [1622813]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
x
То есть разница времен объясняется тем, что кэш в FO реализован лучше, чем в SYBASE ?


Вы не в теме. Мы с мимипробегавшим обсуждали несколько странное поведение именно Sybase. Я предложил свое объяснение, но на нем не настаиваю. На общие результаты тестов это никоим образом не влияет.
15 июн 05, 18:16    [1622916]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
x
Guest
Alexey Rovdo
Вы не в теме. Мы с мимипробегавшим обсуждали несколько странное поведение именно Sybase. Я предложил свое объяснение, но на нем не настаиваю. На общие результаты тестов это никоим образом не влияет.
Я и не оспариваю ваши результаты.
Я пытаюсь понять логику объяснения.
15 июн 05, 19:24    [1623105]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

То есть разница времен объясняется тем, что кэш в FO реализован лучше, чем в SYBASE ?

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

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

... Ну, найдете Вы причину. Устраните. Обгонит SYBASE Версанта. ...


Вы действительно всеръез полагаете, что настройки Sybase ASA по умолчанию можно улучшить на столько, что скорость работы нашего примитивнейшего теста возрастет более чем в 75 раз?

Я ведь не зря выкладываю здесь все исходники. Каждый может повторить эти тесты у себя, если данное сравнение его действительно интересует.
16 июн 05, 10:42    [1624015]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
vadiminfo
Member

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

Вы действительно всеръез полагаете, что настройки Sybase ASA по умолчанию можно улучшить на столько, что скорость работы нашего примитивнейшего теста возрастет более чем в 75 раз?


А Вы всеръез полагаете, что отставание СУБД Sybase в 75 раз от любой другой СУБД на одном и том же компе не нуждается в комметариях от производителей? Что это не вызовет сомнений в том, что что-то здесь не так?
Если бы я проводил тест, и у меня Версант отстал бы в 75 раз на записях на диск, я бы просто не решился об этом объявить без дополнительных консультаций, опасаясь что где-то явно что-то не так.
Падение скорости при закачке, в том числе драмматическое, наблюдал в своей практике причем одной и той же СУБД, но в разгное время.
Кстати, хотел спросить: Версант блокировочник?

Alexey Rovdo

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

Это хорошее дело. Интересно смотреть логику работы других СУБД для тех или иных задач.
16 июн 05, 23:07    [1627059]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
x
Guest
vadiminfo
А Вы всеръез полагаете, что отставание СУБД Sybase в 75 раз от любой другой СУБД на одном и том же компе не нуждается в комметариях от производителей? Что это не вызовет сомнений в том, что что-то здесь не так?
В комментариях (точнее попытках объяснить такой феномен) несомненно нуждается, однако почему обязательно от производителей ?
В конце концов здесь толпа админов, которые и должны заниматься настройкой производительности.

Кстати нелинейная зависимость времени вставки в дочернюю таблицу от числа записей в этой таблице наблюдается также и в MSSQL и в ACCESS (я имею в виду тот же самый тест). И скорость выполнения хотя и различается, но в разы, а не на порядки.

Так что комментарии очень интересны
17 июн 05, 10:17    [1627632]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
x
Кстати нелинейная зависимость времени вставки в дочернюю таблицу от числа записей в этой таблице наблюдается также и в MSSQL и в ACCESS (я имею в виду тот же самый тест). И скорость выполнения хотя и различается, но в разы, а не на порядки.

Так что комментарии очень интересны

То что нелинейная зависимость наблюдается, это несомненно. А вот насчет скорости выполнения в разы хотелось бы увидеть здесь результаты тестов. Что то мне слабо верится, что у MSSQL скорость будет только в разы, а не порядки отличаться.
17 июн 05, 10:25    [1627657]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

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

А Вы всеръез полагаете, что отставание СУБД Sybase в 75 раз от любой другой СУБД на одном и том же компе не нуждается в комметариях от производителей? Что это не вызовет сомнений в том, что что-то здесь не так?


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

vadiminfo

Кстати, хотел спросить: Версант блокировочник?


Затрудняюсь ответить на данный вопрос однозначно. Мне не известна подобная классификация в мире ОСУБД. Учитывая, что продукты Versant являются т.н. "пассивными" серверами, а объекты всегда инстанцируются на клиенте, получается, что каждый клиент получает свою копию объекта - т.е. это скорее версионники, если говорить по аналогии. Но с другой стороны, запросы обрабатываются на сервере и здесь уже нужно искать другие аналогии. VDS поддерживает версионность для хранимых объектов. Возможности FO в этом плане гораздо уже. В обоих ООСУБД блокировки работают на уровне отдельных объектов и ими можно очень гибко управлять (оптимистические/пессимистические, уровни изоляции и т.п.).
17 июн 05, 11:43    [1628113]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Мимо пробегал...
Guest
Да в том то все и дело, что в момент вставки записей в дочернюю таблицу число записей в родительской таблице не меняется! А если учесть, что в дочерней таблице собственные (не внешние) ключи отсутсвуют (в этом SQL отходит от рел. модели) то есть проверять что то в самой себе она не должна, такое поведения никак не укладывается у меня в голове. По идее он должно втсавлят с одинаковой скоростью, что первые записи, что последнии.
17 июн 05, 12:01    [1628220]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мимо пробегал...
Да в том то все и дело, что в момент вставки записей в дочернюю таблицу число записей в родительской таблице не меняется! А если учесть, что в дочерней таблице собственные (не внешние) ключи отсутсвуют (в этом SQL отходит от рел. модели) то есть проверять что то в самой себе она не должна, такое поведения никак не укладывается у меня в голове. По идее он должно втсавлят с одинаковой скоростью, что первые записи, что последнии.


Мы с вами путаем людей. Я то понимаю, что вы говорите о странной нелинейной зависимости в Sybase времени вставки во вторую таблицу от объема этой таблицы. Но другие могут понять это как обсуждение отличий Sybase от Versant, которые непосредственно влияют на результаты тестов. На мой же взгляд - это частность. Примерно то же я наблюдал и в Oracle. Как кстати вам мое уже прозвучавшее объяснение относительно кэша? Вам оно кажется неубедительным?
17 июн 05, 12:09    [1628276]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Suite)  [new]
x
Guest
ASCRUS
То что нелинейная зависимость наблюдается, это несомненно. А вот насчет скорости выполнения в разы хотелось бы увидеть здесь результаты тестов. Что то мне слабо верится, что у MSSQL скорость будет только в разы, а не порядки отличаться.
Я имел в виду, что результаты моих тестов отличаются от Ваших в разы (Точнее на моей машине ACCESS показывает чуть более высокую скорость, чем SYBASE на Вашей, а MSSQL - в два раза медленнее).

Я не понимаю откуда берется такая резкая нелинейность. Если бы она была логарифмической - вопросов бы не было.

Я не понимаю почему у FO зависимость другая

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

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

Если бы FO не пользовался кэшированием, а тупо поднимал страницы с диска, то зависимость хотя и была бы линейной, но скорость была бы низкой.


В том и прикол, что не пользовался я кэшированием - не требовалось оно мне здесь. Я ведь про 3,5 Мб занимаемой памяти написал выше. Другое дело, что есть кэш операционной системы, которая конечно ускоряет работу с файлами на диске.
17 июн 05, 12:24    [1628392]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 25 26 27 28 29 30 31 [32] 33 34   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить