Как проверить в Daxstudio, какой запрос DAX имеет лучшую производительность?

Question

Как проверить, какой из двух запросов DAX имеет лучшую производительность, используя Daxstudio . В примере запросы возвращают точно такие же результаты. Однако статистика различается, показывая неясные намеки. Какую полезную информацию мы можем получить asp из сравнения двух запросов?

Сводная статистика статистики запросов:

+-------------------------+------------+---------+---------+
|                         |            | Query 1 | Query 2 |
+-------------------------+------------+---------+---------+
| Server timings          | Total      |       7 |       5 |
|                         | SE CPU     |       0 |       0 |
|                         | FE         |       6 |       4 |
|                         | SE         |       1 |       1 |
|                         | SE Queries |       3 |       2 |
|                         | SE Cashe   |       0 |       0 |
+-------------------------+------------+---------+---------+
| Query plan, no of lines | physical   |       7 |      28 |
|                         | logical    |      13 |       9 |
+-------------------------+------------+---------+---------+

• Второй запрос быстрее, но имеет густой и длинный план. 2 сканирования.
• Первый запрос имеет более длительную синхронизацию с сервером, но более чистый и короткий план запроса. 3 скана.

Таким образом, время сервера поддерживает второй запрос, но его сложный план запроса вызывает обеспокоенность. Зная статистику и планы запросов, что мы можем ожидать, если в SearchTable будет миллион строк? Разве нам не нравятся более простые планы запросов, поскольку оптимизация DAX в будущем может измениться в их пользу?

Образцы данных. У нас есть две таблицы SearchTable и ThisTable:

SearchTable = 
DATATABLE (
    "Category", STRING,
    "Product", STRING,
    "Amount", INTEGER,
    {
        { BLANK ()      , "apple"       , 1 },
        { "Fruits"      , "apple"       , 1 },  -- watch out for multiple apples!
        { "Yummy Fruits", "apple"       , 2 },
        { "Fruits"      , "banana"      , 4 },
        { "Fruits"      , "wolfberry"   , 5 },
        { "Fruits"      , "cherry"      , 3 },
        { "Vegetables"  , "carrot"      , 3 },
        { "Vegetables"  , "potato"      , 1 },
        { "Vegetables"  , "onion"       , 7 },
        { "Fruits"      , "cherry"      , 3 }        
    }
)
---
ThisTable = 
DATATABLE (
    "Product", STRING,
    {
        { "apple" },
        { "banana" },
        { "blackberry" },
        { "carrot" },
        { "cherry" },
        { "onion " },
        { "potato" },
        { "watermelon" },
        { "wolfberry" }
    }
)

Запрос № 1.

EVALUATE
ADDCOLUMNS (
    VALUES ( ThisTable[Product] ),
    "FilterLookup",
    VAR LookupKey = ThisTable[Product]
    RETURN
        CALCULATE ( MAX ( SearchTable[Category] ), SearchTable[Product] = LookupKey )
)

Запрос имеет следующую статистику:

И план запроса:

Запрос № 2.

EVALUATE
ADDCOLUMNS (
    VALUES ( ThisTable[Product] ),
    "FilterLookup", MAXX (
        FILTER ( SearchTable, SearchTable[Product] = ThisTable[Product] ),
        SearchTable[Category]
    )
)

Статистика:

План запроса:

Вопрос относится к:

DAX-поиск первого непустого значения в несвязанной таблице

Вы можете загрузить файл pbix с примерами данных:

DAX-просмотр top 1 value.pbix

Answer 1

Вы не можете точно сказать из DAX Studio, когда наборы данных настолько малы, но в большинстве случаев запрос с наименее сложным планом запроса будет самым быстрым. Это случай запроса № 1, и он действительно будет самым быстрым в вашем случае (игнорируйте все измерения времени менее ~ 20 мс - поскольку это ненадежно, поскольку наборы данных очень малы).

Кроме того, Я хотел бы добавить, что следующий запрос должен дать тот же результат и быть еще быстрее, с еще более простым планом запросов, чем оба ваших запроса:

ADDCOLUMNS(
    ThisTable,
    "FilterLookup",
        LOOKUPVALUE(SearchTable[Category], SearchTable[Product], ThisTable[Product])
)

Редактировать: Я не заметил, что «яблоко» появляется дважды в столбце SearchTable[Product]. Это приведет к сбою вышеуказанного вызова LOOKUPVALUE(...), поскольку он не сможет найти однозначное значение для SearchTable[Category].

Answer 2

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

В общем, вы хотите избегать итераторов, подобных MAXX в пользу MAX, когда это возможно, так как последний имеет оптимизацию двигателя под капотом. Очень немногие правила универсальны при оптимизации запросов, так что это вопрос, основанный на мнении, учитывая данные, которые вы показали.