Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Yo.!
я потрясен. точно так ? неважно какой RANGE заставит прочесть весь индекс !?

мы видимо по-разному поняли процитированную фразу. Конечно же, читается только часть индекса -- от lower bound до upper bound. Это же range scan, в конце концов :-) В цитате имеется ввиду, что читаются все ключи диапазона за единый скан и только потом читаются записи в порядке хранения. А не идти по циклу "ключ->запись".
22 фев 08, 18:48    [5330195]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

fynda пишет:

> Все они. И не надо говорить, что кто-то знает, как писать абсолютно
> безглючный код.

Безглючный код - одно, а куча глобальных переменных в многопоточном
приложении - совсем другое.

Posted via ActualForum NNTP Server 1.4

22 фев 08, 22:56    [5330542]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
fynda
Member

Откуда: Пенза
Сообщений: 2785
MasterZiv

Безглючный код - одно, а куча глобальных переменных в многопоточном
приложении - совсем другое.


Это ничего, что страницей ранее мы говорили про баги, а теперь уже - про глобальные переменные? ;)
22 фев 08, 23:20    [5330565]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
dimitr

мы видимо по-разному поняли процитированную фразу. Конечно же, читается только часть индекса -- от lower bound до upper bound. Это же range scan, в конце концов :-) В цитате имеется ввиду, что читаются все ключи диапазона за единый скан и только потом читаются записи в порядке хранения. А не идти по циклу "ключ->запись".

хм ... так блоки листьев вроде как на HDD не обязательно лежат последовательно, т.е. вы спуститесь до нижнего блока и начнете ходить по ссылкам рандомно читая связаные листовые блоки, откуда возьмется "sequential I/O" ?

постгресовый bitmap index scan мне показалось походит на fast full index scan из оракла, где оракл читает с помощью scattered i/o весь индекс, а потом выкидывает ненужное. я ошибся ?
23 фев 08, 18:42    [5331316]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Yo.!
хм ... так блоки листьев вроде как на HDD не обязательно лежат последовательно, т.е. вы спуститесь до нижнего блока и начнете ходить по ссылкам рандомно читая связаные листовые блоки, откуда возьмется "sequential I/O" ?

блоки листьев тут не причем. Речь о блоках, на которые ссылаются эти листья. Ключ индекса 1 ссылается на страницу данных 5, ключ 2 на страницу 56, ключ 3 снова на страницу 5, ключ 4 на страницу 32 и т.д. PGSQL и FB буду читать страницы данных в порядке 5-32-56, а не 5-56-5-32. Есс-но, на эффективность тут влияет еще и фрагментация БД, но даже в худшем случае два чтения со страницы 5 пройдут подряд когда она в кэше, а не через неопределенных интервал времени, когда она уже может быть вытеснена.

Yo.!
постгресовый bitmap index scan мне показалось походит на fast full index scan из оракла, где оракл читает с помощью scattered i/o весь индекс, а потом выкидывает ненужное. я ошибся ?

он работает именно так, как я описал
23 фев 08, 22:30    [5331610]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
другими словами, считайте что в PGSQL/FB индексный скан (именно скан, а не индекс) всегда имеет идеальный clustering factor (в терминах оракла).
23 фев 08, 22:49    [5331655]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
как работает теперь ясно, конечно способность оттянуть нужность фулскана аж до 70-80% от выборки (если учесть, что в оракле ~12%, наверно за счет мультиблочного чтения) мягко говоря вызывает сомнения, но тут думаю упаришься мерять все варианты...
к стате такой оптимзацией и котроллер сам может заниматся (оптимизируя очередь сказийных команд).
25 фев 08, 13:28    [5333968]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
hvlad
Member

Откуда:
Сообщений: 11577
Yo.!
как работает теперь ясно, конечно способность оттянуть нужность фулскана аж до 70-80% от выборки (если учесть, что в оракле ~12%, наверно за счет мультиблочного чтения) мягко говоря вызывает сомнения, но тут думаю упаришься мерять все варианты...
к стате такой оптимзацией и котроллер сам может заниматся (оптимизируя очередь сказийных команд).
Угу и мультиблочным чтенем он тоже может сам заняться, и b-tree тоже сам строит, да и партиционировать (по цилиндрам ?) правильные контроллеры давно сами умеют...

25 фев 08, 15:59    [5334471]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
dimitr

это может говорить и об относительной неторпливости ораклового парсера :-)

Дело не в парсере, а в оптимизаторе (если только вы не имели в виду тоже самое). Поскольку у Оракла он более совершенный, процесс построения плана занимает больше времени.
25 фев 08, 19:25    [5335246]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Yo.!
как работает теперь ясно, конечно способность оттянуть нужность фулскана аж до 70-80% от выборки (если учесть, что в оракле ~12%, наверно за счет мультиблочного чтения) мягко говоря вызывает сомнения, но тут думаю упаришься мерять все варианты...
к стате такой оптимзацией и котроллер сам может заниматся (оптимизируя очередь сказийных команд).

1. не 12%, а 15%
2. это очень усредненная оценка, случаи бывают разные, где-то в оракловой ветке "Я и Ежик" показывал, как Index Range Scan 50% хорошо кластеризованной таблицы выигрывал у Full Scan той же таблицы
3. при Index Range Scan Оракл пинит последний прочитанный блок, как раз на случай он вдруг понадобиться; это конечно не так эффективно как у Жарптицы (доступ к записям в порядке их расположения в страницах), но зато не надо тратить время и память на сортировку
4. у Оракла есть альтернативные способы борьбы с плохим фактором кластеризации - IOT, Cluster.
25 фев 08, 19:51    [5335332]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
автор
Но каково по-вашему соотношение времени оптимизации к времени исполнения пусть даже коротких запросов в реальной жизни

https://www.sql.ru/forum/actualthread.aspx?tid=518669#5203350
автор
Prepare time = 20ms
Execute time = 10ms
26 фев 08, 09:37    [5336235]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
p.s. не флейма ради а истины для.
26 фев 08, 09:38    [5336237]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Чендлер
Guest
dimitr
страницу 32 и т.д. PGSQL и FB буду читать страницы данных в порядке 5-32-56, а не 5-56-5-32.


умарил :) тут уже дело не в субд а в винтах
26 фев 08, 09:45    [5336259]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Чендлер
dimitr
страницу 32 и т.д. PGSQL и FB буду читать страницы данных в порядке 5-32-56, а не 5-56-5-32.


умарил :) тут уже дело не в субд а в винтах

От вы тупые, ей богу...
Разные записи разных листовых блоков индекса могут ссылаться на строки находящиеся в одном блоке данных таблицы. Так вот смысл предварительной сортировки в том, чтобы избежать многократного чтения один и тех же блоков данных таблицы. Причем тут винты? Речь о логическом доступе.
26 фев 08, 10:36    [5336568]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
Apex

1. не 12%, а 15%
2. это очень усредненная оценка, случаи бывают разные, где-то в оракловой ветке "Я и Ежик" показывал, как Index Range Scan 50% хорошо кластеризованной таблицы выигрывал у Full Scan той же таблицы
3. при Index Range Scan Оракл пинит последний прочитанный блок, как раз на случай он вдруг понадобиться; это конечно не так эффективно как у Жарптицы (доступ к записям в порядке их расположения в страницах), но зато не надо тратить время и память на сортировку
4. у Оракла есть альтернативные способы борьбы с плохим фактором кластеризации - IOT, Cluster.


1. This threshold percentage varies greatly, however, according to the relative speed of a table scan and how clustered the row data is about the index key. The faster the table scan, the lower the percentage; the more clustered the row data, the higher the percentage.
2. а кеш он догодался сбрасывать перед замерами ? Кайт утверждает, что для чтение 25% от таблички как раз и понадобится поднять все блоки таблицы.
3. эфективней !? мелкие таблицы будут в кеше, ФБ - проигрывает занимаясь лишней сортировкой, большие таблицы оракл мультиблочно в разы, если не порядок быстрее справится с i/o. Fast index scan по сути и есть подход ФБ, но в оракле никому в голову не пришло шагать по ссылкам листьев отказываясь от мультиблочного чтения.
26 фев 08, 11:22    [5336931]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
hvlad
Member

