django-haystack: выбор большого SearchIndex вместо индексированной БД

Question

У меня есть модель UserProfile с 35 полями (Char, Int, Bool, Dec, M2M, FK). Как часть функциональности представления поиска, одно из полей требует полнотекстового поиска, а остальные 34 поля будут использоваться для обеспечения расширенной фильтрации поиска (с использованием: __gte, __lte, __cured, __in, __startswith). Запрос 'search' может использовать от 5 до 35 полей в качестве критериев просмотра.

Я использую стог сена для построения SearchIndex, и в настоящее время добавлены все 35 полей, но это кажется неэффективным, поскольку я обхожу django ORM (?).

ответ от Фильтровать результаты Django Haystack, такие как QuerySet? предлагает мне просто сохранить одно полнотекстовое поле поиска в SearchIndex и объединить SearchQuerySet с QuerySet django для оставшихся 34 полей фильтра. Буду ли я тогда использовать db_index = True в некоторых или во всех этих полях в моей модели django? Будет ли использование этого двухэтапного подхода к слиянию запросов масштабироваться до тысяч результатов?

Поскольку моя модель UserProfile может увеличиться до 300K-2M записей, я пытаюсь понять, как лучше индексировать эту модель. Будучи новичком в области индексирования и поиска в БД, я хочу узнать, как лучше оптимизировать мою базу данных.

Answer 1

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

Но если вы сделаете что-то вроде

results = [ r.pk for r in searchqueryset ]

На самом деле он выполняет этот запрос к стогу сена / solr. Если вы просматриваете в общей сложности 2 млн записей, это означает, что ваш список потенциально может вернуть 2 млн записей. И теперь вы отправляете список 2M в MySQL (используя ORM) для дальнейшей фильтрации. Это никогда не будет увеличиваться, очевидно.

Если вы просто придерживаетесь стога сена, а затем продолжаете строить свой набор запросов, он будет выполнен только один раз при доступе к результатам. Также имейте в виду уменьшить {{result.object}}, потому что это также касается базы данных для каждого результата.

Вы можете посмотреть на load_all (), огранку и т. Д.