Solr / Lucene fieldCache Сортировка ошибок OutOfMemory на динамическом поле

У нас есть ядро Solr, которое имеет около 250TrieIntFields (объявлен какdynamicField). В нашем индексе Solr содержится около 14 миллионов документов, и многие документы имеют определенную ценность во многих из этих полей. Нам необходимо отсортировать все эти 250 полей за определенный период времени.

Проблема, с которой мы сталкиваемся, заключается в том, чтоfieldCache заполняется очень быстро. У нас есть коробка 4 ГБ, а размер индекса составляет 18 ГБ. После сортировки по 40 или 45 из этих динамических полей потребление памяти составляет около 90%, и мы начинаем получать ошибки OutOfMemory.

На данный момент у нас есть задание cron, которое запускается каждую минуту, перезапуская tomcat, если общее потребление памяти превышает 80%.

Из того, что я прочитал, я понимаю, что ограничение числа различных значений в сортируемых полях Solr приведет к снижениюfieldCache пространство. Значения в этих сортируемых полях могут быть любыми целыми числами от 0 до 33000 и довольно широко распределены. У нас есть несколько масштабных решений, но как лучше всего решить эту проблему?

ОБНОВЛЕНИЕ: Мы думали, вместо сортировки, если мы сделали повышение, выиграл 'зайти в fieldCache. Таким образом, вместо выдачи запроса, как

select?q=name:alba&sort=relevance_11 desc

мы попытались

select?q={!boost relevance_11}name:alba

но, к сожалению, повышение также заполняет кэш поля :(

Ответы на вопрос(2)

Решение Вопроса

Я думаю, у вас есть два варианта:

1) Добавьте больше памяти.

2) Заставить Solr не использовать кеш поля, указавfacet.method=enumсогласно документации

Там'такжеСписок рассылки solr-user обсуждая ту же проблему.

Если ваш индекс не огромен, ябуду идти с вариантом 1). Оперативная память дешева в наши дни.

 mindas28 нояб. 2012 г., 10:26
Спасибо, что поделились, это довольно интересно.
 arun15 нояб. 2012 г., 19:31
неfacet.method применимо только для фасетных запросов? Как отключить кэш полей для запросов сортировки?
 arun15 нояб. 2012 г., 19:31
Хотя увеличение объема памяти является одним из очевидных решений, наши серверы размещаются на стоечном пространстве, а сервер на 4 ГБ стоит 175 долларов в месяц, а сервер в 15 ГБ (который может содержать почти весь индекс Solr) стоит 657 долларов в месяц (см.rackspace.com/cloud/pricing). Прежде чем бросить больше денег на эту проблему для кеша, который мы неЯ даже хочу найти, как этого избежать.
 arun28 нояб. 2012 г., 06:47
Я отправил список пользователей по почте. Эрик Эриксон говорит: «Я уверен, что нетне вижу, как это может работать с учетом ограничений. Просто для хранения значений, при условии, что каждый документ содержит значение в 150 полях, вам требуется 150 * 4 * 14 000 000 или 8,4 ГБ памяти, и вы просто нене так много памяти, чтобы поиграть с. Sharding кажется глупым для 14M документов, но это может быть то, чтонеобходимо. Или получить оборудование с большим объемом памяти. Или переопределить проблему, чтобы вы нене нужно сортировать так много полей. Не совсем уверен, как это сделать с моей головы, но "  поэтому мы сейчас переделываем нашу схему! Я принимаю твой ответ

У нас есть способ переработать схему, сохранив одно поле сортировки. Динамические поля, которые мы имеем, похожиrelevance_CLASSID, Текущая схема имеет уникальный ключNODEID и многозначное полеCLASSID - баллы релевантности для этих классов. Если вместо этого мы сохраняем один документ на classId на nodeId, то есть новая схема будет иметьNODEID:CLASSID как уникальный ключ и хранить некоторую избыточную информацию в документах с тем жеNODEIDтогда мы можем отсортировать по одному полюrelevance и сделать запрос фильтра по CLASSID.

Ваш ответ на вопрос