| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
 Индекс для inmemory таблицы
|
|
|
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 таблицы
|
|
|
andy st Member Откуда: Сообщений: 689 |
ustass, 1. на чем основаны подозрения? 2. для подсчёта количества значений по фильтру разве выборки делать не надо? |
| 15 мар 19, 13:05 [21833667] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
Владислав Колосов Member Откуда: Сообщений: 6271 |
ustass, сомневаюсь, что inmemory таблица даст выигрыш в расчете count(*). |
| 15 мар 19, 14:25 [21833870] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
AnyKey45 Member Откуда: Ekaterinburg-Moscow-EU Сообщений: 219 |
hash он для equal операций, в идеале ключ должен быть уникален, а у тебя тут море дубликатов раз ты count(*) считаешь range более похож на стандартный индекс дискковой таблицы - давно бы уже сам протестировал |
| 15 мар 19, 23:40 [21834414] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Сообщений: 15 |
так делать не надо) надо делать oltp-триггер на вставку и в нем танцевать глобальные переменные для этих двух счетчиков можно держать тоже в топ-таблицах, их обновлять там просто одна строка в каждой из одного столбца) хотя вопрос про глобальные переменные дискуссионный тут отдельную ветку вроде даже видел или еще где-то, не найду теперь) ну там ничего сверхъестественного табличка из имени и значения, обертка к ней функциями set и get ну сейчас это можно сделать связкой топ-псск еще вариант - отправка сообщений через service broker блин, так и не найду))) целая статейка потерялась)) на самом деле возможные сценарии могут быть лучше реализованы просто через джоб там в цикле дергать псск и waitfor ждать немного (если надо) |
| 16 мар 19, 10:08 [21834496] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Сообщений: 15 |
перепутал, там про массивы и списки но про переменным тоже можно)) https://www.sql.ru/articles/mssql/03060701arraysandlistsinsqlserver.shtml#fixed-length |
| 16 мар 19, 10:33 [21834497] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Сообщений: 15 |
но что-то service broker не очень, говорят https://dba.stackovernet.com/ru/q/32976 |
| 16 мар 19, 11:00 [21834504] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Сообщений: 15 |
ну и, конечно, можно заморочиться на columnstore index если на триггеры не уходить на таких задачах где нужно на точное сравнение искать - рекомендовано только почему-то нужно всё равно ещё задать хэш/ренж индекс почему - понятно, записи идентифицировать в операциях но какого черта))) есть же индекс))) в итоге от затрат на обновление этого второго индекса не уйти вроде бы (я наглотался всего этого за последние дни, могу подглючивать) |
| 16 мар 19, 11:07 [21834506] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
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 таблицы
|
|
|
AnyKey45 Member Откуда: Ekaterinburg-Moscow-EU Сообщений: 219 |
dklim.kzn, +1 действительно, не обратил внимания 1к+ транзакций, каждая делает count(*) по фильтру - тут никакой индекс не поможет |
| 16 мар 19, 21:49 [21834905] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
ustass Member Откуда: МО Сообщений: 196 |
Отвечаю всем сразу. 1.inmemory дают огромное преимущество при массовых вставках в нескольких потоках параллельно особенно если не сохранять данные на диск. 2.Выборка из памяти, особенно если данные в памяти занимают 80-120мб то же будет не медленнее чем с диска. 3.Я не уточнял процесс поэтому просто скажу, что все предложения с триггерами, брокерами,.. не имеют смысла. 4. На той нагрузке, которую я сейчас могу сгенерировать обе версии индекса ведут себя одинаково. Вопрос к тем кто работал с данным решением. И вопрос именно тот, что озвучен в теме первого сообщения. |
| 18 мар 19, 10:28 [21835643] Ответить | Цитировать Сообщить модератору | |
| Все форумы / Microsoft SQL Server | |
|
x