|
MSSQL 2000 vs Firebird 1.5
#32799234
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
|
|
|
|
|
Короче вот результаты моего нобольшого но показательного тестинга
Сравниваем: MSSQL2000 и Firebird 1.5
Имеем идентичные БД
dictionary (id, word) = 512987 записей
id integer primary,
word varchar(30) unique
indextable (document int,word int,word_npp int,weight int) = 15 750 432
записей
index (document,word_npp)
index (word)
Претензии по практической бессмысленности и логической неправильности НЕ
принимаются...
Я и так знаю что половина из них бессмысленны, половина - неправильные по
функционалу
Я только проверял производительность...
Заявления об отсутствии индексов или их неоптимальности тоже не
рассматриваются... т.к. я лично их перестроил перед тестом
Особое внимание обратите на 3-5 запросы...
именно изза них я разочаровался в FB
//Время измеряем так: "min:sec"
1 ***************
select count(*) from indextable
#MSSQL: 0:07 (index scan!!!)
#FB: 2:01 (table scan)
2 ***************
select sum(weight) from indextable
#MSSQL: 0:14 (table scan!!!)
#FB: 2:13 (table scan)
3 ***************
select word,count(*)
from indextable
where word between 100000 and 100010 --scan 10 words
group by word
#MSSQL: 0:00 (range index scan)
#FB: 0:16 (indexed table scan!!!)
4 ***************
select word,count(*)
from indextable
where word between 100000 and 101000 --scan 1000 words
group by word
#MSSQL: 0:00 !!! (range index scan)
#FB: 9:29 (indexed table scan!!!)
5 ***************
select word,count(*)
from indextable --scan all words (512тыс)
group by word
#MSSQL: 0:17 !!! (index scan)
#FB: хбз, более пулучаса (полагаю - несколько часов)
6 ***************
select word,sum(weight)
from indextable --scan all words (512тыс)
group by word
#MSSQL: 0:50 !!! (table scan)
#FB: анологично предыдущему
7 ***************
select
i.document,
sum(i.weight) relev
from
dictionary w,
indextable i
where
w.word like 'ИНФОРМ%' and
i.word = w.id
group by
i.document
#RESULT: 13278 строк
#MSSQL: 2:20
#FB: 1:27 (это радует)
// и там и там план по двум индексам
8 ***************
select
i1.document,
sum(i1.weight+i2.weight) relev
from
dictionary w1,
indextable i1,
indextable i2,
dictionary w2
where
w1.word like 'MSSQL%' and
w2.word like 'ADM%' and
i1.word = w1.id and
i2.word = w2.id and
abs(i1.word_npp-i2.word_npp)<3
group by
i.document
#RESULT: 41 строка
#MSSQL: 0:26
#FB: 0:12 (это тоже радует)
// и там и там план по 4 индексам
ВЫВОДЫ
#1 как MSSQL умудряется просканировать 15 млн записей за 14 сек - я не
знаю... ведь только чтение этого объема данных с диска должно занять минут
3-5
#2 видим что FB не умеет читать только индексы... он обязалельно лезет в
таблицу... и наверно изза этого он существенно (раз в 100) проигрывает по
простым запросам
#3 нормальные запросы по данным FB выполняет даже быстрее
#4 FB крутится в строго отведенном ему пространстве и расшираться в памяти
не считает нужным, в то время как MSSQL хавает памяти стока скока считает
нужным и видимо изза этого и существенно выигрывает по некоторым запросам
ЗАКЛЮЧЕНИЕ
FB рулит, т.к. реальные запросы выполняются немного быстрее, если только
если принять во внимание и избегать #2 и #4 (а если данных не много - то
пофиг)
Короче для большинства задач - FB оптимален
Буду рад выслушать ваше мнение по этому поводу
==Copyright Ляпис
|
|
|
