Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 MSSQL 2000 vs Firebird 1.5  [new]
tRaQ
Member

Откуда:
Сообщений: 165

Короче вот результаты моего нобольшого но показательного тестинга
Сравниваем: 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 Ляпис
25 ноя 04, 11:21    [1134513]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
alexsr
Guest
tRaQ

...
#4 FB крутится в строго отведенном ему пространстве и расшираться в памяти
не считает нужным, в то время как MSSQL хавает памяти стока скока считает
нужным и видимо изза этого и существенно выигрывает по некоторым запросам


Не плохо было бы почитать доку по FB. Сколько кушать памяти определяется параметрами в файле firebird.conf.
25 ноя 04, 12:12    [1134703]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Буду рад выслушать ваше мнение по этому поводу

Какое мнение может быть, если:
автор
Претензии по практической бессмысленности и логической неправильности НЕ
принимаются...


-- Tygra's --
25 ноя 04, 12:15    [1134716]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
tRaQ
в то время как MSSQL хавает памяти стока скока считает нужным

Вобще-то в MSSQL тоже настраивается сколько ему памяти давать
25 ноя 04, 12:20    [1134747]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
konstsch
Member

Откуда: Северодвинск
Сообщений: 1029
А попробуй подредактировать firebird.conf, в сторону увеличения объёма используемой памяти.
25 ноя 04, 12:29    [1134776]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
Большая часть теста - полный бред. Прежде чем сравнивать версионник с блокировочником на запросах типа SELECT COUNT(*) - тогда сразу станет понятно что сравнение это глупое. Выйдет версиооная версия MS SQL и тоже будет TABLE SCAN использовать, так как версионник не может индексы на таком запросе использовать принципиально.
25 ноя 04, 13:47    [1135186]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
Хотел сказать что почитать про архитектуру MGA и блокировочную надо - и всё станет понятно тогда.
25 ноя 04, 13:50    [1135203]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Gold
так как версионник не может индексы на таком запросе использовать принципиально.

SQL> create table counting as
  2  select object_id, object_name, owner
  3  from dba_objects;

Table created.

SQL> update counting set object_id = -rownum where object_id is null;

18 rows updated.

SQL> alter table counting add constraint counting_pk
  2  primary key (object_id);

Table altered.

SQL> analyze table counting compute statistics;

Table analyzed.

SQL> analyze index counting_pk compute statistics;

Index analyzed.

SQL> set autotrace on;
SQL> select count(*) from counting;

  COUNT(*)                                                                      
----------                                                                      
     41725                                                                      


Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=10 Card=1)                    
   1    0   SORT (AGGREGATE)                                                    
   2    1     INDEX (FAST FULL SCAN) OF 'COUNTING_PK' (UNIQUE) 
25 ноя 04, 14:05    [1135263]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
2 tRaQ:

Сервера надо сходно настраивать, а потом говорить о том, кто сколько памяти ест.

2 Gold:

Может версионник обходиться index-only сканом, но это достаточно спорное улучшение.

2 softwarer:

Нашел образцово-показательный версионник ;-)

А в целом тест действительно бестолковый.
25 ноя 04, 14:23    [1135336]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
dimitr
Нашел образцово-показательный версионник ;-)

Просто не люблю неверных категоричных утверждений ;-)

А тот, кто скажет что это девочка - пусть первый кинет в меня камень (c)
25 ноя 04, 15:26    [1135723]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
2 softwarer:
Это на где пример? На Оракле? Так он вроде бы не совсем версионник :-)
Что индекс сканом обходиться можно при выполнении SELECT COUNT(*) я верю, но я не пойму вобще какой в этом смысл может быть, если всё равно смотреть надо каждую запись на предмет видимости для текущей транзакции...
А вобще-то я с трудом представляю как MSSQL на запрос select count(*) from indextable выдал index scan. Я с блокировочниками не работал, но интересно зачем тут вобще индекс нужен и что он будет делать если конкурирующая транзакция записи удалила? Или он удалить и вставить ничего не даст в это время?
25 ноя 04, 18:34    [1136577]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Gold
Что индекс сканом обходиться можно при выполнении SELECT COUNT(*) я верю, но я не пойму вобще какой в этом смысл может быть, если всё равно смотреть надо каждую запись на предмет видимости для текущей транзакции...


Не обязательно. Transaction ID может входить в ключ индекса и именно тогда возможен index-only scan. Минуса в этом подходе два - небольшое "раздувание" индекса (больше I/O на операцию) и факт, что любое изменение записи (даже не затрагивающее индексированных полей) приведет к изменению ключа индекса. Последнее - довольно критично.

Gold
А вобще-то я с трудом представляю как MSSQL на запрос select count(*) from indextable выдал index scan. Я с блокировочниками не работал, но интересно зачем тут вобще индекс нужен и что он будет делать если конкурирующая транзакция записи удалила? Или он удалить и вставить ничего не даст в это время?


Индекс читать быстрее, чем таблицу (он меньше). AFAIU, сервер наложит блокировку на индекс на время скана.
25 ноя 04, 18:58    [1136636]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Забыл добавить, что к Ораклу вышесказанное про индексы вообще отношения не имеет ;-) А вот в Юконе все может быть очень похоже... я бы не отказался узнать детали.
25 ноя 04, 19:03    [1136643]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> Или он удалить и вставить ничего не даст в это время?

Не даст. Там очередь образуется.
25 ноя 04, 20:11    [1136761]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
Очередь - это плохо. Не представляю даже как бы я с блокировочником работал после версионника...
26 ноя 04, 14:31    [1139016]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Gold
Это на где пример? На Оракле? Так он вроде бы не совсем версионник :-)

А тот, кто скажет что это девочка - пусть первый кинет в меня камень (c)

Gold
но я не пойму вобще какой в этом смысл может быть, если всё равно смотреть надо каждую запись на предмет видимости для текущей транзакции...

Например - если эта информация уже есть в индексе :)
26 ноя 04, 16:07    [1139589]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
Lexis
Member

Откуда: Moscow
Сообщений: 1737
а после каждого запроса кеш данных сбрасывался?
3 дек 04, 01:13    [1154523]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
Ламерский вопрос:
тут вот говорили, что MSSQL полностью поместит базу в оперативку. Поэтому и работает быстрее. Внимание вопрос: что будет с его скоростью, когда два клиента будут работать с базами под пару гигов на одном компе?
3 дек 04, 17:36    [1157249]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
2 гига - это очень маленькая база. Нчего страшного не будет.
3 дек 04, 18:02    [1157324]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
А если оперативки меньше? Куда он базу запихивать будет?
4 дек 04, 16:42    [1158144]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL 2000 vs Firebird 1.5  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> А если оперативки меньше? Куда он базу запихивать будет?

MS SQL может оставлять часть базы на диске, не запихивая её всю в оперативную память . Именно эта способность сервера позволяет ему с лёгкостью ворочать 40гигабайтными базами данных.

Размер оперативной памяти, которую можно кушать SQL серверу, можно поменять в настройках. Через диалог настроек можно задать минимальный и максимальный размер оперативной памяти, не хуже, чем через редактирование файла firebird.conf.
4 дек 04, 16:55    [1158156]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить