Здравствуйте, Merle, Вы писали:
L>>С чего бы это? Последняя страница одна, а выборки по чтению идут по всем. M>Ну, это действительно скорее проблема интенсивной вставки, но есть такой нюанс, что
Это тогда уж скорее проблема твоего конкретного случая.
M> в реальных очень часто нужны именно последние, только что вставленные данные. И простая вероятность тут мало что решает..
Как раз в нормальной жизни между появлением объекта в базе и появлением желающих его читать проходит какое-то время.
Не могли бы уважаемые, как определитесь с выводами, озвучить их с практической точки зрения ?
Сам это разбирал полтора года назад, как бы понятно процентов на 90% что Вы пишете, но кол-во сообщений не дает сделать осмысленные выводы.
Может в журнале ? Я его читаю !
Здравствуйте, Lexey, Вы писали:
L>Как раз в нормальной жизни между появлением объекта в базе и появлением желающих его читать проходит какое-то время.
Мне что-то нормальной жизни довольно мало встречалось...
Здравствуйте, VladD2, Вы писали:
VD>Ссылки, плиз. Вот перевод МС-ного мануала: VD>http://www.optim.ru/cs/1999/2/sql7architecture/sql7architecture.asp
Это мануал MSSQL 7.0, в 2000 все поменяли. В семерке действительно была физическая упорядоченность, в 2000 от нее отказались.
VD>Еще раз. Ссылки и тесты в студию.
L>>>С некоторой долей вероятности? Это как? M>>Так, что физического упорядочивания записи нет, есть упорядоченность страниц и гарантия того, что запись "меньше" самой "большой" и "больше" самой маленькой записи страницы окажется на этой странице.
VD>См. выше.
VD>Что уж МС называет физическим порядком решать тебе.
Ну, пример того как на самом деле поступает сервер с кластерным индексом я уже привел... Глазам своим не веришь?
VD>Но как минимум записи в странице точно упорядочены. Или это уже не индекс.
Ничего они не упорядочены, точнее упорядочены логически. Какой смысл в физическом упорядочивании, если с диска поднимается вся страница за раз?
Достаточно гарантии того, что не придется прыгать из середины на другую страницу за следующей записью, эта гарантия есть, а больше ничего кластерный индекс не гарантирует, ну кроме того, что страницы будут сканироваться в логическом порядке, по указателям PrevPID, NextPID.
VD>по-моему, совершенно однозначно дают понять...
Да бога ради...
VD> Ну, и далее все будет ясно.
Делал неоднократно, в различных вариантах, для различных задач. Результаты примерно такие: При интенсивной вставке из параллельных транзакций в табличку с кластерным/некластерным guid'ом/identity индексом, разницы между guid и identity практически нет. Выборка сильно зависит от ситуации, но в среднем колеблется от 5 до 20% в пользу identity, когда количество записей приближается к нескольким миллионам.
Здравствуйте, Lexey, Вы писали:
L>Очень интересный результат. Статейку не хочешь на эту тему написать?
Да этой новости уже 5 лет, периодически статьи появляются на всяких sqlserverperfomance.com, ectю, когда кто-нибудь в очередной раз наталкивается на непонятки с кластерным индексом и делает открытие... Один вот, недавно, на sql.ru натолкнулся, тоже топик километровый наваял...
L>С этим все равно не согласен. Аргументы все те же — фрагментация индекса, меньшая плотность заполнения и cache misses.
Да, по поводу меньшей плотности заполнения и разбиения страниц — согласен.
L> Я говорил, что в случае вставки в конец заблокирована только одна страница, а у тебя таких страниц может быть пачка. Вероятность нарваться на блокировку при чтении у тебя больше.
Нет, все совсем не так. Этот latch очень и очень быстрая операция, когда эти latch'и размазаны по всей таблице из вообще никто не замечает, время ожидания мизерно. А при вставке в конец, из большого числа разных транзакций, последняя страница оказывается заблокирована постоянно, и не смотря на то, что блокировка очень короткая все равно выстраивается очередь на ресурс.
L>Кластеризации по неуникальному полю вообще не бывает. Сервер все равно сделает кластерный индекс уникальным.
Это уже частности.. Смысл в том, что физически записи нужные одной группе транзакций оказываются рядом и не пересекаются с записями нужными другим транзакциям.
L> Вот ты все про бизнес логику. А с чего ты решал, что бизнес-логике нужны именно такие запросы.
Да я и не говорю что всегда, но в большинстве случаев оказывается именно так.
L> Да, такие запросы бывают, но в тех базах, с которыми я работал, они составляли от силы процентов 30. И грузили они сервер не очень сильно. А основная нагрузка шла на join'ы, которые как раз и делаются по identity и напрямую выигрывают от его кластеризации.
Что-то с трудом верится... У вас все таблицы с отношением один к одному? Или при выборке из подчиненной в большинстве случаев FK не учавствует?
L>Т.е. композитный уникальный ключ приемлемой длины в данном случае не построишь?
Можно и построить, а зачем?
Здравствуйте, Lexey, Вы писали:
L>Равномерно — да, но заполненность у них при этом может получиться хреновой.
Ну, скорее всего как раз процентов 70-80, хотя и возможны флуктуации..
L>Обрати внимание на выделенное. В случае вставки в конец нет никакой необходимости дробить страницу — гораздо проще начать новую.
Да, скорее всего ты прав.
VD>Объясни тогда почеиму когда создаешь ПК на таблице mssql автоматом делает кластерный индекс? Они по твоему вредительством занимаются?
Потому что MS разрабатывался так, чтобы работать даже в кривых руках, и даже у людей, которые вообще не знают что такое индекс. А поскольку хоть какой-то кластерный индекс лучше, чем отсутствие кластерного индекса вообще, то они и лепят его по умолчанию на PK, чтобы не промазать.
VD>Любоая. Если на таблице нет кластеного уникального индекса, то любая ссылка будет букмарком, т.е. все индексы будут содержать букмарки в качестве идентификаторов строк. Если же на таблице есть уникальный кластерный индекс (УКИ), то в индексах будет использоваться именно он (см. BOL).
Все немного не так.
Для того что бы не было букмарков уникальности от кластерного индекса не требуется, сервер сам обеспечит эту уникальность если создать кластерный индекс по неуникальному полю, добавив в ключ числовой идентификатор. Но физически одинаковые записи окажутся рядом, на одной или соседних страницах, собственно ради этого все и затевается. Так что букмарка не будет по любому, при поиске по полю с кластерным индексом, в не зависимости от того уникально это поле или нет.
VD>Пробовал. Не помогает. Видимо нужно тщательнее излагать мысли.
Согласен, нужно..
Здравствуйте, VladD2, Вы писали:
VD>И оно снова ошибочное. МС сами советуют это делать.
Они не советуют, они просто пихают кластерный индекс по дефолту на PK, чтобы хоть какой-то был... И в данном случае я доверяю не БОЛ и визардам, а собственному опыту, который говорит, что кластеризация по PK бывает оправдана довольно редко.
VD>Не, ну, доказывая приемущества ГУИДов переходить на другие примеры как не очень верно с точки зрения логики.
Как я уже говорил, здесь я обсуждал вопрос очень слабо связанный со спором GUID vs identity, а именно необходимость кластеризации по PK.
VD>Если индекс кластерный, то букмарков не будет вообще, и стало быть не будет и связанных с ними накладных расходов.
Зато будут букмарки и гораздо более серьезные накладные расходы при диапазонных и массовых выборках.
Здравствуйте, Lexey, Вы писали:
L>>>В описанное верится очень слабо. M>>Тем не менее это так. L>Конкретный пример и цифры в студию, pls (если есть). Пока мой здравый смысл утверждает ровно обратное.
Вот цитаты из умных книжек:
Ken Henderson, "Guru's Guide To T-SQL":
A table without a clustered index is known as a heap table. Rows inserted into a heap table are
inserted wherever there’s room in the table. If there’s no room on any of the table’s existing
pages, a new page is created and the rows are inserted onto it. This can create a hotspot at the
end of the table (meaning that users attempting simultaneous INSERTs on the table will vie for
the same resources). To alleviate the possibility of this happening, you should always establish
clustered indexes for the tables you build. Consider using a unique key that distributes new
rows evenly across the table. Avoid automatic, sequential, clustered index keys as they can
cause hotspots, too.
Microsoft T-SQL Performance Tuning Part 2: Index Tuning Strategies Adapted from “Transact-SQL Programming” By Kevin Kline, Andrew Zanevsky, and Lee Gould. Published by O’Reilly & Associates. ISBN: 1565924010
Columns with monotonously increasing values, such as a column with the IDENTITY property or TIMESTAMP columns, can be dangerous. They create a “hot spot” of activity on the last page. Good for certain types of OLTP applications because it minimizes page splits. But can also be bad for certain locking situations.
Там же, чуть ниже, уже по вопросу выбора кластерного индекса:
Clustered indexes are good for queries that use:
· GROUP BY that use all or the first few columns of the clustered index key,
· ORDER BY that use all or the first few columns of the clustered index key,
· WHERE clause conditions comparing to the first or the first few columns of the clustered index key and retrieving many rows,
· Long keys (either based on long columns or composite keys comprised of many columns), because a clustered index on a long key takes no extra space for the leaf level. A non-clustered index on a long key may be quite large, because it takes a lot of space to store keys of the leaf level of the index.
The first three types benefit from the fact that requested rows are located continuously on the table. SQL Server only has to find the first qualifying row and then keep on scanning until all rows are done. Several rows found on a single page reduce the number of I/O operations needed to access all the data. Additionally, Microsoft SQL Server has a performance booster — the read-ahead feature that automatically detects sequential reads from the same table and prefetches data pages before the query asks for them.
Понятно, что PK, тем более суррогатный тут не кандидат... Примерно те же слова есть и в BOL. Кластерный индекс в первую очередь хорош для данных идущих подряд, а для PK можно и покрывающий индекс соорудить. Хотя конечно же надо каждый случай отдельно рассматривать.
Вот еще, ну просто мои слова :
Rick Sawtell, Michael Lee, Matt Bridges, with Victor Isakov
Chapter 4 from SQL Server 7, 24 seven, published by Sybex, Inc.
Although SQL Server Primary Keys are associated with clustered indexes by default, these are often poor choices for clustered indexes. The maximum performance advantage from a clustered index comes when selecting ranges of data. Primary Keys, when included in a WHERE clause, are usually not selected in ranges.
Ну и наконец Kalen Delaney, большего англоязычного авторитета по MSSQL-ю сложно найти
Clustered indexes are extremely useful for range queries (for example, WHERE sales_quantity BETWEEN 500 and 1000) and for queries in which the data must be ordered to match the clustering key. Only one clustered index can exist per table, since it defines the physical ordering of the data for that table. Since you can have only one clustered index per table, you should choose it carefully based on the most critical retrieval operations. Because of the clustered index's role in managing space within the table, nearly every table should have one. And if a table has only one index, it should probably be clustered.
If a table is declared with a primary key (which is advisable), by default the primary key columns form the clustered index. Again, this is because almost every table should have a clustered index, and if the table has only one index, it should probably be clustered. But if your table has several indexes, some other index might better serve as the clustered index. This is often true when you do single-row retrieval by primary key. A nonclustered, unique index works nearly as well in this case and still enforces the primary key's uniqueness. So save your clustered index for something that will benefit more from it by adding the keyword NONCLUSTERED when you declare the PRIMARY KEY constraint.
Все о том же: используйте кластерный индекс для упорядоченных данных и для диапазонных запросов, а с PK и обычный индекс неплохо справляется.
Здравствуйте, VladD2, Вы писали:
VD>Только по-твоему. VD>Объясни тогда почеиму когда создаешь ПК на таблице mssql автоматом делает кластерный индекс? Они по твоему вредительством занимаются? VD>И вообще, можно хоть какие-то доказательства верности твоей теории? Ну, ссылки, результаты тестов... Re[13]: GUID и кластерны
Ну, и что? Разумные слова про то, что кластерные индексы выгодны при последовательной выборке еще не означают, что они плохи для ПК. Если 90% времени ты дергаешь таблицу по одному индексу, то логично будет сделать его кластерным. Но если таблица постоянно идет через джоин, то как раз ПК самый лучший выбор. Кластреные индексы не только ускоряют последовательную выборку. Они ускоряют и вообще выбогрку по индексу, так как не нужно лазить по таблице.
В общем, ты уже переключился с обсуждения своий идеи о выгодности GUID и теперь еще раз переключаешся. Ты все же сделай тест GUID vs. int+identity, а там уже осудим его результаты.
Я тебе с тем же успехом могу надыбать кучу цитат о выгодности identity в качестве ПК.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
VD>>Ссылки, плиз. Вот перевод МС-ного мануала: VD>>http://www.optim.ru/cs/1999/2/sql7architecture/sql7architecture.asp M>Это мануал MSSQL 7.0, в 2000 все поменяли. В семерке действительно была физическая упорядоченность, в 2000 от нее отказались.
Никаких существенных изменений с тех времен не было. Этот же мануал лежит в BOL-е от 2000-ого.
M>Re[11]: GUID и кластерны
Здравствуйте, Lexey, Вы писали:
M>Кластеризации по неуникальному полю вообще не бывает. Сервер все равно сделает кластерный индекс уникальным.
Но все же кластерый индекс можно создать и по неуникальному полю.
M> Вот ты все про бизнес логику. А с чего ты решал, что бизнес-логике нужны именно такие запросы. Да, такие запросы бывают, но в тех базах, с которыми я работал, они составляли от силы процентов 30. И грузили они сервер не очень сильно. А основная нагрузка шла на join'ы, которые как раз и делаются по identity и напрямую выигрывают от его кластеризации.
Вот именно. Причем чем более хорошо спроектирована БД, тем больше джоинов.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
L>> Да, такие запросы бывают, но в тех базах, с которыми я работал, они составляли от силы процентов 30. И грузили они сервер не очень сильно. А основная нагрузка шла на join'ы, которые как раз и делаются по identity и напрямую выигрывают от его кластеризации. M>Что-то с трудом верится... У вас все таблицы с отношением один к одному? Или при выборке из подчиненной в большинстве случаев FK не учавствует?
А сколько ФК можно кластеризовать на одной таблице? И как будет делаться поиск строки на втором и третьем ФК? Ну, и какова вероятность, что выборка будет всегда идти по тому первому ФК что оказался кластерным?
В общем, еще раз. Тесты в студию.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
VD>>Что уж МС называет физическим порядком решать тебе. M>Ну, пример того как на самом деле поступает сервер с кластерным индексом я уже привел... Глазам своим не веришь?
Ничего такого втом что ты привел нет. По крайней мере твои выводы точно с этих данных делать нельзя. А вот твои утверждения противоречат другим твоим же. В честности твоя идея о непоследовательности как-то плохо стэкуется с мыслью о том, что скорость последовательной выборки из кластерный индексов высокая.
VD>>Но как минимум записи в странице точно упорядочены. Или это уже не индекс. M>Ничего они не упорядочены, точнее упорядочены логически.
Гы.
1. Где подтерждение этому? Опровержение вроде постоянно появляются. Да и логике это противоречит. Индекс есть индекст. Его записи обязаны быть упорядочены.
2. Какя разница как физически что-то реализовано? Главное, что нет нужны заниматься сортировкой при считывании данных или заниматься не эффективным последовтельным перебором для поиска записи. Один фиг страница с большой вероятностью попадет в кэш процессора, а значит скорость будет приблизительно одинакова.
M> Какой смысл в физическом упорядочивании, если с диска поднимается вся страница за раз?
Не делать сотрировки при чтении. Это между прочем не быстрая операция. Вот какой смысл хранить данные неупорядоченно в индеске? Это действительно маразм. Как минимум нужно хотя бы сделать микро-индес внутри страницы.
M>Достаточно гарантии того, что не придется прыгать из середины на другую страницу за следующей записью, эта гарантия есть, а больше ничего кластерный индекс не гарантирует, ну кроме того, что страницы будут сканироваться в логическом порядке, по указателям PrevPID, NextPID.
Почитай какова будет стоимость поиска в линейном списке на одной странице, умож это число на количество считываемых страниц и получишь велечину бессмысленных накладных разсходов.
M>Делал неоднократно, в различных вариантах, для различных задач. Результаты примерно такие: При интенсивной вставке из параллельных транзакций в табличку с кластерным/некластерным guid'ом/identity индексом, разницы между guid и identity практически нет.
Я вот видил вставку из одноко потока. И разница была очень явная.
M> Выборка сильно зависит от ситуации, но в среднем колеблется от 5 до 20% в пользу identity, когда количество записей приближается к нескольким миллионам.
Ну, и что ты доказываешь? Или ГУИД-ы "рвануть" на выборке?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Merle, Вы писали:
VD>>Объясни тогда почеиму когда создаешь ПК на таблице mssql автоматом делает кластерный индекс? Они по твоему вредительством занимаются? M>Потому что MS разрабатывался так, чтобы работать даже в кривых руках, и даже у людей, которые вообще не знают что такое индекс. А поскольку хоть какой-то кластерный индекс лучше, чем отсутствие кластерного индекса вообще, то они и лепят его по умолчанию на PK, чтобы не промазать.
Ну, и тестовые БД в них тоже криворукие делали?
VD>>Любоая. Если на таблице нет кластеного уникального индекса, то любая ссылка будет букмарком, т.е. все индексы будут содержать букмарки в качестве идентификаторов строк. Если же на таблице есть уникальный кластерный индекс (УКИ), то в индексах будет использоваться именно он (см. BOL). M>Все немного не так. M>Для того что бы не было букмарков уникальности от кластерного индекса не требуется, сервер сам обеспечит эту уникальность если создать кластерный индекс по неуникальному полю, добавив в ключ числовой идентификатор.
Предположим так. Какого по твоему мнению будет размер такоего составного ключа? И насколько он окажется эффекнивнее при лукапе чем кластерный индекс по уникальному поли целого типа?
M> Но физически одинаковые записи окажутся рядом, на одной или соседних страницах, собственно ради этого все и затевается. Так что букмарка не будет по любому, при поиске по полю с кластерным индексом, в не зависимости от того уникально это поле или нет.
Блин. Да раз в год по праздникам может оказаться нужно последовательно сканировать таблицу. А джоины делать нужно постоянно. И что будет эффекнивнее? Оптимизировть один запрос с сортировкой по полям совпадающим с КИ или десяток не совпадающих?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Предположим так. Какого по твоему мнению будет размер такоего составного ключа?
Не на много больше чем обычного.
VD>И насколько он окажется эффекнивнее при лукапе чем кластерный индекс по уникальному поли целого типа?
При лукапе чего? Тут все от запросов зависит.
VD>Блин. Да раз в год по праздникам может оказаться нужно последовательно сканировать таблицу.
Ха, раз в год. сканировать куски таблицы и выбирать диапазоны приходится гораздо чаще и запросы эти самые критичные.
VD> А джоины делать нужно постоянно.
Джойны тоже разные бывают и в большинстве случаев это все тоже сканирование диапазона.
Здравствуйте, VladD2, Вы писали:
VD> Но если таблица постоянно идет через джоин, то как раз ПК самый лучший выбор.
Джоин чего? джойны тоже разные бывают, и как правило джойнится все тот же диапазон.
VD> Кластреные индексы не только ускоряют последовательную выборку. Они ускоряют и вообще выбогрку по индексу, так как не нужно лазить по таблице.
Правильно, но при выборке по диапазону лазить по таблице приходится гораздо дольше и потери в этом случае гораздо больше — как правило это самое узкое место, поэтому оно и является первым кандидатом на затыкание кластерным индексом.
VD>В общем, ты уже переключился с обсуждения своий идеи о выгодности GUID и теперь еще раз переключаешся.
Я не переключаюсь, я обсуждаю два, довольно мало связанных вопроса.
VD>Я тебе с тем же успехом могу надыбать кучу цитат о выгодности identity в качестве ПК.
Ну надыбай. Просто просмотрел первые попавшиеся статьи и книги у меня на диске, пока время было, все пишут о том, что PK вовсе не первый кандидат на кластеризацию.
Здравствуйте, VladD2, Вы писали:
VD>Никаких существенных изменений с тех времен не было.
Ну так, Storage Engine периписали, оптимизатор переписали, а больше действительно, особо серьезных изменений не было..
VD>Где там тесты?
Там показано, что реально кластерный индекс ничего физически не упорядочивает.
Мы уже победили, просто это еще не так заметно...
