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

Откуда:
Сообщений: 34
Доброго всем дня.
Итак имеем:
Объекты, с которых пишем данные.
Типов объектов несколько.
Экземпляров объектов каждого типа от одного до больше сотни.
Данные от каждого объекта поступают раз в секунду. Параметров в каждой посылке (записи в БД) несколько сотен.
В каждом объекте есть подобъектик, имеющийся во всех типах этих объектов.
В каждой посылке всегда есть данные от этого подобъектика. А вот остальные данные редко, но могут отсутствовать.

Структура обсуждалась тут: https://www.sql.ru/forum/1074379/bd-dlya-obektov-s-raznym-kolichestvom-parametrov?hl=

В итоге имеем таблицы:
1. Общая (Common).
В ней ID свой, ID экземпляра объекта (ObjectID), время измерения (DT) и та самая пара десятков параметров, общих для всех объектов.
2. Таблицы экземпляров объектов (Object1 ... ObjectN).
В ней ID свой, ID записи в таблице Common и огромная куча своих параметров.

Делаю для каждого экземпляра объекта свой вьюшник (View1 ... ViewN). Индексированный - материализованный.
В него будет включены ObjectID, DT, несколько полей из Common и несколько полей из Object(i). Необходимые для обработки.
Поля в дальнейшем, по необходимости, могут добавляться.

1-й вопрос. Поля ID из Common и ID и CommonID из Object(i) не включал в таблицу. Правильно ли это?
Понимаю, что они как бы и ни к чему. Но все равно, как-то не привычно )))

Пара ObjectID и DT уникальны. И по ним же в абсолютном большинстве случаев будет проводиться выборка.
Тип первого bigint, второго datetime.
Количество записей в представлении на данный момент видится вплоть до десятков - около сотни миллионов.

2-й вопрос. Нормально ли сделать кластеризованный индекс по ним?
Пробовал сделать ID. По нему кластеризованный индекс. А по связке ObjectID и DT - некластеризованный.
Но что-то мне план выполнения не понравился. Делает Seek по некластеризованному индексу, а потом скан по кластеризованному.
В варианте же составного индекса просто делает seek по нему.

Или я что-то неправильно понимаю?
12 дек 14, 10:52    [16987224]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
автор
Делает Seek по некластеризованному индексу, а потом скан по кластеризованному.


Возможно, что индекс не обеспечивает покрытие.
12 дек 14, 13:13    [16988377]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
zenk
Member

Откуда: Москва
Сообщений: 115
Если честно, то я побоялся бы строить кластерный индекс на таблицах с относительно активным добавлением, когда структура индекса не следует за физическим порядком добавления записей в таблицу.

Возможно, вместо индексированных VIEW стоит попробовать индексы с INCLUDE.
12 дек 14, 13:43    [16988564]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
zenk
Если честно, то я побоялся бы строить кластерный индекс на таблицах с относительно активным добавлением, когда структура индекса не следует за физическим порядком добавления записей в таблицу.

Добавление идет не по записи, а из файлов. Т.е. порциями от 10 до ... наиболее часто - 300 записей (5 минут). Хотя и часовые встречаются бывает.
Т.е. мы сразу добавляем N-ное количество записей для экземпляра объекта (ObjectID), при этом все эти записи уже отсортированы по времени (DT).
В таблицы вставка идет с.о.:
1.По очереди insert-ы в Common с получением каждого InsertIdentity.
Одновременно с этим готовится файл под bulk insert.
2. bulk insert в Object(i).
Я не знаю, как построена технология добавления индексированных представлений, но пока bulk не будет выполнен, то не получится inner join для вьюшника. Т.е. новая "готовая порция" данных для вставки во вьюшник опять-таки относится к одному ObjectID и упорядочена по DT.
zenk
Возможно, вместо индексированных VIEW стоит попробовать индексы с INCLUDE.

Думал. Но слишком пока трудно спрогнозировать количество и длину (количество полей include) таких индексов.
И первое и второе грозит в перспективе разрастись до неприличных размеров :(
12 дек 14, 14:03    [16988714]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
zenk
Member

Откуда: Москва
Сообщений: 115
Vladimir A.K.,

автор
Пара ObjectID и DT уникальны. И по ним же в абсолютном большинстве случаев будет проводиться выборка.


В таком случае почему бы не попробовать кластерный индекс по паре ObjectID и DT?
Какие запросы будут в основном – точечные по одному точному моменту времени или интервальные?

Кстати, а зачем для ObjectID использовать BIGINT?
Неужели число каналов столь велико?
На первый взгляд, даже SMALLINT может потянуть.
12 дек 14, 16:20    [16989882]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
zenk
В таком случае почему бы не попробовать кластерный индекс по паре ObjectID и DT?

Вот его и пробую.
zenk
Какие запросы будут в основном – точечные по одному точному моменту времени или интервальные?

В основном интервальные.
zenk
Кстати, а зачем для ObjectID использовать BIGINT?
Неужели число каналов столь велико?
На первый взгляд, даже SMALLINT может потянуть.

Объяснить, кроме того, что писал я в пятницу во второй половине дня, мне этот ляп нечем :)
На самом деле изначально сделал INT. Но буду переделывать в SMALLINT. Его - за глаза.
Просто сейчас пытаюсь тестировать на десктопе "скорострельность" в "ухудшенных условиях".
И INT оставил и индексированное представление у меня включает все поля из двух таблиц. Пущай пашет по полной.
Тяжело в ученье - легко в бою :)
15 дек 14, 12:03    [16998005]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
zenk
Member

Откуда: Москва
Сообщений: 115
Vladimir A.K.,

zenk
На первый взгляд, даже SMALLINT может потянуть.


Вы только не очень мне верьте, проверьте этот факт, и лучше запасом в несколько раз на рост системы.

А скан по кластерному индексу – это наверняка выборка каких-то иных полей из View, вы же наверняка не только ObjectID и DT выбирали?

У вас «широкая» таблица (View), на 1 странице данных умещается мало строк.
Оптимизатор посчитал, что эффективнее сначала найти ключ данных по компактному обычному индексу, а уже потом просмотреть нужную страницу кластерного индекса, то есть фактически все данные.
15 дек 14, 16:07    [16999740]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
zenk
Вы только не очень мне верьте, проверьте этот факт, и лучше запасом в несколько раз на рост системы.

Мысль эта и раньше бродила в голове, но казалась до сего момента не существенной.
Но Ваша подсказка видится очень здравой. Добавление новых ObjectID в БД планируется не больше пары-тройки сотен в год.
Так что спасибо за наводку :)
zenk
А скан по кластерному индексу – это наверняка выборка каких-то иных полей из View, вы же наверняка не только ObjectID и DT выбирали?

Именно так. Сами по себе эти два поля, без других полей, имеют ценность, в пределе стремящуюся к нулю.
zenk
У вас «широкая» таблица (View), на 1 странице данных умещается мало строк.
Оптимизатор посчитал, что эффективнее сначала найти ключ данных по компактному обычному индексу, а уже потом просмотреть нужную страницу кластерного индекса, то есть фактически все данные.

И-и-и? Это лечится? Или кластерный сдвоенный ключ оптимальней?
15 дек 14, 16:36    [17000002]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
zenk
Member

Откуда: Москва
Сообщений: 115
Vladimir A.K.,

У вас ничего лечить не надо, выборка данных происходит оптимально.

Помните, что представление может включать не более 1024 столбцов.

Надеюсь, что между каждая строка базовой таблицы соответствует одному, и только одному индексированному представлению?
15 дек 14, 17:03    [17000229]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
zenk
Vladimir A.K.,
У вас ничего лечить не надо, выборка данных происходит оптимально.

Спасибо.
zenk
Помните, что представление может включать не более 1024 столбцов.

К стыду своему, даже не знал об этом :(
Запомню. Ибо "невер сэй невер".
zenk
Надеюсь, что между каждая строка базовой таблицы соответствует одному, и только одному индексированному представлению?

Угу.
Только одному :)
16 дек 14, 10:17    [17002846]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Время идет.
Базенка растет и пополняется.
Встал вопрос об ее усечении. Удалении устаревших данных.

Пока пытаюсь делать так:
declare @CurrTime datetime
select @CurrTime = DATEADD(day, -30, getdate())

delete from Object1 where CommonID in
(select ID from Common 
	where MeasDateTime < @CurrTime
	and SectionID in (select ID from ... )) -- тут идет подзапрос выборки ID-шников экземпляров объекта с типом Object1

delete from Common 
	where MeasDateTime < @CurrTime
	and SectionID in (select ID from ... )) -- тут идет подзапрос выборки ID-шников экземпляров объекта с типом Object1


Т.е. запоминаем дату (-30 дней относительно текущей), с которой идет сравнение в запросе. Сделано, что бы в двух DELETE была одна и та же дата.
Потом удаляем данные в таблице с эксклюзивными данными для типа объекта 1.
После этого удаляем данные из общей таблицы для этого типа объекта.
Очень не нравится, что приходится фактически дважды делать одну и ту же выборку из таблицы Common.

Может есть иные, более красивые и правильные варианты?

Может сливать запрос
select ID from Common 
	where MeasDateTime < @CurrTime
	and SectionID in (select ID from ... )

во временную таблицу, а потом уже удалять из двух таблиц, делая выборку из временной?
А после этого чистить и временную.
12 янв 15, 15:04    [17106305]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Vladimir A.K.
Может сливать запрос
select ID from Common 
	where MeasDateTime < @CurrTime
	and SectionID in (select ID from ... )


во временную таблицу, а потом уже удалять из двух таблиц, делая выборку из временной?

А это позволит в 2х командах delete не обращаться к этой временной таблице дважды ?
12 янв 15, 15:07    [17106321]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Glory
А это позволит в 2х командах delete не обращаться к этой временной таблице дважды ?

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

Тут еще мысль пришла. А может подзапрос делать по индексированным вьюверам?
Они же уже отсортированы (кластерный индекс) по SectionID, MeasDateTime. Добавлю туда поле CommonID и по нему будет подзапрос.
Есть шанс на ускорение процесса?
12 янв 15, 15:23    [17106435]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Vladimir A.K.
Но в этой таблице количество строк будет не больше, чем количество удаляемых строк.
А в подзапросе мы выбираем из очень большой таблицы.

И по плану вы увидели, что выбираются все записи из большой таблицы ?
12 янв 15, 15:24    [17106443]     Ответить | Цитировать Сообщить модератору
 Re: Индексированное представление. Кластеризованный индекс и другие вопросы.  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Glory
И по плану вы увидели, что выбираются все записи из большой таблицы ?

Ну да - шарики за ролики поехали.
Спасибо.
12 янв 15, 15:39    [17106538]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить