Здравствуйте, VladD2, Вы писали:

VD>Ничего там серьезно не переписывали.
Ты это сотрудникам MS расскажи.. Почему-то я им больше верю..

VD> И факт в том, что кластерный индекс должен быть на тех полях по которым чаще всего делается выборка.
На сколько чаще?

VD> А это с обычно и есть ПК.
Это не так. Так только в справочниках и некоторых других специальных случаях.

VD> Гуидя же — это вообще никому ненужный удар по производительности.
Да нет там никакого удара.

VD>Применять их в обычных случях можно только от большой к ним любьви. Вот если нужна репликация или это резко упрощает реализацию какого-нить сервера приложений с O/R-мапингом, то другое дело.
Никогда нельзя быть уверенным, что какой-то таблице не потребуется репликация.

Здравствуйте, VladD2, Вы писали:

VD>Маразм... Нда. Веский аргумент ничего не скажешь. Значит по твоему тупой перебор быстрее будет?
Это твой аргумент.

VD>Вот только в твоих словах все меньше и меньше о ГУИД-ах. И все больше и больше ухода от темы.
Я лишь отвечаю на твои возражения.

VD>Открой любой TPC-C тест и погляди какие там типы данных используются. Если хоть один ГУИД найдешь можно будет дальше обсудить эту теорию, а так в эту сказку я без тестов не поверю.
В tpc-c тесты примитивны, там пять таблиц и десять запросов.

Здравствуйте, VladD2, Вы писали:


VD> ни в коем случае не делать ПК кластерным...".
А вот этого я не говорил.

VD>Очень просты. ПК в иде ГУИД-а и без кластра вс. Инт + КИ. Плюс табличек 5 связанных между собой и набор запросов по ним. Естественно хотя бы в одной табличне нужно залить пару миллионов данных (чтобы хоть было видно не вооруженным взглядом).
И ничего этот тест не покажет.

VD>Ну, вот и покажешь как это будет выглядеть при реальных джоинах.
При реальных джойнах тебе уже показали.

VD>Ну, поехали еще в одну степь. Не нужно отвлекаться. Речь идет об общей производительности, а не одного специально оптимизированного запроса.
Это ты поехал, а я по прежнему про оптимальность выбора ПК на конкретной таблице.

Здравствуйте, Lexey, Вы писали:

L>В общем, я так понимаю, что упорядочивание страниц никто и не обещал. Главное, что они слинкованы в правильном порядке.
совершенно верно.

L>Ну и что? А внутри страницы данные похоже упорядочены.
L>Вот если окажется, что внутри одной страницы порядок записей может быть любым, тогда твое утверждение будет верным.
Легко, сейчас покажу:
Создадим табличку в одну страницу с кластерным индексом:

create table t(a int)

insert into t(a) values(100)
insert into t(a) values(200)
insert into t(a) values(300)
insert into t(a) values(400)

create clustered index ix on t(a)

-- выясним что получилось...
--
dbcc traceon(3604)
declare @db_id int, @tbl_id int 
select @db_id = db_id('Cavy'), @tbl_id = object_id('t') 
dbcc tab(@db_id, @tbl_id)

-- PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID PageType IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID 
-- ------- ----------- ------ ----------- ----------- ------- -------- ---------- ----------- ----------- ----------- ----------- 
-- 1       19544       NULL   NULL        853578079   1       10       0          0           0           0           0
-- 1       19543       1      19544       853578079   0       1        0          0           0           0           0
-- 1       19545       1      19544       853578079   1       2        0          0           0           0           0

Первую страницу я выделил, смотрим что там:

dbcc page('Cavy', 1, 19543, 3)

-- Slot 0 Offset 0x60
-- a                                = 100              

-- Slot 1 Offset 0x6b
-- a                                = 200              

-- Slot 2 Offset 0x76
-- a                                = 300              

-- Slot 3 Offset 0x81
-- a                                = 400

Обрати внимание на параметр Offset — физический адрес — пока все по честному, адреса подряд.
А теперь поизмываемся:

delete from t where a = 200
insert into t (a) values(250)

