Alexey Rovdo

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

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

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

Не нужно отвечать на другие вопросы, которых Вам никто не задавал, ответьте на эти.

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 никакой разницы. А сам внешний ключ можно убрать, он в данном случае не используется и только мешает, хотя и не очень сильно.

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

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