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

Откуда:
Сообщений: 75
Есть таблица, которая представляет собой данные с электросчетчиков :
CREATE TABLE [dbo].[Summary](
	[CounterID] [int] NOT NULL,	
        [Time] [smalldatetime] NULL,	
	[Value] [float] NULL,
        [Status] [int] NOT NULL
	еще поля
)
Данные попадают блоками из разных источников, однако, хронология по времени обычно нарастает, другое дело что мы можем сначала по одному получить 1000 записей по одному счетчику, потом 300 по-другому. Выборка идет обычно для 1-20 счетчиков за один и тот же период. Т.е., счетчики номер 1212,231312,131231 за февраль 2010.

Размышляю над вопросом, в каком порядке лучше создать кластерный индекс (эти поля одновременно будут ПК):
а) CounterID, Time
б) Time, CounterID
Важнее скорость селектов, нежели скорость вставки.
Перестраивать индексы часто не получится (раз в месяц максимум), объем базы большой
Селективность по полю Time, конечно, выше, что вроде наталкивает на 2 вариант, но за период нужны не все счетчики, а лишь небольшая часть.
8 окт 11, 01:53    [11406419]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
darkexpert
Member

Откуда:
Сообщений: 75
В описании таблицы ошибка - поле Time NOT NULL :-)
8 окт 11, 01:55    [11406422]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
iljy
Member

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

скорее всего кластерный лучше по Time, CounterID. Возможно по CounterID, Time будет иметь смысл сделать простой индекс, возможно с включенными полями. Но реально надо просто проверять.
8 окт 11, 10:22    [11406671]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
mssql_developer
Member

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


Секционирование по time, кластерный по counter_id
8 окт 11, 11:59    [11406804]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31993
darkexpert
Селективность по полю Time, конечно, выше, что вроде наталкивает на 2 вариант, но за период нужны не все счетчики, а лишь небольшая часть.
Нужно смотреть на селективность по условиям запросов, а не на селективность самих данных.

Ну и о вставке не надо забывать - при кластерном индексе по CounterID, Time будет вообще мешанина в файлах.
darkexpert
Перестраивать индексы часто не получится (раз в месяц максимум)
вот и не надо будет перестраивать при индексе по Time, CounterID.
8 окт 11, 12:44    [11406880]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
darkexpert
Member

Откуда:
Сообщений: 75
alexeyvg
Нужно смотреть на селективность по условиям запросов, а не на селективность самих данных.
Ну и о вставке не надо забывать - при кластерном индексе по CounterID, Time будет вообще мешанина в файлах.

Запросов будет 2 типа: получение за интервал времени (основной) по нескольким счетчикам; поиск последнего значения (редко)
Почему мешанина будет? Time то ведь далеко не текущий, то есть сегодня я могу получить данные например за позапрошлый месяц. Если бы Time текущий был, то есть всегда увеличивался, тогда очевидно было бы сделать его первым, чтобы избежать фрагментации.
8 окт 11, 18:18    [11407270]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
Fire83
Member

Откуда: Гомель-Минск
Сообщений: 474
darkexpert,

При кластерном индексе
а) CounterID, Time
серверу придется при вставке данных постоянно трогать старые страницы потому как
данные относящиеся к одному счетчику физически хранятся рядом.

Если же
б) Time, CounterID

то с учетом что Time постоянно растет этого не будет.
Лучше все-таки наверное второй вариант для кластерного.
8 окт 11, 19:27    [11407407]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
darkexpert
Member

Откуда:
Сообщений: 75
Fire83
darkexpert,

При кластерном индексе
а) CounterID, Time
серверу придется при вставке данных постоянно трогать старые страницы потому как
данные относящиеся к одному счетчику физически хранятся рядом.

Ну это дело можно поправить FillFactor'ом меньше сотни. Скорость вставки не критична.
8 окт 11, 19:58    [11407463]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
iljy
Member

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

сами же говорите, что индексы часто перестраивать нельзя. А все добавление у вас идет близко к концу таблицы, так что подозреваю, что fillfactor вам только раздует таблицу, а от фрагментирования все равно особо не спасет.

Вы вообще проверили хоть приблизительно - есть повод для разговоров-то? Потому что решения могут быть самые разные, вплоть до отказа от кластерного индекса вообще.
8 окт 11, 20:13    [11407501]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
iljy
Member

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

или секционирование, тогда у вас фрагментироваться будет только хвост таблицы.
8 окт 11, 20:15    [11407506]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
clustered index
Guest
если вы будите делать запросы типа

select *
from Summary
where time >... and time <...
  and CounterID in (...)


то кластерный индекс Time, CounterID - бесполезен, точнее бесполезен в нем столбец CounterID, т.к. seek-а по нему не будет.
10 окт 11, 15:27    [11413564]     Ответить | Цитировать Сообщить модератору
 Re: Кластерный индекс, как лучше?  [new]
ZOOKABAKODER
Member

Откуда:
Сообщений: 178
В поле [Time] какой точности данные идут? Добавляются данные всегда за текущий день, как я понял, или могут подгрузить за прошлую неделю откуда-то? Насколько далеко идёт запрос по давности (За последний год, квартал, месяц?). {Time; Counter} уникальный?
10 окт 11, 17:29    [11414985]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить