Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 RID vs PK по identity  [new]
Kartas
Member

Откуда: Минск, Беларусь
Сообщений: 135
Доброго времени суток.

Есть MS SQL 2005:

автор
Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86) Nov 24 2008 13:01:59 Copyright (c) 1988-2005 Microsoft Corporation Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 3)


Есть таблица с PK bigint identity.

В таблицу идет массовая вставка записей и иногда массовое удаление записей по условию.
Условие по полю на котором есть индекс (datetime).

Так же на таблице присутствют друие индексы.

Селекты по таблице достаточно часто используют несколько индексов, полностью покрывающих условия в запросе.

Вопрос в следующем. Какова предпочтительная организация таблицы в этом случае - куча или кластерный индекс. кластер по другим полям невозможен - нет кандидатов да и уникальных наборов кроме identity тоже нету.

В общем случае при селекте будет идти сначала пересечение индексов, а затем лукап по RID или кластерному индексу.

задача ускорить селекты и не сильно просадить инсерты.

Гугл и эксперименты особой разницы между RID lookup и clustered index lookup не показывают в случае когда кластерный индекс не толстый. в конкретном случае - не толстый (bigint).

Второй вопрос - что же собстевнно есть этот RID? как понимаю это букмарка на место в куче, но в терминах типов данных что же это такое? GUID? комбинация страница/позиция?

просветите или пните в направлении плиз.

Спасибо.
5 окт 09, 19:01    [7744895]     Ответить | Цитировать Сообщить модератору
 Re: RID vs PK по identity  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5499
Блог
Kartas
Второй вопрос - что же собстевнно есть этот RID? как понимаю это букмарка на место в куче, но в терминах типов данных что же это такое? GUID? >>>комбинация страница/позиция?<<<
Выделен правильный вариант.
В случае, когда идут массовые удаления данных, без кластеризованного индекса я бы таблицу не оставлял - будут проблемы с фрагментацией.
Сравните варианты:
кластеризованный уникальный по дате+PK,
кластеризованный уникальный по PK,
кластеризованный неуникальный по дате.

Варианты дал в предполагаемом порядке "ухудшения". ;)

PS Вообще-то было бы неплохо видеть структуру таблицы и индексов, а также назначение поля "datetime"...
5 окт 09, 19:07    [7744917]     Ответить | Цитировать Сообщить модератору
 Re: RID vs PK по identity  [new]
Kartas
Member

Откуда: Минск, Беларусь
Сообщений: 135
DeColo®es,
спасибо за ответ.

по дате+PK сложно. Суть системы - хранение инфы о банковских транзакциях/балансах счетов/прочей банковсой лабуде. Инфа приходит из handoff-файлов внешних систем. Суть поля datetime - дата транзакции или дата баланса.

Чем плох кластер по дате - иногда данные за одну и ту же дату требуется перезаливать - слкдовательно кластер по дате+ПК - не очень хорошо себя поведет. Мало того, часто требуется хранить инфу "за один последний день месяца". Для текущего месяца это будут постоянные делиты/инсетры, которые приведут к жуткой логической фрагментации кластера. Поэтому для крастера видимый выход один - кластер по identity.

Я правильно понял что лучше кластер по bigint чем по RID "комбинация страница/позиция"?

таблицы показывать большого смысла нету - их много и они все разные. Суть системы - датамарт, который хранит инфу из файлов в удобном для использования внешним софтом виде (тобишь в реляционном).

Спасибо.
5 окт 09, 20:05    [7745097]     Ответить | Цитировать Сообщить модератору
 Re: RID vs PK по identity  [new]
Kartas
Member

Откуда: Минск, Беларусь
Сообщений: 135
Kartas

скип

Я правильно понял что лучше кластер по bigint чем по RID "комбинация страница/позиция"?

Спасибо.


сори, читать как "лучше иметь кластер по полю без бизнес-смысла, чем кучу" в вышеописанном случае.
5 окт 09, 20:10    [7745106]     Ответить | Цитировать Сообщить модератору
 Re: RID vs PK по identity  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5499
Блог
По моему опыту, как раз дата баланса - один из лучших кандидатов на первое поле в кластеризованных индексах. Не раз перестраивал индексы подобным образом и был доволен результатом. Что на сотнях тысяч записей, что на десятках миллионов.

Такой выбор ускоряет операции массовых выборок, экономит память, доводит эффективность упреждающих чтений до 100% и т.д., поскольку как правило все выбираемые данные относятся к одной дате и набору дат и на если уж при выборке понадобилась одна строка из таблицы, то и остальные тоже будут нужны.

Насчет фрагментации - не сильно мучайтесь, все равно при интенсивных вставках/удалениях еженедельная реиндексация актуальна, как чистка зубов. ;) А за счет экономии на выборках из малоизменяемой части таблицы можете выиграть гораздо больше, тем более сами пишите, что это - наиболее критично.

PS А что мешает попробовать?
5 окт 09, 20:54    [7745219]     Ответить | Цитировать Сообщить модератору
 Re: RID vs PK по identity  [new]
Kartas
Member

Откуда: Минск, Беларусь
Сообщений: 135
DeColo®es,

мешает любовь к теоретизированию :D и отсутствие сегодня под рукой системы. Завтра обязательно попробую предложеный Вами вариант.
6 окт 09, 00:12    [7745648]     Ответить | Цитировать Сообщить модератору
 Re: RID vs PK по identity  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10715
Блог
http://msmvps.com/blogs/gladchenko/archive/2009/09/28/1727878.aspx
6 окт 09, 11:43    [7746900]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить