|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983 Кластерный индекс еще делается, уже 12 часов... файл БД +60 GB Процесс активен и файл БД растет периодически, так что не висит... и это одна, не самая большая, таблица( Растет потому, что пишется новое, прежде чем удалить старое + двойная запись в журнал (старого и нового). ЗЫ. Только договоренность со шкафом может ускорить процесс. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 11:49 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
aleks222, aleks222+ двойная запись в журнал (старого и нового).Старое-то для каких целей писать? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 11:52 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983, Еще раз - явное указание индекса в запросе не может влиять на результат. Если влияет, то либо это уже другой запрос, либо индекс поврежден. Проверить можно выполнив checkdb или checktable. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 11:53 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
aleks222, Файл лога кстати не растет, так и остался 2,5GB ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 12:20 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983 Кластерный индекс еще делается, уже 12 часов... вы бы себе отпилили тестовую БД на 10 лямов, например чтобы до старости то дожить, хотя бы ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 13:07 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
полудух kaktus1983 Кластерный индекс еще делается, уже 12 часов... вы бы себе отпилили тестовую БД на 10 лямов, например чтобы до старости то дожить, хотя бы ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 16:27 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983Учитывая время построения индекса, а таблиц таких 20+, хочу спросить: что в моем случае будет правильней делать?Еще раз повторю Создать некластерный колумнстор по всем полям партицированным по TagIndex (индекс будет раз в 10 меньше кучи) Полагаю ваша куча почти отсортирована по дате, так что запросы указанные выше летать будут (лишнее будет отсекатся) Можете начать пока без секционирования (партицирования) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 18:21 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
SERG1257 Еще раз повторю Создать некластерный колумнстор по всем полям партицированным по TagIndex (индекс будет раз в 10 меньше кучи) Полагаю ваша куча почти отсортирована по дате, так что запросы указанные выше летать будут (лишнее будет отсекатся) Можете начать пока без секционирования (партицирования) Да, куча идет по дате по порядку, БД - это журнал, почти без удаления. Я пока только читаю о колумнсторе... Честно говоря, не понимаю что Вы имеете ввиду под "партицированным по TagIndex" Если не сложно, напишите по-подробней, какие поля надо перечислить в индексе. Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 21:03 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983какие поля надо перечислить в индексеВсе. kaktus1983Я пока только читаю о колумнстореОно еще называется Real-Time Operational Analytics https://docs.microsoft.com/en-us/sql/relational-databases/indexes/get-started-with-columnstore-for-real-time-operational-analytics?view=sql-server-ver15 Суть колумнстора - все данные хранятся блоками (rowgroup) по миллиону записей. У каждого блока по каждому полю есть min/max то есть сервер заранее знает, что этот блок читать не надо если значения @from позже min или @till раньше max. Все данные в каждом поле для каждой rowgroup хорошо жмутся (степень сжатия легко достигает 10 и выше) kaktus1983"партицированным по TagIndex"Если разбить ваш индекс еще и на подгруппы с разными TagIndex, то список rowgroup для чтения сократится еще больше. (как именно разбивать партиции на TagIndex по одной, по две или по десять это надо мерять). Для начала можете этого не делать. Создайте колумнстор и погоняйте запросы. Партиции можно применить и для обычных индексов и кучи. Эта технология перпендикулярна колумнстору. Плюсы сразу - вам не надо будет перестраивать кластерный индекс удваивая требования по хранению. Добавить придется только сам колумнстор индекс (сжатый) и надеюсь это будет быстрее и дешевле. Далее запрос на чтение делается в т.н. Batch Mode. Что это такое я вам на пальцах не объясню. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-query-performance?view=sql-server-ver15 Минус - запись в колумнстор будет в один поток, ибо блокировки будут не на страницу, а на всю rowgroup. Как я понял это вам не важно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 23:12 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
SERG1257, Спасибо! Понятно и интересно описали суть. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 23:24 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
Извиняюсь 'в лоб' не получится Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Надо будет сначала перестроить кучу для партицирования ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2020, 23:29 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
SERG1257, Эх, а я уже в уме представил быстрое и изящное решение)) Буду пробовать. Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2020, 00:28 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
Попробовал разные варианты на разных таблицах. Индексы: Код: sql 1.
Код: sql 1.
работают примерно одинаково. CREATE занимает примерно 8 часов на таблицу с 500 000 000 записей (на внешний HDD по USB). NONCLUSTERED с include быстрее, но не существенно. Для таблицы с 1 500 000 000 записей решил попробовать COLUMNSTORE. SERG1257 Еще раз повторю Создать некластерный колумнстор по всем полям партицированным по TagIndex (индекс будет раз в 10 меньше кучи) Полагаю ваша куча почти отсортирована по дате, так что запросы указанные выше летать будут (лишнее будет отсекатся) Можете начать пока без секционирования (партицирования) Да, все таблицы-кучи были записаны параллельно, в хронологическом порядке. Решил начать с простого, без секционирования SERG1257 kaktus1983какие поля надо перечислить в индексе Создал Код: sql 1.
Эффекта нет, как будто нет индекса вообще.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2020, 22:00 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983Эффекта нет, как будто нет индекса вообще. В смысле нет ускорения? План в студию >Видимо я что-то не понимаю и делаю не так...? Это должно быть именно так. План должен показать использование индекса. На крайняк можно заставить использовать индекс как советовал invm 22107040 Версия у вас непропатченая Накатите последний патч KB4535007 https://support.microsoft.com/en-ca/help/4535007/cumulative-update-19-for-sql-server-2017 Поможет или нет не знаю, но не повредит. >Важно ли, при создании COLUMNSTORE, что в таблице Temperatures есть еще несколько не нужных мне столбцов? Не важно. Но при создании COLUMNSTORE индекса добавляют все поля. >Стоит ли пробовать кластерный COLUMNSTORE? Не стоит. Создание кластерного индекса перетряхнет другой (обычный) индекс, это будет долго. >Возможно нужны дополнительные (не колумнсторе) индексы? Не нужны >p.s. CREATE NONCLUSTERED COLUMNSTORE выполнилось гораздо быстрее, чем я ожидал (до часа). Ради того все и затевалось. Размер индекса должен быть тоже очень маленкий (по сравнению с кучей). Он должен быстро и умно читатся. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2020, 23:46 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
SERG1257, спасибо большое за ответы! Даю план в студию. Вдруг чего упустил, продублирую: сама таблица Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Размер 60GB, записей 1.5млрд. Индексов нет вообще, создаю Код: sql 1.
только по трем нужным мне столбцам. Код: sql 1.
ничего не меняет ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2020, 06:54 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
А почему план в студии от другого запроса? Две с половиной минуты неприемлимо? Сколько времени занимает группировка (запрос без *) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2020, 07:12 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983, Колумнстор партиционированный по полю фильтрации (дате) должен неплохо себя показать. Вообще таблицу надо отгонять в хранилище данных (в stage) и там заниматься такого рода анализом. И вообще такого рода данные рекомендую отогнать в вертику. Бесплано до 1 TB ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2020, 08:00 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
kaktus1983, Секционируйте кучу по дате, если выбираете относительно небольшие диапазоны. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2020, 12:13 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
SERG1257 А почему план в студии от другого запроса? Две с половиной минуты неприемлимо? Сколько времени занимает группировка (запрос без *) Две с половиной минуты - это для очень упрощенного варианта запроса: выборка top(10) и только за 5 секунд. Для стандартного avg(Val) и время примерно за час - я отменил после 10 минут, а с индексом Код: sql 1.
выполняется до секунды. В конечном итоге мне надо сформировать матрицу данных 12000 х 444, каждая ячейка которой - результат запроса avg(Val) за диапазон времени примерно час. Тут каждая милисекунда будет важна)) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2020, 13:41 |
|
Выборка данных из таблицы с миллиардами записей
|
|||
---|---|---|---|
#18+
Владислав Колосов, a_voronin, спасибо! В целом задачу решил, SP отработала, 12000 х 444 значений просчитала за 4 часа. Всем спасибо за помощь и идеи! aleks222, SERG1257, вам отдельная благодарность)) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2020, 13:49 |
|
|
start [/forum/topic.php?fid=46&msg=39941862&tid=1686279]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 329ms |
total: | 464ms |
0 / 0 |