| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
 Индекс для inmemory таблицы
|
|
|
ustass Member Откуда: МО Сообщений: 197 |
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 Откуда: Сообщений: 699 |
ustass, 1. на чем основаны подозрения? 2. для подсчёта количества значений по фильтру разве выборки делать не надо? |
| 15 мар 19, 13:05 [21833667] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
Владислав Колосов Member Откуда: Сообщений: 6399 |
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 Откуда: Казань Сообщений: 123 |
так делать не надо) надо делать oltp-триггер на вставку и в нем танцевать глобальные переменные для этих двух счетчиков можно держать тоже в топ-таблицах, их обновлять там просто одна строка в каждой из одного столбца) хотя вопрос про глобальные переменные дискуссионный тут отдельную ветку вроде даже видел или еще где-то, не найду теперь) ну там ничего сверхъестественного табличка из имени и значения, обертка к ней функциями set и get ну сейчас это можно сделать связкой топ-псск еще вариант - отправка сообщений через service broker блин, так и не найду))) целая статейка потерялась)) на самом деле возможные сценарии могут быть лучше реализованы просто через джоб там в цикле дергать псск и waitfor ждать немного (если надо) |
| 16 мар 19, 10:08 [21834496] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
перепутал, там про массивы и списки но про переменным тоже можно)) https://www.sql.ru/articles/mssql/03060701arraysandlistsinsqlserver.shtml#fixed-length |
| 16 мар 19, 10:33 [21834497] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
но что-то service broker не очень, говорят https://dba.stackovernet.com/ru/q/32976 |
| 16 мар 19, 11:00 [21834504] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
ну и, конечно, можно заморочиться на columnstore index если на триггеры не уходить на таких задачах где нужно на точное сравнение искать - рекомендовано только почему-то нужно всё равно ещё задать хэш/ренж индекс почему - понятно, записи идентифицировать в операциях но какого черта))) есть же индекс))) в итоге от затрат на обновление этого второго индекса не уйти вроде бы (я наглотался всего этого за последние дни, могу подглючивать) |
| 16 мар 19, 11:07 [21834506] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
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 Откуда: МО Сообщений: 197 |
Отвечаю всем сразу. 1.inmemory дают огромное преимущество при массовых вставках в нескольких потоках параллельно особенно если не сохранять данные на диск. 2.Выборка из памяти, особенно если данные в памяти занимают 80-120мб то же будет не медленнее чем с диска. 3.Я не уточнял процесс поэтому просто скажу, что все предложения с триггерами, брокерами,.. не имеют смысла. 4. На той нагрузке, которую я сейчас могу сгенерировать обе версии индекса ведут себя одинаково. Вопрос к тем кто работал с данным решением. И вопрос именно тот, что озвучен в теме первого сообщения. |
| 18 мар 19, 10:28 [21835643] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
ustass, ну хэш то вообще оптимален для уникальных значений для неуникальных сервер делает список, по которому потом гуляет и считает встречал вариант триггера-счетчика, который просто в отдельной табличке держит итог и меняет его на каждую операцию также можно держать вью, и вроде как сервер будет рилтайм поддерживать там актуальные значения сам из остального - если попробуете, то напишите итог попробовать сделать составной ключ по нужному полю и ещё одному, желательно уникальному SELECT COUNT(DISTINCT `field_1`) FROM `table` where K=@k ну это предположительно чушь, но вдруг все просмотрели)) кроме того, можно предложить вести две таблицы, и брать из каждой число записей как-нибудь быстро https://stackoverflow.com/questions/6069237/fastest-way-to-count-exact-number-of-rows-in-a-very-large-table/17386344 особенно креативно там ближе к концу параллельно запросы по интервалам индекса ну в рассматриваемом случае тоже можно иметь составной индекс и кататься по нему по сути этой идеей можно озадачить сам сервер для этого надо построить составной индекс с существенной сегментацией исходного поля то есть второе поле ключа должно иметь большое количество уникальных значений не могу сказать хорошо ли будет, чтобы оно было уникальным но идея в том, чтобы сервер пошел гулять по ветвям индекса параллельно может же такое быть, что имея список значений ключей - он не бьет его на части сам? хотя если этот список неупорядочен - так и происходит, видимо если покрытие @r1 и @r2 существенное, то есть остальных записей записей немного - то лучше сразу две суммы считать select (case when K1=@r1 then 1 else 0 end) as a, (case when K2=@r2 then 1 else 0 end) as b при наличии нужного индекса пройдет параллельно можно попробовать брать разные поля для второй части индекса и выбрать как быстрее |
| 26 мар 19, 14:55 [21843839] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
ну то есть он по списку записей будет одинаково гулять считать и в случае с хеш-индексом и в случае некластеризованного и там будет одинаковое содержимое, видимо )) |
| 26 мар 19, 14:59 [21843849] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
про две таблицы в одной держать всё с K1=@R1 считать K2=@r2 придется всё равно по двум таблицам... или вторую тоже разбить на две)) но по первой считать с вторым фильтром всё равно надо думаю, вью с подходящим индексом будет хорошо особенно индексированное вью https://docs.microsoft.com/ru-ru/sql/relational-databases/views/create-indexed-views |
| 26 мар 19, 15:14 [21843879] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
dklim.kzn Member Откуда: Казань Сообщений: 123 |
ну собственно вот и рекомендация когда то я её читал наверное ))) https://docs.microsoft.com/ru-ru/sql/relational-databases/in-memory-oltp/indexes-for-memory-optimized-tables?view=sql-server-2017#duplicate-index-key-values |
| 26 мар 19, 15:32 [21843922] Ответить | Цитировать Сообщить модератору | |
| Re: Индекс для inmemory таблицы
|
|
|
a_voronin Member Откуда: Москва Сообщений: 3883 |
ustass, попробуйте колумнстор |
| 27 мар 19, 14:15 [21845091] Ответить | Цитировать Сообщить модератору | |
| Все форумы / Microsoft SQL Server | |
|
x