Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
_Промешан_
Member

Откуда:
Сообщений: 969
Много где встречается идея, что GUID (через NEWID) для Clustered Index - плохо. А вот INT (identity increment) - очень хорошо.

Тут в коменте:
https://stackoverflow.com/questions/11938044/what-are-the-best-practices-for-using-a-guid-as-a-primary-key-specifically-rega


Дается везде некая общая информация и что то вроде "physical storage-related thing", когда говорится про Clustered Index.

Честно говоря не удалось найти какой-то теоретической аргументации по этому поводу.
Полез почитал про сбалансированные деревья, коим является кластеризованный индекс. И с этой позиции не понял, какая к черту разница, насчет GUID и INT... Один хрен при добавлении что в середину, что в конец - дерево будет многообразно перестраиваться.

А вот про доступ к памяти вообще ни слова - перезаписываются ли куски памяти в случае GUID в середину или нет - не понятно. Нигде про это ни слова (или я плохо гуглю).
14 мар 18, 02:40    [21254147]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36987
_Промешан_
Один хрен при добавлении что в середину, что в конец - дерево будет многообразно перестраиваться.
Это далеко не один хрен. Это очень разные хрены, я бы даже сказал.
_Промешан_
А вот про доступ к памяти вообще ни слова - перезаписываются ли куски памяти в случае GUID в середину или нет - не понятно. Нигде про это ни слова (или я плохо гуглю).
А вот тут как раз почти один хрен, ибо сервер оперирует страницами.
_Промешан_
Много где встречается идея, что GUID (через NEWID) для Clustered Index - плохо. А вот INT (identity increment) - очень хорошо.
Авторы сей идеи не пробовали интенсивно вставлять в конец любого инкрементального индекса хотя бы в 10 коннектов.
14 мар 18, 02:55    [21254150]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
_Промешан_,

Оно в определенной степени не лучше и не хуже.
Как по мне единственная проблема с identity increment это contention на последней странице при энтенсивной вставке, о чем говорит Гавриленко. Тут может помочь:
•Use a random Clustered Key value (like a UNIQUEIDENTIFIER). But be aware of the side-effects: larger logical pointer in EVERY Non-Clustered Index, Page Splits…)
•Implement Hash Partitioning, if you are using the Enterprise Edition of SQL Server.
•Eliminate latching through the use of In-Memory OLTP, that is part of SQL Server 2014.
•Use a so-called Reverse Index. Unfortunately SQL Server doesn’t provide you that kind of index out-of-the box, like Oracle. But you can implement it at your own…
Как и многое связанное с SQL здесь также можно сказать It depends...
Если вы будете бездумно добавлять везде GUID то можете получить сильную фрагментацию, Page Split, плюс это 16 байт, которые также будут в каждом некласт. индексе, а при использовании identity increment вы получите hotspot в виде последней стрницы. Я к чему, надо нагрузку знать знать на таблицу, только тогда можно что-то решать.
14 мар 18, 05:38    [21254161]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31367
_Промешан_
Полез почитал про сбалансированные деревья, коим является кластеризованный индекс. И с этой позиции не понял, какая к черту разница, насчет GUID и INT... Один хрен при добавлении что в середину, что в конец - дерево будет многообразно перестраиваться.
Ну, для GUID будет запись в разные страницы для каждой новой записи. Плюс время от времени расщепление страниц (в зависимости от филл фактора). А для INT запись будет последовательная, и только изредка будет перебалансировка, которая в общем тоже будет идти последовательно для перебалансированных узлов.

aleksrov добавил про случаи, когда GUID даёт более высокую производительность, но важно понимать, что она будет выше в абсолюте, то есть это позволит достичь максимума на очень мощном оборудовании. А для обычных серверов, когда дисков не больше нескольких сотен, это будет только замедлять.
14 мар 18, 09:25    [21254317]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
otdo
Guest
https://www.microsoft.com/en-us/download/details.aspx?id=26665
14 мар 18, 09:28    [21254330]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 5960
alexeyvg
Ну, для GUID будет запись в разные страницы для каждой новой записи. Плюс время от времени расщепление страниц (в зависимости от филл фактора).

И в случае NEWSEQUENTIALID тоже?
14 мар 18, 10:04    [21254435]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
aleks222
Guest
Сон Веры Павловны
alexeyvg
Ну, для GUID будет запись в разные страницы для каждой новой записи. Плюс время от времени расщепление страниц (в зависимости от филл фактора).

И в случае NEWSEQUENTIALID тоже?

Это неотличимо от int. Только длиннее.
14 мар 18, 10:19    [21254468]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
aleks222,

И только каждый раз новая последовательность при перезгрузке сервака. Из Bol:
Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique.
И
The UuidCreateSequential function has hardware dependencies. On SQL Server, clusters of sequential values can develop when databases (such as contained databases) are moved to other computers. When using Always On and on SQL Database, clusters of sequential values can develop if the database fails over to a different computer.

И раумеется использовать его для того чтобы убрать last page contention полностью бесмысленно ибо это практически тот же identity с определенными оговорками.
14 мар 18, 11:26    [21254756]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
_Промешан_
Member

Откуда:
Сообщений: 969
hotspot - это чем плохо?

А что если используется оборудование с flash?
14 мар 18, 15:26    [21255865]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
_Промешан_,

Не быстрые диски, не много памяти тут не помогут. В чем суть, это проблема возникает из-за латчей. Латчи это (вырезка из Internals 2016):
Latches are lightweight synchronization objects that protect the consistency of SQL Server internal data
structures. As the opposite of locks, which protect transactional data consistency, latches prevent the
corruption of the data structures in memory.
Consider a situation where multiple sessions need to update different rows on the same data page.
Those sessions would not block each other, because they don’t acquire incompatible locks on the same
objects. SQL Server, however, must prevent the situation where multiple sessions simultaneously update
a data page structure in-memory, making it inconsistent and corrupting it. Moreover, SQL Server needs to
prevent other sessions from accessing the data page structure at the time of modification. SQL Server uses
latches to achieve this.
When the thread cannot obtain a latch on the data structure, it is placed into the FIFO queue, where it
stays suspended - и вот здесь как раз возникает проблема. Хоть латчи и кратковременны, но когда множество потоков вставляют на одну и туже страницу это становится проблемой.
К примеру можете прочесть тут
14 мар 18, 17:39    [21256452]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
_Промешан_
Member

Откуда:
Сообщений: 969
aleksrov
_Промешан_,

Не быстрые диски, не много памяти тут не помогут. В чем суть, это проблема возникает из-за латчей. Латчи это (вырезка из Internals 2016):

А GUID такой проблемы не получают?
14 мар 18, 18:26    [21256617]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
_Промешан_,

Нет, но они получают другие проблемы, о которых было сказано выше. Вы похоже не читаете что вам пишут. Из ссылки которую я привел выше:
Another solution is to use a non-sequential key in order to load data all over the index and not only at the end of it. By doing this, we spread the load and not creating a hotspot. This sounds like a very bad idea at first, because it generates lots of page splits and fragmentation when inserting the data, but it turns out page splits are less problematic for insert performance than latch contention. Also, in order to limit the amount of fragmentation, you can work with a low fillfactor (even 10%), and by doing so, you basically create “buckets” that will be ready for each row, instead of generating fragmentation when the insert occurs. If you use this method, watch out for your table size, as it can make your table quite larger than in other methods.
14 мар 18, 18:37    [21256663]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
aleksrov
_Промешан_,

Нет, но они получают другие проблемы, о которых было сказано выше. Вы похоже не читаете что вам пишут. Из ссылки которую я привел выше:
Another solution is to use a non-sequential key in order to load data all over the index and not only at the end of it. By doing this, we spread the load and not creating a hotspot. This sounds like a very bad idea at first, because it generates lots of page splits and fragmentation when inserting the data, but it turns out page splits are less problematic for insert performance than latch contention. Also, in order to limit the amount of fragmentation, you can work with a low fillfactor (even 10%), and by doing so, you basically create “buckets” that will be ready for each row, instead of generating fragmentation when the insert occurs. If you use this method, watch out for your table size, as it can make your table quite larger than in other methods.

