Частые обновления документов Solr - проблемы эффективности / масштабируемости

Question

У меня есть индекс Solr с полями документа, например:

id, body_text, date, num_upvotes, num_downvotes

В моем приложении документ создается с некоторым целым числом id и некоторым значением body_text (не более 500 символов).Дата устанавливается на время ввода, а num_upvotes и num_downvotes начинаются с 0.

Мое приложение дает пользователям возможность повышать или понижать содержание упомянутого выше контента, а также причину, по которой я хочу сохранитьОтслеживание этого в Solr, а не только в БД, заключается в том, что я хочу иметь возможность учитывать количество положительных и отрицательных голосов в моем search.

Это проблема, потому что вы не можете просто обновить документ solr (т. Е. Увеличить число up_votes), и вы должны заменить весь документ, что, вероятно, довольно неэффективно, учитывая, что это потребует нажатия моей БД, чтобы получить всесоответствующие данные снова.

Я понимаю, что для решения может потребоваться другая структура данных или несколько индексов (хотя я не знаю, можно ли запросить / оценить по ядрам solr).

Может ли кто-нибудьпредложить какие-либо рекомендации о том, как справиться с этим?

Answer 1

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

Также каждую ночь, когда у меня мало трафика, я оптимизирую индексирование. После каждого импорта я настраивал несколько разогревающих запросов в конфигурации SOLR.

В моем индексе SOLR у меня есть около 1,5 миллионов документов, каждый документ имеет 24 поля и около 2000 символов во всем документе. Я обновляю индекс каждые 10 минут около 500 документов (без оптимизации индекса) и делаю около 50 разогревающих запросов, состоящих из самых распространенных аспектов, наиболее часто используемых запросов фильтра и поиска в свободном тексте.

Я не получаю негативного влияния на производительность. (по крайней мере, это не видно) - мои запросы выполняются в среднем за 0,1 секунды. (до обновления каждые 10 минут среднее количество запросов составляло 0,09 секунды)

ПОСЛЕДНЕЕ РЕДАКТИРОВАНИЕ:

Я не столкнулся с какими-либо проблемами во время этого обновления. Я всегда беру документы из базы данных и вставляю их с уникальным ключом в SOLR. Если документ существует в SOLR, он заменяется (это я имею в виду под обновлением).

Обновление SOLR никогда не занимает более 3 минут. На самом деле я делаю 10 минут перерыв после каждого обновления. Итак, я запускаю обновление индекса, жду, пока он завершится, и затем жду еще 10 минут, чтобы начать снова.

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

Answer 2

Функция Join поможет вам в этом. Тогда вы можете хранить голоса вверх / вниз в отдельном документе.

Плохая новость заключается в том, что вам нужно подождать до Solr 4, если вы не чувствуете себя комфортно при сборке ствола.

Answer 3

Если вы собираетесь обновлять только голоса вверх / вниз. Вместо того, чтобы возвращаться к базе данных, просто используйте соответствующий Solr Client для вашего приложения и извлеките документ из индекса, установите необходимые значения вверх / вниз, а затем снова вставьте документ обратно в индекс.

Answer 4

В SOLR нет решения вашей проблемы. У вас проблема с базой данных, и вы пытаетесь решить ее с помощью поисковой системы.

Лучший способ справиться с этим - сохранить базу данных redis, в которой записывается document id из SOLR и подсчитывается количество голосов "за" и "против". Затем ваше приложение может объединить данные из обоих источников перед отображением.