Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / MSSQL 2000 vs Firebird 1.5 / 21 сообщений из 21, страница 1 из 1
25.11.2004, 11:21
    #32799234
tRaQ
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5

Короче вот результаты моего нобольшого но показательного тестинга
Сравниваем: 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 Ляпис
...
Рейтинг: 0 / 0
25.11.2004, 12:12
    #32799330
alexsr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
tRaQ
...
#4 FB крутится в строго отведенном ему пространстве и расшираться в памяти
не считает нужным, в то время как MSSQL хавает памяти стока скока считает
нужным и видимо изза этого и существенно выигрывает по некоторым запросам


Не плохо было бы почитать доку по FB. Сколько кушать памяти определяется параметрами в файле firebird.conf.
...
Рейтинг: 0 / 0
25.11.2004, 12:15
    #32799340
tygra
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
автор Буду рад выслушать ваше мнение по этому поводу
Какое мнение может быть, если:
автор Претензии по практической бессмысленности и логической неправильности НЕ
принимаются...


-- Tygra's --
...
Рейтинг: 0 / 0
25.11.2004, 12:20
    #32799360
SergSuper
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
tRaQ в то время как MSSQL хавает памяти стока скока считает нужным
Вобще-то в MSSQL тоже настраивается сколько ему памяти давать
...
Рейтинг: 0 / 0
25.11.2004, 12:29
    #32799377
konstsch
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
А попробуй подредактировать firebird.conf, в сторону увеличения объёма используемой памяти.
...
Рейтинг: 0 / 0
25.11.2004, 13:47
    #32799603
Gold
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
Большая часть теста - полный бред. Прежде чем сравнивать версионник с блокировочником на запросах типа SELECT COUNT(*) - тогда сразу станет понятно что сравнение это глупое. Выйдет версиооная версия MS SQL и тоже будет TABLE SCAN использовать, так как версионник не может индексы на таком запросе использовать принципиально.
...
Рейтинг: 0 / 0
25.11.2004, 13:50
    #32799617
Gold
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
Хотел сказать что почитать про архитектуру MGA и блокировочную надо - и всё станет понятно тогда.
...
Рейтинг: 0 / 0
25.11.2004, 14:05
    #32799650
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
Gold так как версионник не может индексы на таком запросе использовать принципиально.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
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) 
...
Рейтинг: 0 / 0
25.11.2004, 14:23
    #32799700
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
2 tRaQ:

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

2 Gold:

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

2 softwarer:

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

А в целом тест действительно бестолковый.
...
Рейтинг: 0 / 0
25.11.2004, 15:26
    #32799920
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
dimitrНашел образцово-показательный версионник ;-)
Просто не люблю неверных категоричных утверждений ;-)

А тот, кто скажет что это девочка - пусть первый кинет в меня камень (c)
...
Рейтинг: 0 / 0
25.11.2004, 18:34
    #32800400
Gold
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
2 softwarer:
Это на где пример? На Оракле? Так он вроде бы не совсем версионник :-)
Что индекс сканом обходиться можно при выполнении SELECT COUNT(*) я верю, но я не пойму вобще какой в этом смысл может быть, если всё равно смотреть надо каждую запись на предмет видимости для текущей транзакции...
А вобще-то я с трудом представляю как MSSQL на запрос select count(*) from indextable выдал index scan. Я с блокировочниками не работал, но интересно зачем тут вобще индекс нужен и что он будет делать если конкурирующая транзакция записи удалила? Или он удалить и вставить ничего не даст в это время?
...
Рейтинг: 0 / 0
25.11.2004, 18:58
    #32800431
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
GoldЧто индекс сканом обходиться можно при выполнении SELECT COUNT(*) я верю, но я не пойму вобще какой в этом смысл может быть, если всё равно смотреть надо каждую запись на предмет видимости для текущей транзакции...

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

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

Индекс читать быстрее, чем таблицу (он меньше). AFAIU, сервер наложит блокировку на индекс на время скана.
...
Рейтинг: 0 / 0
25.11.2004, 19:03
    #32800437
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
Забыл добавить, что к Ораклу вышесказанное про индексы вообще отношения не имеет ;-) А вот в Юконе все может быть очень похоже... я бы не отказался узнать детали.
...
Рейтинг: 0 / 0
25.11.2004, 20:11
    #32800505
www.fun4me.narod.ru
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
>> Или он удалить и вставить ничего не даст в это время?

Не даст. Там очередь образуется.
...
Рейтинг: 0 / 0
26.11.2004, 14:31
    #32801560
Gold
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
Очередь - это плохо. Не представляю даже как бы я с блокировочником работал после версионника...
...
Рейтинг: 0 / 0
26.11.2004, 16:07
    #32801822
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
GoldЭто на где пример? На Оракле? Так он вроде бы не совсем версионник :-)
А тот, кто скажет что это девочка - пусть первый кинет в меня камень (c)

Goldно я не пойму вобще какой в этом смысл может быть, если всё равно смотреть надо каждую запись на предмет видимости для текущей транзакции...
Например - если эта информация уже есть в индексе :)
...
Рейтинг: 0 / 0
03.12.2004, 01:13
    #32810760
Lexis
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
а после каждого запроса кеш данных сбрасывался?
...
Рейтинг: 0 / 0
03.12.2004, 17:36
    #32812542
Sarin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
Ламерский вопрос:
тут вот говорили, что MSSQL полностью поместит базу в оперативку. Поэтому и работает быстрее. Внимание вопрос: что будет с его скоростью, когда два клиента будут работать с базами под пару гигов на одном компе?
...
Рейтинг: 0 / 0
03.12.2004, 18:02
    #32812593
www.fun4me.narod.ru
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
2 гига - это очень маленькая база. Нчего страшного не будет.
...
Рейтинг: 0 / 0
04.12.2004, 16:42
    #32813089
Sarin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
А если оперативки меньше? Куда он базу запихивать будет?
...
Рейтинг: 0 / 0
04.12.2004, 16:55
    #32813101
www.fun4me.narod.ru
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MSSQL 2000 vs Firebird 1.5
>> А если оперативки меньше? Куда он базу запихивать будет?

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

Размер оперативной памяти, которую можно кушать SQL серверу, можно поменять в настройках. Через диалог настроек можно задать минимальный и максимальный размер оперативной памяти, не хуже, чем через редактирование файла firebird.conf.
...
Рейтинг: 0 / 0
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / MSSQL 2000 vs Firebird 1.5 / 21 сообщений из 21, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]