агнонь метод
для таблицы Id UNIQUEIDENTIFIER, Value Id филфактор сколько надо? 1? и диски подносить как дрова
14 мар 18, 18:42    [21256680]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
TaPaK,

Если честно прочел по диагонали этот абзац:) с fillfactor здесь конечно автор погаричился.
14 мар 18, 18:47    [21256694]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31367
TaPaK
для таблицы Id UNIQUEIDENTIFIER, Value Id филфактор сколько надо? 1? и диски подносить как дрова
Ну, баланс между местом и производительностью :-) Хотя ИМХО достаточно 50%

А диски нужны - да; так ведь такой подход менее производителен на единицу железа.
Это используется, что бы получить масштабирование по железу, и даже думать не надо о нём, если у вас число дисков не от тысячи.
14 мар 18, 19:55    [21256836]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
alexeyvg
TaPaK
для таблицы Id UNIQUEIDENTIFIER, Value Id филфактор сколько надо? 1? и диски подносить как дрова
Ну, баланс между местом и производительностью :-) Хотя ИМХО достаточно 50%

А диски нужны - да; так ведь такой подход менее производителен на единицу железа.
Это используется, что бы получить масштабирование по железу, и даже думать не надо о нём, если у вас число дисков не от тысячи.

так речь то в том что 50 не избавит от давления на последнюю страницу
15 мар 18, 09:57    [21257621]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31367
TaPaK
alexeyvg
пропущено...
Ну, баланс между местом и производительностью :-) Хотя ИМХО достаточно 50%

А диски нужны - да; так ведь такой подход менее производителен на единицу железа.
Это используется, что бы получить масштабирование по железу, и даже думать не надо о нём, если у вас число дисков не от тысячи.

так речь то в том что 50 не избавит от давления на последнюю страницу
для кластерного ПК по UNIQUEIDENTIFIER?
15 мар 18, 12:59    [21258333]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
alexeyvg
TaPaK
пропущено...

так речь то в том что 50 не избавит от давления на последнюю страницу
для кластерного ПК по UNIQUEIDENTIFIER?


CREATE TABLE (Id с, Value INT)


сами посчитаете длинну и сколько же на одну страницу влезет
15 мар 18, 13:03    [21258352]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
blonduser
Member

Откуда:
Сообщений: 132
_Промешан_,

Дело в том, что кластерный индекс физически располагает данные, согласно индексу.
Поэтому при "identity increment" данные всегда добавляются в конец таблицы и это происходит быстро.
Когда через NEWID, так как он не последовательный, данные добавляются в произвольное место таблицы ... скорость падает.
21 мар 18, 14:13    [21274475]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
blonduser
_Промешан_,

Дело в том, что кластерный индекс физически располагает данные, согласно индексу.
Поэтому при "identity increment" данные всегда добавляются в конец таблицы и это происходит быстро.
Когда через NEWID, так как он не последовательный, данные добавляются в произвольное место таблицы ... скорость падает.

это только для тех кто не знает про NEWSEQUENTIALID
21 мар 18, 14:38    [21274599]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31367
TaPaK
blonduser
_Промешан_,

Дело в том, что кластерный индекс физически располагает данные, согласно индексу.
Поэтому при "identity increment" данные всегда добавляются в конец таблицы и это происходит быстро.
Когда через NEWID, так как он не последовательный, данные добавляются в произвольное место таблицы ... скорость падает.

это только для тех кто не знает про NEWSEQUENTIALID
И для тех, кто не знает, когда вставка в произвольные места таблицы повышает производительность, про что, собственно, в этой теме только и говорили.
22 мар 18, 11:10    [21276517]     Ответить | Цитировать Сообщить модератору
 Re: Внятно объяснить, почему кластеризованный индекс по GUID хуже INT?  [new]
heavy-inserts
Guest
https://blogs.msdn.microsoft.com/blogdoezequiel/2013/05/23/pagelatch_ex-waits-and-heavy-inserts/
22 мар 18, 12:48    [21277016]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить