О, всезнающий All,

Есть MSSQL 2008, на нем база, в ней таблица. В нее пишется информация о различных событиях с интервалом в час.
Структура примерно такая:

id int, dimension1 int, dimension2 int, dimension3 int, timerecorded datetime, <разные полезные данные по event'у>

Комбинация dimension1, dimension2, dimension3, timerecorded всегда уникальна.
В пределах же комбинации dimension1, dimension2, dimension3 находится серия записей о событиях. Этакая эмуляция куба.
Наиболее частая выборка — как раз получить значения из dimension1, dimension2, dimension3 за какой-то период времени.

Я сделал clustered index на dimension1, dimension2, dimension3 и простой индекс на timerecorded. Это вообще жизнеспособно?
После внедрения такой структуры все стало работать очень быстро (в таблице около 500 млн. записей).
Через неделю (добавляется около 10000 записей в час) появились проблемы с быстродействием. Причину пока не выяснил, но есть подозрения, что это из-за моей модификации.

Может, правильнее сделать как-то иначе?

Спасибо!

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

S>О, всезнающий All,

S>Есть MSSQL 2008, на нем база, в ней таблица. В нее пишется информация о различных событиях с интервалом в час.
S>Структура примерно такая:

S>id int, dimension1 int, dimension2 int, dimension3 int, timerecorded datetime, <разные полезные данные по event'у>

S>Комбинация dimension1, dimension2, dimension3, timerecorded всегда уникальна.
S>В пределах же комбинации dimension1, dimension2, dimension3 находится серия записей о событиях. Этакая эмуляция куба.
S>Наиболее частая выборка — как раз получить значения из dimension1, dimension2, dimension3 за какой-то период времени.

S>Я сделал clustered index на dimension1, dimension2, dimension3 и простой индекс на timerecorded. Это вообще жизнеспособно?
S>После внедрения такой структуры все стало работать очень быстро (в таблице около 500 млн. записей).
S>Через неделю (добавляется около 10000 записей в час) появились проблемы с быстродействием. Причину пока не выяснил, но есть подозрения, что это из-за моей модификации.


Быстро стало работать скорее всего из-за индекса по timerecorded.

Кластерный индекс у вас по идее там должен быть по ID, по dimension1..N делать его ну совсем не надо. И вы точно уверены, что индекс именно кластерный и именно по dimension1,2,3?

Потом, какого рода проблемы появились? при каких запросах, каков план?

Потом, ссылки на строки вам часто нужны, например, join с ней по id и подобное? Если нет — то кластерный индекс нужен как раз по времени

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

S>После внедрения такой структуры все стало работать очень быстро (в таблице около 500 млн. записей).
S>Через неделю (добавляется около 10000 записей в час) появились проблемы с быстродействием. Причину пока не выяснил, но есть подозрения, что это из-за моей модификации.

А вы обслуживание индексов и статистики проводите?

А насчет жизнеспособности — зависит от множества факторов. Однозначного сферического ответа нет.

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

>Может, правильнее сделать как-то иначе?

1) За какие периоды обычно делаются выборки?
2) Насколько много этих "разных полезных данных по event'у"? Желательно в байтах.

Пока что мне кажется, что стоит попробовать обычный индекс по (timerecorded, dimension1, dimension2, dimension3).
timerecorded с интервалом в час должно обеспечить неплохую кластеризацию.

On 09.06.2011 8:01, Scrambler wrote:
> Наиболее частая выборка — как раз получить значения из dimension1, dimension2,
> dimension3 за какой-то период времени.

Так для периода условие по timerecorded используется ?
Тогда нужно бы timerecorded как раз в этот твой clustered index добавть в конец,
а не делать отдельный.

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

MZ>Так для периода условие по timerecorded используется ?
MZ>Тогда нужно бы timerecorded как раз в этот твой clustered index добавть в конец,
MZ>а не делать отдельный.

А зачем в конец?

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

Ну Вы с индексами-то поосторожней

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

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

JR>Ну Вы с индексами-то поосторожней

Это в КУ надо)

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

S>Я сделал clustered index на dimension1, dimension2, dimension3 и простой индекс на timerecorded. Это вообще жизнеспособно?

я так понимаю, что ключ у тебя в итоге не растёт гладко и серверу постоянно надо будет этот индекс перестраивать, из-за того что для d1/2/3 пришли новые записи.

Кластерный здесь как корове седло.