Мы используем ElasticSearch для хранения исторических данных поиска. Индекс предназначен для разделения по дням из шаблона. Все поля являются статическими, поля для поиска индексируются, остальные отключены.
Этот индекс очень часто обновляется и ищется. Обновление заключается в добавлении документов в него; поиск должен получить 500 самых последних исторических записей. Он хорошо работает с низкой нагрузкой, но когда мы подвергаем его стресс-тесту (например, 150 обновлений + поисковых операций в секунду), он начинает работать в 5 раз медленнее.
Размер индекса невелик, около 1 ГБ в день. Мы вращаем данные в течение 30 дней.
Для этого мы подготовили кластер ES, включающий 1 главный узел (4VCPU, 8 ГБ ОЗУ) и 5 узлов данных (8VCPU, 24 ГБ ОЗУ). Учитывая размер индекса, мы устанавливаем shard = 0 и replicas = 4. На каждом узле данных мы разрешаем ES использовать 12 ГБ ОЗУ, а остальные 12 ГБ выделяются для кучи.
Мы попробовали что-то вроде увеличения интервалов обновления, и это не сработало: если загрузка мала, время поиска составляет 30 мс; когда нагрузка высокая, он может подскочить до 220 мс.
Я проверил ситуацию с кешем, и это ужасно:
"primaries": {
"query_cache": {
"memory_size_in_bytes": 0,
"total_count": 7883586,
"hit_count": 0,
"miss_count": 7883586,
"cache_size": 0,
"cache_count": 0,
"evictions": 0
}
},
"total": {
"query_cache": {
"memory_size_in_bytes": 0,
"total_count": 39982611,
"hit_count": 14,
"miss_count": 39982597,
"cache_size": 0,
"cache_count": 6,
"evictions": 6
Вполне возможно, что каждая настройка этого неоптимальна, поэтому я открыт для всех предложений.
Спасибо!