Откуда:
Сообщений: 11577
To ScareCrow : Пользуй процедуры, раз уж так приспичило
ScareCrow
p.s. не флейма ради а истины для.
угу
26 фев 08, 12:36    [5337560]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472

>Пользуй процедуры, раз уж так приспичило
а процедуры мы таки кэшируем?

Posted via ActualForum NNTP Server 1.4

26 фев 08, 13:02    [5337796]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
hvlad
Member

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

>Пользуй процедуры, раз уж так приспичило
а процедуры мы таки кэшируем?
И даже триггеры
26 фев 08, 15:33    [5339007]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Dimitry Sibiryakov
Member

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

Yo.!

ФБ - проигрывает занимаясь лишней сортировкой, большие таблицы оракл
мультиблочно в разы, если не порядок быстрее справится с i/o. Fast index
scan по сути и есть подход ФБ, но в оракле никому в голову не пришло
шагать по ссылкам листьев отказываясь от мультиблочного чтения.

Сортировкой? Там нет никакой сортировки. Обычная битовая маска.

Posted via ActualForum NNTP Server 1.4

26 фев 08, 23:05    [5341206]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Чендлер
Guest
Apex

От вы тупые, ей богу...
Разные записи разных листовых блоков индекса могут ссылаться на строки находящиеся в одном блоке данных таблицы. Так вот смысл предварительной сортировки в том, чтобы избежать многократного чтения один и тех же блоков данных таблицы. Причем тут винты? Речь о логическом доступе.

когда блок считывается он попадает в кеш, прежде чем считать след. блок проверяется есть ли он в кеше, если нет то считываем если есть то берём из кеша. Где сортировка?
27 фев 08, 04:25    [5341469]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Чендлер

когда блок считывается он попадает в кеш, прежде чем считать след. блок проверяется есть ли он в кеше, если нет то считываем если есть то берём из кеша.
Где сортировка?

Это вообще к чему все было? Алгоритм работы для Postgres описан здесь. Следующим постом идет подтверждение того, что FB работает аналогично. К чему был ваш пост?
27 фев 08, 09:52    [5341818]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
dimitr
другими словами, считайте что в PGSQL/FB индексный скан (именно скан, а не индекс) всегда имеет идеальный clustering factor (в терминах оракла).

Кстати, Дмитрий, идеальный фактор кластеризации - это безусловно прекрасно... но что, если из все выборки мне понадобиться только первые N строк?
27 фев 08, 10:00    [5341859]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
hvlad
Member

Откуда:
Сообщений: 11577
Чендлер
Apex

От вы тупые, ей богу...
Разные записи разных листовых блоков индекса могут ссылаться на строки находящиеся в одном блоке данных таблицы. Так вот смысл предварительной сортировки в том, чтобы избежать многократного чтения один и тех же блоков данных таблицы. Причем тут винты? Речь о логическом доступе.

когда блок считывается он попадает в кеш, прежде чем считать след. блок проверяется есть ли он в кеше, если нет то считываем если есть то берём из кеша. Где сортировка?
А кто сказал, что он всё ещё в кеше ? Бывают таблицы, многократно превосходящие размеры кешей, да и не все запросы обращаются только к одной таблице.
И параллельно таких запросов может быть более одного, как ни странно. Ась ?
27 фев 08, 10:31    [5342107]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Apex
что, если из все выборки мне понадобиться только первые N строк?

это цена битмап скана, увы. Это мы уже как-то обсуждали тут с оракловыми ребятами. Но обычно на практике FIRST используется в паре с ORDER BY и тогда, при наличии индекса, подходящего под условие сортировки, будет выбран именно не-битмап скан индекса. Хотя если ORDER BY отсутствует и вы просто хотите закрыть курсор после фетча первых нескольких записей, тады ой -- тут вы FB обманули :-)
27 фев 08, 10:59    [5342375]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 5021
pkarklin
Tauler
Насчет многоаользователей и т.д. - знаю реально работающее производство совсем немалых размеров с 200-ми филиалами, колво юзверей от 100 до 500, филиалы по все России, разбер БД 39 гектар. FB 2.0.

Одно? и фсё?

Читал где-то(источник не помню), была зафиксирована приемлемая работа FB c БД в 200Гб!
28 фев 08, 18:10    [5351485]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить