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

Откуда: МО
Сообщений: 196
SQL 2016 SP2. Есть inmemory SCHEMA_ONLY таблица. Планируется, что это будет постоянно пополняемая около тысячи вставок в секунду и периодическим удалением старых записей раз в 15 минут. В среднем количество записей колеблется между 1-2 млн.
Каждая вставка сопровождается вычислением количества значений для фильтра по одному полю: count(*) from table where K1=@R1 и count(*) from table where K2=@R2
Для каждого значения K1 в таблице присутствует 50-1000 значений, для K2 100-10000. В среднем для К1 около 100 значений, для К2 - 500 значений.
Вопрос - какие типы индекса hash или nonclustered больше подойдут для K1 и K2. Сейчас по каждому из полей построен hash индекс, но создается подозрение, что для К2 это не оптимально. К сожалению во всех статьях микрософта рассматривается выборка значений, а не подсчет количества значений по фильтру.
15 мар 19, 11:23    [21833454]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
andy st
Member

Откуда:
Сообщений: 689
ustass,
1. на чем основаны подозрения?
2. для подсчёта количества значений по фильтру разве выборки делать не надо?
15 мар 19, 13:05    [21833667]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
Владислав Колосов
Member

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

сомневаюсь, что inmemory таблица даст выигрыш в расчете count(*).
15 мар 19, 14:25    [21833870]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
AnyKey45
Member

Откуда: Ekaterinburg-Moscow-EU
Сообщений: 219
hash он для equal операций, в идеале ключ должен быть уникален, а у тебя тут море дубликатов раз ты count(*) считаешь
range более похож на стандартный индекс дискковой таблицы - давно бы уже сам протестировал
15 мар 19, 23:40    [21834414]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
dklim.kzn
Member

Откуда:
Сообщений: 15
так делать не надо)

надо делать oltp-триггер на вставку
и в нем танцевать

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

хотя вопрос про глобальные переменные дискуссионный
тут отдельную ветку вроде даже видел
или еще где-то, не найду теперь)

ну там ничего сверхъестественного
табличка из имени и значения, обертка к ней функциями set и get
ну сейчас это можно сделать связкой топ-псск
еще вариант - отправка сообщений через service broker
блин, так и не найду))) целая статейка потерялась))

на самом деле возможные сценарии могут быть лучше реализованы просто через джоб
там в цикле дергать псск и waitfor ждать немного (если надо)
16 мар 19, 10:08    [21834496]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
dklim.kzn
Member

Откуда:
Сообщений: 15
перепутал, там про массивы и списки
но про переменным тоже можно))

https://www.sql.ru/articles/mssql/03060701arraysandlistsinsqlserver.shtml#fixed-length
16 мар 19, 10:33    [21834497]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
dklim.kzn
Member

Откуда:
Сообщений: 15
но что-то service broker не очень, говорят

https://dba.stackovernet.com/ru/q/32976
16 мар 19, 11:00    [21834504]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
dklim.kzn
Member

Откуда:
Сообщений: 15
ну и, конечно, можно заморочиться на columnstore index
если на триггеры не уходить
на таких задачах где нужно на точное сравнение искать - рекомендовано

только почему-то нужно всё равно ещё задать хэш/ренж индекс
почему - понятно, записи идентифицировать в операциях
но какого черта))) есть же индекс)))

в итоге от затрат на обновление этого второго индекса не уйти вроде бы
(я наглотался всего этого за последние дни, могу подглючивать)
16 мар 19, 11:07    [21834506]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
dklim.kzn
Member

Откуда:
Сообщений: 15
https://docs.microsoft.com/ru-ru/sql/t-sql/statements/create-partition-function-transact-sql?view=sql-server-2017

вишенка на торте в конце холста
поделить лог на секции по одной на каждый день
ну а дальше раз в сутки жать всё предыдущее COLUMNSTORE_ARCHIVE

для идеальной суточной обработки не хватает лишь одного
чтобы одну секцию можно было обозвать активной
и чтобы тогда она была бы in memory
с oltp триггерами и прочей прелестью

впрочем, и сейчас можно соорудить нужное
топ-таблица на прием, по ней триггеры или джобы на перенос/копирование в секционированную архивную
16 мар 19, 12:29    [21834552]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
AnyKey45
Member

Откуда: Ekaterinburg-Moscow-EU
Сообщений: 219
dklim.kzn,
+1
действительно, не обратил внимания
1к+ транзакций, каждая делает count(*) по фильтру - тут никакой индекс не поможет
16 мар 19, 21:49    [21834905]     Ответить | Цитировать Сообщить модератору
 Re: Индекс для inmemory таблицы  [new]
ustass
Member

Откуда: МО
Сообщений: 196
Отвечаю всем сразу.
1.inmemory дают огромное преимущество при массовых вставках в нескольких потоках параллельно особенно если не сохранять данные на диск.
2.Выборка из памяти, особенно если данные в памяти занимают 80-120мб то же будет не медленнее чем с диска.
3.Я не уточнял процесс поэтому просто скажу, что все предложения с триггерами, брокерами,.. не имеют смысла.
4. На той нагрузке, которую я сейчас могу сгенерировать обе версии индекса ведут себя одинаково.
Вопрос к тем кто работал с данным решением.
И вопрос именно тот, что озвучен в теме первого сообщения.
18 мар 19, 10:28    [21835643]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить