|
|
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Есть таблица Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. кол-во данных до нескольких десятков миллионов запросы вида: Код: plaintext 1. 2. 3. 4. 5. 6. 7. в запросах меняется дата/время , набор значений accounttype и значение accountid за сутки вставляется примерно 400000 записей, accounttype может принимать десяток значений, accountid - десятки(сотни) тысяч, но регулярные обращения к первой тысяче, есть и другие запросы, но эти - основные сейчас сделаны Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 09:28 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
A IndexConsultant не помогает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 09:43 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Для начала нужно однозначно переписать запрос и вывести подзапрос из секции SELECT в секцию FROM. Сейчас сто процентов в плане запросов стоит Subquery, который выполняется на каждую строку основного запроса. Нужно от него однозначно избавиться. Попробуйте его соеденить с основным запросом через INNER JOIN или LATERAL, смотря что будет красивее в плане запроса и эффективнее. P.S. На будующее лучше всего показывать в сообщение помимо структуры таблицы, созданных индексов и текста запроса еще возвращаемый план запроса. Иначе без этого сложно сказать, в чем собака порылась :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 10:37 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
при таком росте данных, если позволяет бюджет, советую посмотреть Sybase IQ. Анализ CDR'ов/логов - типичная задача для IQ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 10:52 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Попробую переписать сейчас запрос, тогда план выложу, просто я нифига в нем еще не разбираюсь пока :), девятку только поставили, а раньше все по интуиции больше делалось ... IQ во первых ОЧЕНЬ дорого, во вторых он не потянет такой объем вставляемых данных, insert очень долго проходит ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 12:19 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Да, индексконсультант посоветовал кластерный составной индекс (accounttype, accountid, datetime) но что-то стремно как-то .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 12:24 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
IQ должен стоять "рядом", как база для анализа/репортинга и т.п. Перекинуть 400000 записей из АСА в IQ - дело 3-5 сек. Можно как bulk load так и proxy (insert into location). Цена - это конечно :) Вам решать :) но такие селекты решаются в пределах <X сек (с 1CPU, 512Мб RAM, 40mln row) и еще быстрее на нормальном железе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 12:55 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
VovakaДа, индексконсультант посоветовал кластерный составной индекс (accounttype, accountid, datetime) но что-то стремно как-то .... Это ASKRUS спец по индексам. :) Ждите вердикта. Думаю один кластерный индех не помешает, но довольно сильно увеличит базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 13:10 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
сделал составной индекс по трем полям, но не кластерный - оптимизатор им не пользуется, пользуется индексом по дате/времени с селективностью 94% .... чего-то то не понимаю совсем :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 15:39 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
1. Переписали ли Вы запрос ? 2. Если переписали, то ждем его новый текст и его план запроса. - иначе ничего сказать по поводу того, нужен ли кластерный индекс и по каким полям нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:07 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
А что такое UltraPlan ? Видимо я не туда посмотрел, потому как результаты в Plan и UltraPlan разные ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:20 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
VovakaЕсть таблица за сутки вставляется примерно 400000 записей, accounttype может принимать десяток значений, accountid - десятки(сотни) тысяч, но регулярные обращения к первой тысяче, есть и другие запросы, но эти - основные. сейчас сделаны create index voip_cdr_billing_accountid_accounttype on voip.cdr_billing (accounttype, accountid); Это бесполезный (или малополезный) индекс, исходя из того, что ты сообщил. Или тут перепутан порядок полей в посте или при создании индекса. ( accountid,accounttype)???; Индексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:24 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
(ой, добавочка) ... или datetime ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:24 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
ASCRUSДля начала нужно однозначно переписать запрос и вывести подзапрос из секции SELECT в секцию FROM. Сейчас сто процентов в плане запросов стоит Subquery, который выполняется на каждую строку основного запроса. Нужно от него однозначно избавиться. Попробуйте его соеденить с основным запросом через INNER JOIN или LATERAL, смотря что будет красивее в плане запроса и эффективнее. Как-то не очень бы согласился я : Из запроса не понятно, коррелированный подзапрос там или нет. Кажется, что нет. Если да, то куда его не ставь - все едино. Если запрос некоррелированный, то с какой такой стати ASA его будет для каждой строчки выполнять ? Или оно такое глупое, что ONCE AGREGATE не понимает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:28 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
MasterZiv VovakaЕсть таблица за сутки вставляется примерно 400000 записей, accounttype может принимать десяток значений, accountid - десятки(сотни) тысяч, но регулярные обращения к первой тысяче, есть и другие запросы, но эти - основные. сейчас сделаны create index voip_cdr_billing_accountid_accounttype on voip.cdr_billing (accounttype, accountid); Это бесполезный (или малополезный) индекс, исходя из того, что ты сообщил. Или тут перепутан порядок полей в посте или при создании индекса. ( accountid,accounttype)???; Индексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. Перепутано здесь :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:29 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
MasterZivИндексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. блин, я думал они будут помогать делать group by e164prefix, minuteprice ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:38 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
ASCRUS1. Переписали ли Вы запрос ? 2. Если переписали, то ждем его новый текст и его план запроса. - иначе ничего сказать по поводу того, нужен ли кластерный индекс и по каким полям нельзя. А что из плана нужно выложить ? там так всего много ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 16:58 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
авторКак-то не очень бы согласился я : Из запроса не понятно, коррелированный подзапрос там или нет. Кажется, что нет. Если да, то куда его не ставь - все едино. В скрипте подзапроса в WHERE стоит "prefix = e164prefix". Так что не едино. Во вторых ASA после переноса запроса в FROM уведет его в дерево главного плана, убрав Subquery, что уже прибавит скорости не мало. Так что переписывать нужно в обязку. авторА что из плана нужно выложить ? там так всего много ... Ставим в ISQL опцию Long Plan, нажимаем F5 и копируем результат сюда. По другому не разберешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 17:49 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Начал уже писать, что не всегда используется этот индекс, что возникают ситуации, когда появляется table scan, если в этом примере поменять accountid на определенное значение - то индексскан почему то уже не используется... в общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) вот план Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. так полезен ли будет кластерный индекс ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 18:05 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka MasterZivИндексы по e164prefix и minuteprice для ЭТОГО запроса тоже малополезны - ему собственно нужен индекс по accountid. блин, я думал они будут помогать делать group by e164prefix, minuteprice Ага, жди ... Подумай, чему они будут помогать ? Ну, не будет сервер сортировать набор данных при группировке, читая ВСЮ ТВОЮ ТАБЛИЦУ, ты же не этого наверное хочешь ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:12 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka в общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) ... так полезен ли будет кластерный индекс ? Так что ж непонятного ? Я так понимаю, это он и есть - вожделенный оптимальный план. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:14 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
ASCRUS В скрипте подзапроса в WHERE стоит "prefix = e164prefix". Так что не едино. Во вторых ASA после переноса запроса в FROM уведет его в дерево главного плана, убрав Subquery, что уже прибавит скорости немало. Не понял. Коррелированный ? или нет ? все равно не ясно. Не факт, что e164prefix - поле из внешнего запроса - квалификатора таблицы-то нет. Перенос же в главное дерево может только замедлить, впрочем, надо сначала разобраться, коррелированный подзапрос или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:21 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka в общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) может АСА закешировала запрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:28 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
Vovaka Как то я в плане запроса не вижу табличек globalprefixgroup и globalprefix. Или это уже план на другой запрос ? Просто хочется увидеть сам запрос и план на него. По плану запроса можно сказать, что он неэффективен, так как по нему оптимизатор сначала сканирует по индексу подходящие условию записи, и считывая их значения с таблицы начинает строить хэш-таблицу по полям e164prefix, minuteprice и currencyrate, аггрегируя по ним нужные поля найденных записей. Далее он запихивает результат во временную таблицу для проведения сортировки. Наличие хэша говорит, что оптимизатор не нашел подходящего индекса, а наличие времянки говорит, что самих групп возвращается много и не хватает кэша памяти ASA для их размещения. Так что еще раз хочу сказать, что нужно пока забыть про индексы и более удачно переписать запрос, добившись того, чтобы в нем не было использования хэш алгоритма группировки (он хорош, только при условии малого кол-ва групп). авторНе понял. Коррелированный ? или нет ? все равно не ясно. Не факт, что e164prefix - поле из внешнего запроса - квалификатора таблицы-то нет. Перенос же в главное дерево может только замедлить, впрочем, надо сначала разобраться, коррелированный подзапрос или нет. Вся хитрость в том, что ASA != ASE почти во всем: 1. Квалификатор таблицы для указания поля связи в этом подзапросе не нужен, если таблицы подзапроса не имеют такого же поля. Хотя правильней его писать, чтобы вот потом не возникало таких споров. 2. Запрос явно является коррелированным, так как связывается по полю e164prefix с основным запросом, а так как он аггрегированный, то ASA потребовала бы включить его в группировку, что и сделано в запросе. 3. Перенос в главное дерево, т.е. избавление от Subquery всегда увеличивает скорость работы подзапроса в ASA, только при условии, если правильно переносить :) Например в данном случае переносить запрос нужно в основной запрос не через соединение INNER JOIN, а как LATERAL (прямое внутреннее соединение, которое позволяет внутри подзапроса ссылаться на поля главного запроса, но при этом алгоритм его выполнения эффективнее, чем работа с Subquery). авторТак что ж непонятного ? Я так понимаю, это он и есть - вожделенный оптимальный план. Как я уже и говорил выше, ничего хорошего в этом плане нет, учитывая размеры таблицы. Хэш-таблицы ASA начинает использовать не от хорошей жизни, а от вынужденной необходимости хоть как то обработать огромный массив записей. авторможет АСА закешировала запрос? Кэш не влияет на построение плана запроса. В данном случае правильный ответ будет из фразы: авторв общем потом попробовал еще пару раз - table scan пропало ... теперь еще непонятней стало :) а если вспомнить, что в ASA обучающийся эвристический анализатор, который после выполнения каждого запроса сравнивает полученные результаты с предполагаемыми, корректирует статистику по полям таблицы и индексов и начинает вести рэйтинг планов запросов, то этим скорее всего и обьясняется пропажа TableScan-а. Ну еще как вариант - это изменение условий запроса, которые привели к тому, что в выборках стала участвовать не сильно много записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2004, 19:43 |
|
||
|
ASA9.0.1 Помогите с оптимальными индексами на большой таблице
|
|||
|---|---|---|---|
|
#18+
в общем вот запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. индекс в таблице только один (accountid, accounttype, datetime) вот план Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. пробовал сделать подзапрос через join - выигрыша нет Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. а вот как избавиться от хэшей ? результат выборки, в зависимости от периода может достигать сотен тысяч записей, в данном случае за сутки до десятков тысяч, после группировки остается максимум сотни две ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 09:08 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=32667679&tid=2014148]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 417ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...