производительность скрипта зависит от последовательности полей в таблице?

[igor-st80]

Здравствуйте!

Есть таблица:

Table1

5 млн. строк

12 полей

Поле SDATE является Датой

В зависимости от того каким по счету является поле SDATE получаю разное время выполнения операции:

LOAD

Min(SDATE) as MinDate,

Max(SDATE) as MaxDate

RESIDENT Table1;

Если SDATE является первым полем, то операция выполняется за 9 сек

Если SDATE является последним полем, то операция выполняется за 27 сек

Подскажите пожалуйста чем это объясняется и где еще нужно обратить внимание на последовательность полей, что бы оптимизировать производительность скрипта и возможно готового документа QV?

[Eugeny_Ilyin]

День добрый.

Интересно.
А если поле в середине таблицы?

Возможно, при формировании таблицы в памяти создается служебный индекс по умолчанию на первое поле. Поэтому и разница.
Но это лишь моя гипотеза.

[Sergey_Polekhin]

Добрый день,

Попытался воспроизвести указанный вариант задачи (см. приложение в аттаче).

Можете сами загрузить в приложение интересующее вас количество записей (исправив значение переменной vNumOfRows в начале скрипта) и посмотреть на результат. Сейчас указано 100 000 записей, дабы не увеличивать размер загруженного сюда документа.

В частности, сравнивая времена выполнения операций поиска максимальных и минимальных значений по первому, второму и 12-му полям, разница во времени поиска по этим полям на объеме в 5 000 000 записей составляет не более 1 секунды.

Полагаю, что замеченная вами разница вызвана не порядковым номером столбцов, а набором данных в них (например, количеством уникальных значений, по которым производится поиск). В тестовом приложении я специально генерирую записи неповторяющимся образом с использованием Rand().

Кому интересно, можно поэкспериментировать и заметить, что поиск максимальных и минимальных значений по полю с типом Date выполняется ~3-4 раза быстрее, чем по полю, имеющему тип Num. Для экспериментов можете просто снять комментарий на различных вариантах загружаемых таблиц.

[igor-st80]

Спасибо! Потестировал ваш пример, действительно все корректно работает. Со своими данными обнаружил, что особенность  с перестановкой столбцов наблюдается только на виртуальном сервере. На выделенном сервере и на локальной машине такого  не происходит. Может быть какие-то особенности в настройках нашего сервера? Может такое быть? Но в общем вопрос снимается.

[igor-st80]

Сергей, заметил еще следующее: если в вашем примере оставить только три поля 1,2,12, то поиск мин/макс значений по этим полям будет значительно быстрее, чем если бы в таблице у нас были все 12 полей, но поиск бы осуществлялся также по 3-м полям (1,2,12,).

[Sergey_Polekhin]

При использовании виртуализации можно строить только предположения зависящие как от среды виртуализации, так и от настроек виртуальных ресурсов конкретной виртуальной машины, т.к. в  этом случае управление выделением памяти обеспечивает именно слой виртуализации.

Одно из простейших предположений состоит в том, что виртуальная машина использует несколько логических (виртуальных) процессоров, являющихся не логическими ядрами одного физического процессора, а логическими ядрами нескольких физических процессоров. Т.е. одна виртуальная машина вынуждена использовать физические области памяти, относящиеся к различным физическим процессорам (узлам NUMA).

При распараллеливании вычислительных задач (использовании нескольких таких логических процессоров в рамках одной виртуальной машины) оказывается, что на передачу данных между различными физическими областями данных RAM, принадлежащими различным NUMA-узлам, расходуется дополнительное время.

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

Qlik же при обработке больших объемов данных позволяет вам получить все условия для наглядности:

• Существенно нагрузить аппаратные ресурсы, позволив ощутить разницу в использовании различных вариантов обмена данными в RAM
• Обеспечить простое моделирование нагрузки путем изменения объема обрабатываемой информации и/или сложности выполняемых расчетов
• Обеспечить простой способ визуализации получаемых различий.

В итоге получаем такое вот нестандартное применение Qlik для оценки оптимальности характеристик виртуальной машины .

[Anna_Klimkova]

Добрый день, Игорь!

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

Вместо поиска максимума и минимума по всей таблице фактов ( у вас 5 млн строк, а бывает и гораздо больше), рекомендую использовать FieldValue(), чтобы поиск производился по значениям поля SDATE без повторений. В вашем случае наверняка разных дат не больше пары тысяч.

Нахождение максимума и минимума:

LOAD
min(FieldValue('SDATE',recno()))-1 as MinDate,
max(FieldValue('SDATE',recno())) as MaxDate   
AutoGenerate  FieldValueCount('SDATE');

В итоге календарь может выглядеть так:

MasterCalendar:
LOAD
SDATE as Дата,
Year (SDATE) AS Год,
Month (SDATE) AS Месяц,
Day (SDATE) AS День,
Weekday (SDATE) AS [День недели],
'Кв ' & Ceil(Month (SDATE)/3) AS Квартал,
if(Month(SDATE)<7, '1-е полугодие','2-е полугодие') as Полугодие,
Date( Monthstart (SDATE), 'MMM-YYYY') AS МесГод;
LOAD
date(MinDate+IterNo()) as SDATE
While MinDate+IterNo()<=MaxDate;
LOAD
min(FieldValue('SDATE',recno()))-1 as MinDate,
max(FieldValue('SDATE',recno())) as MaxDate   
AutoGenerate  FieldValueCount('SDATE');

Ссылка на источник:

http://qlikviewcookbook.com/2015/05/better-calendar-scripts/

[igor-st80]

Анна, спасибо!

Ценная информация, сделал как рекомендовано. Календари теперь создаются мгновенно!