Nano Hash - криптовалюты, майнинг, программирование

Этот запрос на переходное_закрытие занимает 20 секунд! Почему?

Этот запрос работал отлично и быстро выполнялся, когда у меня было почти 500 строк в таблице Member_Contact_Edges. Но теперь у меня в этой таблице почти 1000 строк, и выполнение этого запроса занимает 20-30 секунд. Я не мог понять, где проблема. Я пробовал Clustered и Non-Clustered index. Я пробовал каждую комбинацию индексов, но безуспешно.

 ;WITH transitive_closure(member_a, member_b, distance, path_string) AS

  (SELECT member_a, member_b, 1 AS distance, CAST(member_a as varchar(MAX)) + '.' + CAST(member_b as varchar(MAX)) + '.' AS path_string
          FROM Member_Contact_Edges
          WHERE member_a = @source AND contact_durum=1 -- source

   UNION ALL

   SELECT tc.member_a, e.member_b, tc.distance + 1, CAST(tc.path_string as varchar(MAX)) + CAST(e.member_b as varchar(MAX)) + '.' AS path_string
          FROM Member_Contact_Edges AS e
          JOIN transitive_closure AS tc ON e.member_a = tc.member_b
          WHERE tc.path_string NOT LIKE '%' + CAST(e.member_b as varchar(MAX)) + '.%' AND e.contact_durum=1
   )

   SELECT distance, path_string FROM transitive_closure
          WHERE member_b=@target AND distance <= 3 -- destination
          ORDER BY member_a, member_b, distance;

Вот как я вызываю хранимую процедуру:

   Exec Contacts_KacinciDerece @source = 30284, @target=24688

Вывод: (Это то, что я ожидал, и этот запрос создает это)

Ожидаемый результат, но создание занимает так много времени

Спасибо.

sql-server optimization performance transactions
28.06.2011

  • В рекурсивном CTE (что у вас есть здесь) удвоение количества записей в исходных таблицах может привести к экспоненциальному увеличению времени обработки, поскольку оно оценивается против самого себя. Удвоение количества строк означает сравнение в 3 раза большего количества строк (500*500 против 1000*1000). 28.06.2011
  • Исправление - 4-кратное количество строк, 250 тыс. против 1 млн. 28.06.2011

Ответы:


1

У вас есть path_string NOT LIKE '%' + CAST(e.member_b as varchar(MAX)) + '.%'

  • Невозможно оптимизировать ни NOT LIKE, ни ведущий подстановочный знак LIKE, не говоря уже о том и другом.
  • path_string в любом случае является вычисляемым полем

Каждая дополнительная строка в Member_Contact_Edges умножает количество строк, которые необходимо просмотреть (квадрат) без каких-либо преимуществ индексов.

Это O(n^2) по крайней мере: я подозреваю, что выше...

28.06.2011
  • +1 — Мало что показывает проблемы с оптимизацией так же быстро, как рекурсивный CTE — когда ваш плохой код построен на основе другого плохого кода, он быстро замедляется. 28.06.2011
  • Правильно, любое предложение, как получить такой вывод? Я открыл поток для этой проблемы, но не смог найти другого решения, кроме рекурсивного CTE Предыдущий пост — Источник 28.06.2011
  • Сравните e.member_b с tc.member_b вместо tc.path_string. 28.06.2011
  • @Phil Helmer Итак, вы думаете, что основная проблема с производительностью здесь - это утверждение NOT LIKE? Я прав? Позвольте мне попробовать. 28.06.2011
  • @Phil Helmer Мне не удалось запустить отредактированный запрос. «ПРИСОЕДИНЯЙТЕСЬ переходному_закрытию КАК tc ON e.member_a = tc.member_b AND e.member_b‹›tc.member_b WHERE e.contact_durum=1» Описание ошибки: Оператор завершен. Максимальная рекурсия 100 была исчерпана до завершения оператора. 28.06.2011
  • @Phil Helmer, @JNK Я отредактировал вопрос как ответ. Пожалуйста, проверьте. 28.06.2011

    • 2

    Похоже, оператор NOT LIKE является ключом к производительности. Мне удалось выполнить запрос за 160 мс, ограничив расстояние.

    Но тут возникает проблема:

    Если я не использую оператор NOT LIKE, он выбирает одного и того же человека дважды или более из-за рекурсивного выбора.

    Например;

    ;WITH transitive_closure(member_a, member_b, distance, path_string) AS

(SELECT member_a, member_b, 1 AS distance, CAST(member_a as varchar(MAX)) + '.' + CAST(member_b as varchar(MAX)) + '.' AS path_string
      FROM Member_Contact_Edges
      WHERE member_a = @source AND contact_durum=1 -- source

UNION ALL

SELECT tc.member_a, e.member_b, tc.distance + 1, CAST(tc.path_string as varchar(MAX)) + CAST(e.member_b as varchar(MAX)) + '.' AS path_string
      FROM Member_Contact_Edges AS e
      JOIN transitive_closure AS tc ON e.member_a = tc.member_b
      WHERE tc.member_b <> e.member_b AND tc.distance<4 AND e.contact_durum=1
)

SELECT distance, path_string FROM transitive_closure
      WHERE member_b=@target AND distance < 4 -- destination
      ORDER BY member_a, member_b, distance;
    29.06.2011
    Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..