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


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


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

Все еще жду ответ на на вопрос с индексами у фастобджектса. Проверяется уникальный индекс при вставке или нет? Если нет то как обеспечивается условие уникальности? Если предположение с исчерпанием кеша верно, то у фастобджекста там тоже должен закончиться кеш и выигрыш опять уменьшится до 3-х раз как минимум, а скорее еще больше.

Не нужно отвечать на другие вопросы, которых Вам никто не задавал, ответьте на эти.
23 июн 05, 03:04    [1642467]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Alexey Rovdo
Member

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

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


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

Так вы признаете, что в данном тесте РСУБД проигрывают? (Да/Нет).

c127

Или подправьте настройки сервера, увеличте кеш, например, и тоже получите сравнимый результат, если дело действительно в кеше.


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

c127

Все еще жду ответ на на вопрос с индексами у фастобджектса. Проверяется уникальный индекс при вставке или нет? Если нет то как обеспечивается условие уникальности?


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

c127

Если предположение с исчерпанием кеша верно, то у фастобджекста там тоже должен закончиться кеш и выигрыш опять уменьшится до 3-х раз как минимум, а скорее еще больше.


Повторяю еще раз. Обеспечение уникальности записей или не обеспечение оной (с помощью индексов в FO или c помощью PK в Sybase) не оказывает кардинального влияния на результаты тестов ни в FO, ни в Sybase - выигрыш FO обусловлен совершенно другими причинами, имеющими отношение к проверке наличия родительской записи. И кэш тут тоже нипричем.
23 июн 05, 10:15    [1642836]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
c127
Guest
Alexey Rovdo
c127

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


Так вы признаете, что в данном тесте РСУБД проигрывают? (Да/Нет).


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

Ответ: Да. Экспериментатор не ахти.

Alexey Rovdo
Да ради бога, объясните мне что вы понимаете в данном случае с двумя таблицами под денормализацией, если не отказ от FK. Сумеете внятно объяснить - я проведу эксперимент. А нет, так перестаньте голову морочить.


Виноват, переоценил знания оппонента, постараюсь исправиться. Я полагал как денормализовать базу знают все, как и в случае с константным временем поиска по хеш индексу. Например можно поступить так: взять записи их главной таблицы и положить их в предварительно заведенные поля соответсвующих записей дочерней таблицы. Главную таблицу уберать вообще. Сканирования ФК никогда нет по причине остсутсвия таблицы.

Alexey Rovdo

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


А фастобджектс, надо пологать, от большего объема данных только ускоряется.

Alexey Rovdo
Увеличение кэша в Sybase действительно может помочь, но оно возможно только в пределах существующего объема оперативной памяти. Я же говорю о том, что на больших объемах данных, значительно превышающих доступный объем кэша, влияние этого средства повышения производительности становится не существенным.


Но ведь мы говорим о конкретном эксперименте с 10 млн записей и никаком другом. Вы же делаете ОБЩИЕ выводы на основе этого конкретного эксперимента, вот увеличте кеш и продолжайте делать ОБЩИЕ выводы на основании этого нового эксперимента, который такого выигрыша фастобджектса не покажет. Тогда будет по-честному: общий вывод там, обший вывод тут. А может фастобджектс тоже доберется до пределов своего кеша и тогда сайбейз какое-то время будет выигрывать в 75 раз. Тоже неплохой повод для очередных общих выводов.

Alexey Rovdo

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


Все понятно, я же это тоже давным давно пояснял: "Короче версант должен поймать такой же якорь при исчерпании кеша, разумеется если сайбейз действительно тормознул по этой причине." (c127, 18 июн 05, 03:09) Так что вроде бы все понятно.

Alexey Rovdo
Повторяю еще раз. Обеспечение уникальности записей или не обеспечение оной (с помощью индексов в FO или c помощью PK в Sybase) не оказывает кардинального влияния на результаты тестов ни в FO, ни в Sybase - выигрыш FO обусловлен совершенно другими причинами, имеющими отношение к проверке наличия родительской записи. И кэш тут тоже нипричем.


Как это, а это что? "Думаю это связано с исчерпанием памяти. На начальном этапе заполнения таблицы ChildTable весьма на мой взгляд эффективный механизм кэширования Sybase существенно ускоряет процесс. " (Alexey Rovdo, 14 июн 05, 16:20 [1619646])

Опять приходится проводить ликбез. Проверка наличия родительской записи не отличается от проверки уникальности по уникальному индексу. ПОТОМУ ЧТО ЕСЛИ ВАМ УДАЛОСЬ ОПРЕДЕЛИТЬ ВНЕШНИЙ КЛЮЧ В АСА (и во всех РСУБД по-моему), ТО ЗНАЧИТ ОН ССЫЛАЕТСЯ ЛИБО НА ПЕРВИЧНЫЙ КЛЮЧ ЛИБО НА ПОЛЕ ОБЪЯВЛЕННОЕ UNIQUE. Что в ФО UNIQUE, что в АСА UNIQUE никакой разницы. А сам внешний ключ можно убрать, он в данном случае не используется и только мешает, хотя и не очень сильно.

Едем дальше. Индекс в фастобджектсе есть? Есть. Условие что индекс уникальный есть? Есть. Проверять при вставке это условие нужно? Нужно. С ростом количества записей этот процесс замедляется? В принципе да, если индекс - дерево, и потом тоже перестанет помещаться в память. Значит у фастобджектса должно быть в какой-то момент резкое замедление. Это если Ваше процитированное предположение об исчерпании кеша верно.

И откуда Вы можете знать чем именно обуславливается выигрыш фастобджектса? Как Вы это проверили? Ничего подтверждающего предполагаемую Вами причину выигрыша не приведено, кроме не очень грамотных рассуждений на заданную тему.
24 июн 05, 03:56    [1646015]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 25 26 27 28 29 30 31 32 33 [34]
Все форумы / Сравнение СУБД Ответить