Много мыслей по этой теме. Хотя мой ответ никак не влияет на EhCache.
Во-первых, я не считаю, что документы должны храниться в вашем поисковом индексе. Содержимое для поиска должно храниться там, а не весь документ. Что я имею в виду, так это то, что возвращается из вашего поискового запроса, это идентификаторы документов. Не содержание самих документов. Сами документы должны быть сохранены и извлечены из второй системы, возможно, для первоначального хранилища файлов, с которого они индексируются. Это уменьшит размер индекса, уменьшит размер кэша вашего документа, уменьшит время репликации основного ведомого (это может стать узким местом, если вы часто обновляете), и уменьшить накладные расходы при написании ответов на поиск.
Затем рассмотрите возможность установки обратного HTTP-прокси перед Solr. Хотя тайники запросов позволяют Solr быстро реагировать, кеш, такой как Varnish, сидящий перед Solr, еще быстрее. Это выгружает Solr, позволяя ему тратить время на запросы, которые он не видел раньше. Второй эффект заключается в том, что теперь вы можете перебрасывать большую часть своей памяти в кеш-файлы вместо кэшей запросов. Если вы следовали моему первому предложению, ваши документы будут невероятно малы, что позволит вам хранить большинство, если не все из них в памяти.
Быстрый расчет размера конверта для документов. Я могу легко предоставить 32-битный int в качестве идентификатора для 150 миллионов документов. У меня все еще есть 10-кратный запас для роста документов. 150 миллионов идентификаторов занимают 600 МБ. Добавьте в факс для документов Solr, и вы, вероятно, можете легко загрузить все ваши документы Solr в 1-2GB. Учитывая, что получение 12GB-24GB или RAM в наши дни легко, и я бы сказал, что вы можете сделать все это на одной коробке и получить невероятную производительность. Не нужно ничего лишнего, как EhCache. Просто убедитесь, что вы используете свой индекс поиска максимально эффективно.
Что касается GC: я не видел много времени GC, потраченного на мои серверы Solr. Большая часть того, что нужно было собрать, было очень короткоживущими объектами, связанными с циклом запроса и ответа HTTP, который никогда не выходит из пространства с эденом. При правильной настройке кешей не было большого оборота. Единственные большие изменения произошли, когда новый индекс был загружен, а кеши были сброшены, но это не происходило постоянно.
EDIT: Для фона я потратил немало времени на настройку кэширования Solr для крупной компании, которая продает консоли и обслуживает миллионы запросов в день от своих серверов Solr.
Поскольку мы еще ничего не строили, мы обязательно рассмотрим этот вариант.Однако это будет связано с созданием экземпляра базы данных. Благодарю. – nvalada
Для того, что я изложил, это не обязательно. Вы можете использовать URL-адрес или путь к файлу в качестве вашего идентификатора. Это занимает больше места, но все же может быть разумным. – rfeak
@rfeak: В моей компании мы используем Solr не только для поисковых целей, но и для выделения текста. Я предполагаю, что метод отделения документов от индекса удалит эту способность. Если у вас есть время, можете ли вы объяснить, как вы решаете проблемы с огромными индексами, но каким-то образом используете возможности выделения Solr? – iralls