Мы имеем дело с чрезвычайно длительным (более нескольких минут) текстовым запросом ключевого слова Django orm, который вызывает тайм-ауты.
По причинам, которые нам еще предстоит диагностировать, когда поиск по ключевым словам выполняется на нашей базе данных postgres, содержащей более 1 миллиона текстовых записей, время ожидания истекает, несмотря на то, что мы внедрили рекомендуемый подход для повышения производительности в таких ситуациях.как сценарий (например, индексы GIN и to_tsvectors).
Вероятно, есть еще много камней, которые еще не опрокинуты, но в качестве временного исправления начальное поиск в Google указывает на решение для управления / остановки зависшего запроса с использованием модуля многопроцессорной обработки.Например:
import multiprocessing
import time
def run_problem_db_query(textFileSearchParameter, returned_statements):
# this is the db query that hangs.....
retrieved_text_files = statements.extra(where=["textfiles_tsv @@ plainto_tsquery(%s)"], params=[textFileSearchParameter])
return retrieved_text_files
retrieved_text_files = None
p = multiprocessing.Process(target=run_problem_db_query, name="run_problem_db_query", args=(textSearch, retrieved_text_files))
p.start()
time.sleep(10)
p.terminate()
p.join()
Хотя несколько блогов и SO сообщений рекомендовали версию этого подхода, каковы потенциальные проблемы (если таковые имеются)?
В конечном счете, мы, конечно же, хотим исправить запрос и любые потенциальные проблемы с самим БД, но помимо использования потенциально большого объема памяти (, как упомянуто здесь ), что ещепотенциальные подводные камни такого подхода?