Solr пространственная плохая производительность

Question

Я использую SOLR-3.4, пространственную фильтрацию со схемой, имеющей LatLonType (subType = tdouble). У меня есть индекс около 20 миллионов мест. Моя основная проблема заключается в том, что если я использую фильтр bbox с cache = true, производительность будет достаточно хорошей (~ 40-50 QPS, задержка около 100-150 мс), но большим недостатком будет сумасшедший быстрый рост кучи старого поколения, в конечном итоге приводящий к крупным коллекциям каждые 30-40 минут (на очень большой куче, 25GB). И в этот момент производительность выходит за рамки недопустимого. С другой стороны, я могу отключить кэширование для фильтров bbox, но тогда моя задержка и QPS уменьшаются (задержка уменьшается с 100 мс => 500 мс). Javadoc NumericRangeQuery говорит о превосходной производительности, которую вы можете получить (менее 100 мс), но теперь я задаюсь вопросом, было ли это с включенным filterCache, и никто не удосужился посмотреть на результат роста кучи. Я чувствую, что это своего рода ловушка 22, так как ни одна конфигурация не является приемлемой.

Я открыт для любых идей. Моя последняя идея (не опробованная) - использовать гео-хэш (и молиться, чтобы он либо работал лучше с cache = false, либо имел более управляемый рост кучи, если cache = true).

EDIT:

Точность шага: по умолчанию (8 для двойного я думаю)

Системная память: 32 ГБ (EC2 M2 2XL)

JVM: 24 ГБ

Размер индекса: 11 ГБ

EDIT2:

Тдубл с точным шагом 8 означает, что ваши двойники будут разбиты на последовательности по 8 битов. Если все ваши широты и долготы отличаются только последней последовательностью из 8 битов, то tdouble будет иметь ту же производительность, что и обычное удвоение при запросе диапазона. Вот почему я предложил протестировать PrecisionStep 4.

Вопрос: что это на самом деле означает для двойного значения?

Answer 1

Наличие профиля Solr во время ответа на ваши пространственные запросы очень помогло бы понять, что происходит медленно, см., Например, hprof .

Тем не менее, вот несколько идей окак можно (возможно) улучшить задержку.

Сначала вы можете попытаться проверить, что происходит при уменьшении precisionStep (попробуйте 4, например).Если широта и долгота расположены слишком близко друг к другу, а PrecisionStep слишком высок, Lucene не может использовать несколько индексированных значений.

Вы также можете попытаться выделить JVM немного меньше памяти, чтобычтобы дать кешу ОС больше шансов кешировать часто используемые индексные файлы.

Затем, если он все еще недостаточно быстр, вы можете попробовать заменить TrieDoubleField как подполе на тип поля, который будет использовать странный запрос для метода getRangeQuery.Это уменьшит количество обращений к диску при расчете диапазона за счет более высокого использования памяти.(Я никогда не проверял это, это могло бы также обеспечить ужасную производительность.)