Слишком много исключений булевых предложений в solr
Я сталкиваюсь с этой проблемой при использовании логического оператора OR в запросе формирования. Я не хочу увеличивать значение maxBooleanClause. Есть ли другой вариант, кроме этого. Мой диапазон OR может увеличиться до 2 миллионов. Я бы предпочел, чтобы, если диапазон maxBooleanClause был превышен, чем solr разбил запрос и, наконец, объединил все подзапросы. Возможно ли что-то подобное? Или, если кто-то из вас может предложить лучшую технику, чтобы сделать это.
Я хочу построить график, на котором пользователь предоставит некоторый диапазон дат, например, между 2013-03-01 по 2013-06-01, который показывает всем посетителям приложения. Здесь я хочу сделать запрос, который является ИЛИ всех уникальных идентификаторов. Например,
uniqueId:(1001 OR 1003 OR 1009 OR ........ OR 102467)
Помощь приветствуется.
2 ответа
Solr навязывает maxBooleanClause именно потому, что это та вещь, которая находится за пределами ее сладкого места. В конечном счете, если вам нужны миллионы поисков, вам нужно будет самостоятельно распространять и собирать данные за пределами Solr.
Я собираюсь выйти на конечность и предположить, что эти пункты связаны с графиком, что является наиболее распространенным местом, где я вижу подобные запросы. В этом случае, возможно, вам удастся остаться в силе Солра здесь.
Иногда имеет смысл инвертировать логику вашего фильтра, и вместо того, чтобы передавать большой набор значений для фильтрации, индексируйте эти значения в документах, которые вы ищете, чтобы потом можно было передать одно значение.
Например, скажем, у вас есть индекс людей. И скажем, вы хотите искать людей, которые дружат с каким-то конкретным человеком. Вы можете создать список идентификаторов всех своих друзей, чтобы отфильтровать результаты поиска. Но тогда у вас будет проблема, аналогичная той, что вы видите здесь: множество и много предложений OR.
Кроме того, вы можете индексировать список друзей каждого человека в Solr. Теперь у вас будет поле с тысячами значений, но ваш фильтр запросов будет иметь только одно значение: идентификатор человека, по сети которого вы фильтруете поиск.
Это играет большую роль в сильных сторонах Сольра, что касается механики поиска. Тем не менее, есть стоимость. Вам нужно будет самостоятельно управлять денормализацией и, возможно, делать много обновлений в ваших документах или испытывать некоторую задержку при обновлении графика.
Если это окажется слишком обременительным, вам может понадобиться рассмотреть другую технологию, более оптимизированную для обхода графа.
Вы также можете использовать более подходящий анализатор запросов, такой как TermQueryParser, который лучше справляется с массивными предложениями OR.
Пример:
{!terms f=uniqueId}1000,1001,10002,10003
Разделителем по умолчанию является ',', поэтому все термины, которые могут быть найдены, могут быть представлены как term1,term2,term3 и т. Д.
Более подробно здесь: https://cwiki.apache.org/confluence/display/solr/Other+Parsers