-- и посмотрим что произошло
-- 
dbcc page('Cavy', 1, 19543, 3)

-- Slot 0 Offset 0x60
-- a                                = 100              

-- Slot 1 Offset 0x8c
-- a                                = 250              

-- Slot 2 Offset 0x76
-- a                                = 300              

-- Slot 3 Offset 0x81
-- a                                = 400

Логически записи по прежнему отсортированы — Slot 0, Slot 1, ect... А вот физически запись 250 разместилась не по адресу 0x6b, где была раньше 200, ну или по крайней мере не между 0x60 и 0x76, а по адресу 0x8c, то есть добавилась в конец страницы.

Здравствуйте, Merle, Вы писали:

M>В tpc-c тесты примитивны, там пять таблиц и десять запросов.

Там миллионы строк и огромные объемы выборок. И там нужна максимальная производительность. В общем, как раз то о чем мы тут говорим.

Здравствуйте, Merle, Вы писали:

VD>>Ничего там серьезно не переписывали.
M>Ты это сотрудникам MS расскажи.. Почему-то я им больше верю..

Ну, у нас закрытой информации нет. А в открыто нет ни одного слова о изменении. Я уже устал говорить, что вся информация в БОЛ. Если БОЛ врет, то я уже мало чем могу помочь.

VD>> И факт в том, что кластерный индекс должен быть на тех полях по которым чаще всего делается выборка.
M>На сколько чаще?

На 324.

VD>> А это с обычно и есть ПК.
M>Это не так. Так только в справочниках и некоторых других специальных случаях.

Таких специализированных случаев 70%.

VD>> Гуидя же — это вообще никому ненужный удар по производительности.
M>Да нет там никакого удара.

Цифры в студию. А до тех пор я все же буду верить банальной логике. В четыре раза больше данных == минимум в 4 раза медленее. И минимум в 4 раза болше данных.

M>Никогда нельзя быть уверенным, что какой-то таблице не потребуется репликация.

Вот когда понадобится, тогда и введеш еще один ключик в одну таблицу. А совать на этом основании всюду гуиды не разумно.

Здравствуйте, Merle, Вы писали:

M>Во всех цитатах, за исключением одной речь идет о 2k, в одной о 7.
M>Года выпуска с 2000 по 2003, где 7 там не знаю, отдельная глава про индексы взятая с сайта MS.

И какие нафиг хотспоты при вставке в семерке и 2000-ом? Блокировки на строки уже отменили что ли?

Здравствуйте, Merle, Вы писали:

VD>>И если это так, и нет явного перекоса в сторону выборки по одному ФК,
M>Что значит перекос в сторону выборки по одному ФК?

Значит, что в 60% случаев и более делается выборка по ФК.

VD>> то смысла делать кластерный индекс на этом ФК нет.
M>Как раз в этом случае смысл есть.

В каком? Речь идет о равномерном использовании ФУ и ПК... в случае где нет явно часто используемого одного способа выборки данных... т.е. в 90% случаев.

VD>> А вот КИ на ПК при этом даст повышение производительности, так как лукап по ПК будет наиболее шустрым, ПК, а стало быь и ссылки на записи в обычных индексах будут иметь минимальный размер (и будут совпадать со словом процессора). Стало быть вся система станет быстрее.
M>Все не так. ПК — один, один раз сходить за записью — не проблема, FK много, много раз ходить за записью накладно, поэтому имеет смысл делать кластерным FK.

Нда. Логика на грани фантастики. "FK много" ... "поэтому имеет смысл делать кластерным [b]один[/b]] FK".
А ПК тем временм будет лукапиться в два приема. И джоины на него будут дормозить.


VD>>Собственно потому МС и делает по умолчанию на ПК КИ.
M>MS делает ПК кластерным вовсе не по этому, я уже писал почему, и не только я.

А. Ну, да. Вокруг все идеоты... в МС тоже... От того видимо во всех их БД ПК тоже кластерные.

VD>>Блин. И что даст ускорение выборки по одному ФК если таблица постоянно лукапится по ПК и на нае есть еще с десяток ФК?
M>Ты чего-то путаешь.

Или ты.

M> Таблица по ПК не постоянно не ищется.

Блин. Ну, сделай джоин на этот самый ПК и погляди. В БД 1-2 таблицы которые не соеденяются по ПК.

M> И при чем здесь ФК на таблицу? Если есть ФК у таблицы то он, скорее всего один.

Это ж почему он один? Где ты такие БД берешь? В таблице может быть дцат полей ссылочного типа. Каждый из них будет ФК.

VD>>Да, один запрос сужественно ускоряется. А 100 других замедляется.
M>Никто не замедлится.

Ну, ну. В общем, надоело. Делай тесты поглядим. А так пустая трата времени. Рассказы по таблицы с одним ФК к которым редко обращаются по ПК меня как то не убеждают.

VD>>Представь себе справочник в тотором, ну, 1000-3000 записей.
M>Эээээ... Справочник — это особый случай, ты же не будешь утверждать, что правильная база вся состоит из справочников?

Порой к справочникам можно отнести все таблицы кроме 3-5 где лежит основная информация. Возми к примеру БД нашего сайта. Там есть две таблицы где лежат основные данные и море справочных таблиц.

M> Скорее наоборот. Справочники — это скорее исключение.

Ну, т.е. ты держишь в голове какую-то свою модешь БД для которой и предлагаешь решения. При этом другие они все исключения. А я вот не вдел БД где справочники не были бы в большом количестве.


M>Больше как раз запросов таких, как привел KisA: Re[16]: GUID и кластерны

Автор: KisA
Дата: 22.07.04

VD>> Итоно получаем нехилый удар по производительности. Уря товарищи! За то мы выполнили все мудрые советы!
M>Ну не надо передергивать, я нигде не говорил, что всегда надо использовать не ПК? Я говорил, что ПК наименее вероятный кандидат.

А я и не передергиваю. Я просто уверен, что послушав тебя не очень опытные орлы так и сделают. Ты не раз тут заявлял, что делать КИ по ПК плохое решение и что КИ на ФК — это верный выбор в большинстве случаев. Теперь вот утверждаешь еще, что один ФК на таблицу — это самое частно втречающийся случай и что мол все таблицы нужно делать такими плюя на понятия вроде дизайна. Если бы ты сказал: "Иногда <в таких то условиях> выгоднее сделать КИ на ФК по причине того, что чтение КИ быстнее.", то с тобой никто и не стал бы спорить. А ты возвел этот в догму. Попутно наговорив на идентети и воспев ГУИД-ы.

VD>>Из БОЛ я тебе уже приводил.
M>В БОЛ из пяти или шести примеров ПК только один.

По крайней мере в БД нет бреда про хотспоты при вставке в одну таблицу и есть разумная аргументация.

VD>>Но все же кандидат?
M>Я где-то утверждал обратное?

По-моему постоянно. Слова худший выбор вроде точно звучали.

VD>>Самое забавное, что твои слова будут расценены многими не опытными людьми как призыв вообще не исполозовать кластерный индекс.
M>Ну нееет, это ж каким не опытным надо быть..

И тем не менее именно так и будет. Моло кто обратит внимание, на тонкости организации КИ и на то, что они все равно остаются уникальными и исползуются в других индексах.

VD>> В общем, не подменяй идею частной оптимизации для конкретной таблицы и паттерн для повседневного применения.
M>Паттерн для повседневного применения заключается в том, чтобы не пихать тупо кластерный индекс на ПК, о чем я и говорил с самого начала.

А по-моему как раз нужно тупо пихать кластерный индекс в ПК и если есть более подходящий кандидат, менять на него. Но это я уже говорил.

VD>>Именно ПК первый претендент,
M>Последний. Ну предпоследний, за вычетом текстовых и длинных варчарных полей.

В общем, ты явно не верно понимашь принципы оптимизации.

Здравствуйте, Merle, Вы писали:

VD>> ни в коем случае не делать ПК кластерным...".
M>А вот этого я не говорил.

И чем это отличается от заявления что ПК последний притендент на кластерный индекс?

VD>>Очень просты. ПК в иде ГУИД-а и без кластра вс. Инт + КИ. Плюс табличек 5 связанных между собой и набор запросов по ним. Естественно хотя бы в одной табличне нужно залить пару миллионов данных (чтобы хоть было видно не вооруженным взглядом).
M>И ничего этот тест не покажет.

Он покажет твою не правоту. Я просто уверен, что и скорость вставки и темболее скорость выборки, а уж объем данных подавно, будут значительно хуже у твоего решения. Да похоже ты и сам это понимашь.

VD>>Ну, вот и покажешь как это будет выглядеть при реальных джоинах.
M>При реальных джойнах тебе уже показали.

Где? Что-то ты путаешь.

VD>>Ну, поехали еще в одну степь. Не нужно отвлекаться. Речь идет об общей производительности, а не одного специально оптимизированного запроса.
M>Это ты поехал, а я по прежнему про оптимальность выбора ПК на конкретной таблице.

А я про скорость джоинов (всех а не одного). И про не оптимальность ГУИД-ов.

Здравствуйте, Merle, Вы писали:

VD>> А до тех пор я лично вижу кучу ошибок в логических рассуждениях.
M>Да бога ради, Влада убеждать просто не интересно,

Не. Как раз очень интересно. Я бы даже сказал, если ты убедил Влада, то значит привел дейсвительно неоспоримые и веские доказательства, а не растекса мыслью по древу.

M> он последний раз в серьез дело с сиквелом имел, когда я его еще в глаза не видел

Ну, предположим он у меня постоянно крутится. Но видел его я действительно раньше тебя. Мы и 7-ку и 2000 еще в бетаверсиях тестировали. 2000-ый еще тогда 7.5 назывался. Так что изменерия членов будут не в твою пользу.

M>А кого надо я уже давно убедил.

Понятно агитация с целью обращения в свою веру.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, KisA, Вы писали:

KA>>Отсюда приминимость IOT в Oracle, на мой взгляд, достаточно мала.
M>Упс, странно... А причины такого ограничения известны? И что, в Оракле PK — особенный? Или тут имелась ввиду уникальность? тогда ничего страшного...
Уникальность и not null, внутренний идентификатор записи ( RowId ) для IOT строится как функция от ключа по которому строится IOT, соответственно этот ключь должен быть уникальным, а поскольку null ключи Oracle в индексе не хранит, то null значения не разрешены. Т.е Unique+NOT NULL = "primary key sorted manner".
Как я понял в отличии от кластерного индекса в mssql,в IOT идет реальное упорядочивание внутри блока.

Здравствуйте, VladD2, Вы писали:

VD>И какие нафиг хотспоты при вставке в семерке и 2000-ом? Блокировки на строки уже отменили что ли?
Еще раз. При добавлении ключа в страницу индекса блокируется вся страница индекса. Эта кратковременная низкоуровневая блокировка (latch) держится только на время вставки, а не до конца транзакци.

Здравствуйте, VladD2, Вы писали:


KA>>В общем, ни хрена в MS-SQL не смыслю но скажу из общетехнических соображений,

VD>Хорошая аргументация. Сам я подсудимого не знал, но как и весь Советский наро...
Аргументация шла ниже, а это , типа, литературное вступление

VD>Матиматика тоже забавная. Правда не учитывает кое чего и кое в чем основывается на недоказанных предположениях, но выглядит внушитешьно.
"если кто то, кое где у нас порой...", так раскройте как кое что кое в чём учтенное кое как изменит кой какую ситуацию.
Опять же какие предположения требуется доказать, попробуем доказать ну или дать ссылку.

VD>Остается только доказать состоятельность всех рассчетов. Сделай таблички и померяй скорость. Причем таблички сделай не две, а хотя бы пять и джоинов не один, а тоже пять или десять. Померяй скорость и потом расскажи свои ощущения.
Боюсь, что измерения на Oracle тебя не устроят

Здравствуйте, KisA, Вы писали:

KA> Т.е Unique+NOT NULL = "primary key sorted manner".
Ну тогда можно в ручную делать то, что делает MSSQL, то есть искуственно добавлять уникальность в случае необходимости...

KA>Как я понял в отличии от кластерного индекса в mssql,в IOT идет реальное упорядочивание внутри блока.
А вот это уже хуже, в некоторых случаях вставка и модификация могут серьезно проседать... К тому же на сколько я помню в Оракле Read-Ahead нет и на больших выборках оптимизатор начинает сканировать страницы не в логическом порядке, а в физическом...

Здравствуйте, VladD2, Вы писали:

VD> Правда не учитывает кое чего и кое в чем основывается на недоказанных предположениях, но выглядит внушитешьно. Остается только доказать состоятельность всех рассчетов. Сделай таблички и померяй скорость. Причем таблички сделай не две, а хотя бы пять и джоинов не один, а тоже пять или десять. Померяй скорость и потом расскажи свои ощущения.

create table r (i int identity, a uniqueidentifier, b varchar(100), c varchar(100))
create table r1(i1 int identity, fk int, d varchar(100), e varchar(100))

-- заполнение r
--
declare @i int 
set @i=0
while @i<10000 begin
   insert into r (a,b,c)
   values (newID(), cast(newid() as varchar(50))+cast(newid() as varchar(50)), 
    cast(newid() as varchar(50))+cast(newid() as varchar(50)))    
   set @i=@i+1
end

-- заполнение r1
--
declare @i int 
set @i=0
while @i<100000 begin
   insert into r1 (fk,d,e)
   values (ceiling(@i/10), cast(newid() as varchar(50))+cast(newid() as varchar(50)), 
    cast(newid() as varchar(50))+cast(newid() as varchar(50)))    
   set @i=@i+1
end

-- создание временной таблички
--
select top 50 a into r_tmp from r

-- создание индексов, сначала вариант с кластеризацией по ПК.
--
create clustered index ixr on r(i)
create clustered index ixr1 on r1(i1)
create index ix2 on r(a) 
create index ix3 on r1(fk)

set statistics io on

select * from r inner join r1 on r.i=r1.fk
where r.a in(select a from r_tmp)
-- Table 'r1'. Scan count 50, logical reads 1694, physical reads 0, read-ahead reads 0.
-- Table 'r'. Scan count 50, logical reads 224, physical reads 0, read-ahead reads 0.

-- А теперь с кластеризацией по FK
--
drop index r.ixr
drop index r.ix2
drop index r1.ixr1
drop index r1.ix3

create clustered index ixr on r(a)
create clustered index ixr1 on r1(fk)
create index ix2 on r(i) 
create index ix3 on r1(i1)

select * from r inner join r1 on r.i=r1.fk
where r.a in(select a from r_tmp)
-- Table 'r1'. Scan count 50, logical reads 190, physical reads 0, read-ahead reads 0.
-- Table 'r'. Scan count 50, logical reads 114, physical reads 0, read-ahead reads 0.

И зто все для случая, когда из главной таблицы выборка хаотическая и записи короткие и все влезают на одну страницу.
Хочешь сказать, что 304 чтения будут выполняться дольше чем 1918? Можно еще подчиненных таблиц понавесить с джойнами, ситуация не изменится.

Вообщем спор у нас свелся к тому, какого рода запросы выполняются в БД чаще... Тут уж пусть каждый сам для себя решает.

Здравствуйте, VladD2, Вы писали:

VD>Значит, что в 60% случаев и более делается выборка по ФК.
Ну так обычно и происходит.

VD>Нда. Логика на грани фантастики. "FK много" ... "поэтому имеет смысл делать кластерным [b]один[/b]] FK".
Я не о том.. Не FK много, а записей одинаковых в FK много, ссылающихся на один PK.

VD>Порой к справочникам можно отнести все таблицы кроме 3-5 где лежит основная информация. Возми к примеру БД нашего сайта. Там есть две таблицы где лежат основные данные и море справочных таблиц.
Вот БД нашего сайта лучше не брать. Там ровно один запрос по ПК, который одно сообщение достает, а и ещ еодин есть, который кажет профиль конкретного пользователя. Все остальное — изнурительное сканирование диапазонов, в которых ПК вообще не при делах.

VD>А я и не передергиваю. Я просто уверен, что послушав тебя не очень опытные орлы так и сделают.
Как так? Вообще от кластеризации откажутся? Это они зря...

VD> Ты не раз тут заявлял, что делать КИ по ПК плохое решение
Да, так и есть, правда с оговоркой, что в большинстве случаев... Я не никогда не утверждал, что кластеризация по ПК — это всегда плохо, один пример, где это оправдано ты привел — справочники.

VD> и что КИ на ФК — это верный выбор в большинстве случаев.
Не в большинстве, это лишь один из примеров, когда выгоднее сделать кластеризацию не по ПК.

VD> Теперь вот утверждаешь еще, что один ФК на таблицу — это самое частно втречающийся случай и что мол все таблицы нужно делать такими плюя на понятия вроде дизайна.
Я так не говорил, это ты уже за меня додумал. Справочники, как я уже говорил — особый случай.

VD> Если бы ты сказал: "Иногда <в таких то условиях> выгоднее сделать КИ на ФК по причине того, что чтение КИ быстнее.", то с тобой никто и не стал бы спорить. А ты возвел этот в догму.
Я не возвел это в догму. Я возвел в догму, что не надо тупо делать кластеризацию по ПК, а надо подумать, и с очень хорошей вероятностью окажется, что выгоднее сделать кластеризацию по другому полю.

VD>Попутно наговорив на идентети и воспев ГУИД-ы.
Я не наговорил на identity, я лишь описал реальное положение вещей, identity тоже не безгрешен и с ним тоже могут быть проблемы.

VD>По крайней мере в БД нет бреда про хотспоты при вставке в одну таблицу и есть разумная аргументация.
Про хот-споты что-то не один я брежу, и аргументация БОЛ ни чем не отличается от моей.

VD>По-моему постоянно. Слова худший выбор вроде точно звучали.
Скорее всего худший выбор, если есть другие кандидаты.

VD>В общем, ты явно не верно понимашь принципы оптимизации.
Или ты принципы построения БД..

Вообщем спор у нас свелся к тому, какие запросы по БД выполняются чаще, а это уж каждый пусть за себя решает.

Здравствуйте, VladD2, Вы писали:


VD>Он покажет твою не правоту. Я просто уверен, что и скорость вставки и темболее скорость выборки, а уж объем данных подавно, будут значительно хуже у твоего решения. Да похоже ты и сам это понимашь.
Re[18]: GUID и кластерны

Автор: Merle
Дата: 23.07.04

Здравствуйте, Merle, Вы писали:

M>Логически записи по прежнему отсортированы — Slot 0, Slot 1, ect... А вот физически запись 250 разместилась не по адресу 0x6b, где была раньше 200, ну или по крайней мере не между 0x60 и 0x76, а по адресу 0x8c, то есть добавилась в конец страницы.

OK, теперь точно убедил. Получается, что они внутри страницы linked list строят что-ли?

Здравствуйте, Lexey, Вы писали:

L>OK, теперь точно убедил. Получается, что они внутри страницы linked list строят что-ли?
Конечно, а как бы они еще предикатные блокировки реализовывали?
Самый эффективный способ на данный момент — это Key Range lock, который без ссылок листьевых ключей друг на друга не сделаешь...
Да и для всяких сканирований штука полезная...

Здравствуйте, Merle, Lexey, Вы столько понаписали...

Казалось бы, логично выделить следующие аспекты вопроса:

1) GUID длиннее. Со всеми вытекающими.
2) В отличие от IDENTITY, GUID не генерируется монотонно (функцией NEWID(), но можно написать процедуру, которая бы использовала UuidCreateSequential()). Опять-таки со всеми вытекающими.
3) Новые GUID-значения уникальны на всех машинах.

Все эти аспекты достаточно ясны.

Мне кажется, также, что вопрос влияния длины данных на производительность можно выделить в отдельную ветку, так же как и вопрос генерации новых GUIDов внутри SQL, так же как и тему репликации.

ИМХО, у вас прозвучало много интересных моментов, которые тем не менее никак не связаны ТОЛЬКО с GUID'ами или ТОЛЬКО с кластерными индексами по таковым полям.