Оптимизация журнала аналитики запросов

Question

Я запускаю этот запрос в журнале аналитики

                                        Perf
                                        | where TimeGenerated >= ago(5m) 
                                        | join kind = inner
                                            ( 
                                                Heartbeat  
                                                | where TimeGenerated >= ago(5m)
                                                | summarize arg_max(TimeGenerated, *) 

                                                by SourceComputerId
                                            ) on Computer
                                        | summarize arg_max(TimeGenerated, *) by SourceComputerId, CounterName
                                        | extend  Indicator = strcat(ObjectName,'-', CounterName)
                                        | summarize dict = make_dictionary
                                        (   
                                            pack
                                            (      
                                                  'WorkspaceId' 
                                                ,  TenantId
                                                ,  Indicator       
                                                ,  CounterValue
                                                ,  'TimeGenerated'   
                                                ,  TimeGenerated
                                                ,  'Computer'
                                                ,  Computer
                                            )
                                        )  by SourceComputerId
                                        | evaluate bag_unpack(dict)

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

Answer 1

Довольно сложно сказать, не упоминая размер данных (например, количество записей) для каждого из join участков и количество элементов в столбце SourceComputerId.

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

Обновление: Явное упоминание лучших практик, которые могут быть полезны в вашем случае: (для проверки)

• При использовании оператора соединения - выберите таблицу с меньшим количеством строк, чтобы быть первой (самой левой).
• Когда левая сторона мала (до 100 000 записей), а правая сторона велика, рекомендуется использовать hint.strategy = broadcast.
• Если обе стороны объединения слишком велики, а ключ объединения имеет большую мощность, рекомендуется использовать hint.strategy = shuffle.
• Когда группа по ключам оператора суммирования имеет большую мощность (лучшая практика: более 1 миллиона), тогда рекомендуется использовать hint.strategy = shuffle.