Предисловие: Примите новую версию
Чтобы обеспечить обновление версии ElasticSearch, каждое обновление ElasticSearch в основном имеет повышение производительности на 10–30% в определенных сценариях.Обновление версии ElasticSearch — это дешевый способ улучшить производительность и опыт кодирования.Обновление стабильной версии , по крайней мере обеспечьте обновление мажорной версии, постарайтесь не обновлять версию, которая сильно отличается от официальной версии, я сталкиваюсь с таким, и очень больно обновляться через три мажорные версии!
Оптимизация запросов
SSD
Излишне говорить о преимуществах ssd, но это может быть не то, что мы можем решить, просто знайте это.
подходящая память
ElasticSearch — очень требовательный к памяти поисковик, Sort (сортировка), agg (агрегация) в процессе поиска, fieldadd, инвертированный индекс и т. д. в процессе сегментации слов потребляют память, и должно быть достаточно JVM HEAP, поддерживающего это остаток средств.
Официальный представитель четко заявил, что машина с 64G памяти идеальна, а JVM HEAP предпочтительно должен быть установлен на 1/2 от машины, которая составляет 32G, чтобы обеспечить достаточно места в куче и достаточно памяти вне кучи, потому что Lucene отвечает за полную -текстовый поиск, а производительность Lucene зависит от взаимодействия с операционной системой. Если вы выделите всю память для динамической памяти Elasticsearch, для Lucene не останется никакой памяти. Это серьезно повлияет на производительность полнотекстового поиска, поэтому OOM часто будет возникать из-за нехватки памяти вне кучи.
- Стандартная рекомендация — использовать 50 % доступной памяти в качестве кучи Elasticsearch, а оставшиеся 50 % оставить себе. Конечно, она также не будет потрачена впустую, и Lucene с радостью использует оставшуюся память.
Также обратите внимание на ограничение памяти ElasticSearch в 32 ГБ! До сегодняшнего дня официальный сайт по-прежнему не рекомендует нам превышать 32 ГБ памяти.
Память кучи: размер и подкачка | Elasticsearch: полное руководство | Elastic
Источник проблемы: узкое место технологии сжатия указателя памяти (compressed oops).Проще говоря, если он превысит 32 ГБ, сжатие указателя не удастся, и память будет потрачена впустую. Ходят слухи: производительность 50 ГБ кучи объем памяти близок к 31 ГБ, а нагрузка на сборку мусора высока, что также влияет на производительность.
-Xms 31g
-Xmx 31g
Если у вас 128 машин, вы можете настроить два узла, каждый с 32 ГБ памяти, чтобы сформировать кластер. Если это ваш случай (физическая машина (жесткий диск) не решается открыть несколько узлов из-за узких мест в памяти), то вы должны установить
cluster.routing.allocation.same_shard.host: true
Это предотвратит существование первичной реплики того же сегмента на одном физическом компьютере (поскольку, если он существует на одном компьютере, высокая доступность реплики будет недоступна).
_routing маршрутизация
Маршрутизация (маршрутизация данных), поставляемая с ElasticSearch, очень полезна. Сценарий ее использования аналогичен ShadingSpare (подбаза данных и промежуточное программное обеспечение подтаблиц Apache). можете решить по своему.Какая гранулярность и какое поле определяет роутинг всего индекса,вообще чем единее тем лучше,автор платформа SAAS,тогда можно использовать (идентификатор компании)для _routing,если это лог системы, вы можете рассмотреть возможность использования (детализации по времени) в качестве _routing, скорость запросов после _routing значительно повышается при увеличении объема данных.
Если вы не добавляете внутренний процесс _routing ElasticSearch:
- Распространение: после того, как запрос достигает узла-координатора, узел-координатор распределяет запрос запроса по каждому сегменту.
- Агрегация: узел-координатор собирает результаты запроса на каждом сегменте, сортирует результаты запроса и затем возвращает результаты пользователю.
В случае больших данных _routing должен быть включен в каждый запрос для запроса любых данных.Для особых бизнес-сценариев унифицированный _routing может использоваться независимо от _routing.
Не разделяйте слова для полей, не связанных с поиском
Есть много бизнес-полей, которые вообще не нуждаются в сегментации слов, таких как связанные идентификаторы, некоторые бизнес-поля, которые не участвуют в поиске, коды состояния и т. д. Такие поля должны быть объявлены без сегментации слов:
index:"no_analyzer" 或 type:"keyword"
Выполняйте полное сопоставление, чтобы это поле не участвовало в сегментации слов, не участвовало в инвертированном индексе, уменьшало сегмент для экономии места в памяти и позволяло памяти кэшировать все больше и больше полезных данных, память ограничена, используйте ее бережно
- Просмотр использования памяти сегмента индекса
GET _cat/segments/indexName?v
size : Дисковое пространство, занятое сегментом
memory.size: объем памяти, занимаемый сегментом
разделение индекса
**Во-первых, не создавайте несколько типов под одним индексом! **Даже если у вас 2.x, 5.x, в котором не запрещено несколько типов, учитывая последующую масштабируемость, такую как будущие обновления версии, вам необходимо разобрать его как можно скорее, и я часто ссылаюсь на официальный сайт. , В то время я узнал, что будет проблема перекоса данных при создании нескольких типов для одного индекса, что похоже на перекос кольца хэшей, что приведет к неравномерному распределению данных и плохой производительности сжатия документов! Дистрибутив плотный, больше соответствует спецификации Lucene и больше подходит для сжатия. Каждый индекс по умолчанию соответствует одному _doc.
Во-вторых, если она похожа на систему журналов, основанную на ELK и ELFK, вы можете использовать шаблон ролловера + индекса, чтобы свернуть индекс в соответствии со временем, чтобы избежать огромного объема данных, генерируемых индексом и фиксированным сегментом, который приведет к катастрофе поиска. Индекс десятков миллиардов документов установлен с 5 осколками, что может гарантировать, что фрагментация не будет потрачена впустую, а производительность в реальном времени гарантирована.
Глубокое пейджинг не допускается
Этот базовый масштабный сайт не разрешен.Конечно, многие продакт-менеджеры очень **.Если мне не верите, зайдите на Таобао для поиска товаров, до 100 страниц.Так я уговариваю продакт-менеджеров, а ElasticSearch по умолчанию запрашивает 10 000 наиболее подходящих данных. Если вы хотите сделать более подробные запросы (например, для расчетов отчета требуются полные данные), вам может потребоваться maxResult или прокрутка для однократного чтения или запросы с перелистыванием страниц. .
отключить подстановочный знак
До сих пор у нас все еще есть скрытая опасность подстановочных знаков, которая не была скорректирована:
{
"bool": {
"must": [
{
"wildcard": {
"name": "${name}"
}
},
{
"term": {
"companyId": "${companyId}"
}
}
]
}
}
Просто вставьте пример:обсудить.эластик.со/он/подстановочный знак-…
Подстановочный знак убивает производительность: в случае большого объема данных он будет запрашивать очень и очень медленно, легко застрять и даже вызвать сбой и выход из строя узлов кластера.
Альтернативный вариант: сочетание стандарта и ik, полученное с помощью match_phrase. Пользовательский токенизатор nGram, используйте match_phrase для поиска или узнайте, можно ли использовать менее точный метод поиска? Комбинируйте запросы с match_phrase и slop.
Чтобы удовлетворить запрос с подстановочными знаками, он должен выполнить итерацию по всем элементам, что влечет за собой большие накладные расходы на обработку. Это должно работать, но это определенно не работает.
- Вы можете использовать search.allow_expensive_queries = false, чтобы отключить подстановочные знаки от любого члена команды.
Прогрев данных
Часто могут быть горячие ключевые слова для поиска.При поиске соответствующий индекс сегмента еще не находится в памяти, поэтому требуется такой процесс, как кэширование с диска >>>, который намного медленнее, чем прямой запрос памяти.Однако после период времени память может быть заменена другими проиндексированными сегментами, поэтому следующий поиск требует такого длительного процесса:
Поскольку память ElasticSearch ограничена, мы можем представить, что данные в его памяти подобны пространству фиксированного размера, управляемому алгоритмом LRU.Мы можем найти способ запускать поиск горячих данных через определенные промежутки времени, чтобы они всегда находились в памяти ES. (куча JVM).
Оптимизация записи
Лог лучше всего использовать Rollover
По сравнению с журналом Eryan, вы можете использовать шаблон ролловера + индекса, чтобы свернуть индекс по времени, чтобы избежать огромного количества данных, генерируемых индексом и фиксированным сегментом, что приведет к катастрофе поиска. Индекс десятков миллиардов документов установлен с 5 осколками, что может гарантировать, что фрагментация не будет потрачена впустую, а производительность в реальном времени гарантирована.
Лог-система на базе ELK и ELFK еще проще, правила нам предоставлены, достаточно их настроить.
Уменьшите количество обновлений
ES — это движок, работающий почти в реальном времени, а не в реальном времени.По умолчанию используется значение 1S, поскольку Lucene сначала записывает данные для записи в память, а когда оно превышает 1 секунду (по умолчанию), запускается обновление, а затем Refresh обновит данные в памяти до файлового кэша операционной системы.
В некоторых сценариях, если производительность поиска в реальном времени не очень высока, например: отчеты, созданные в полночь, журналы и т. д., можно рассмотреть возможность увеличения события обновления 1С по умолчанию и уменьшения количества слияний сегментов.
index.refresh_interval:20s
Каждый каталог монтирует отдельный диск
Этот сценарий может быть отражен в упомянутом выше узком месте памяти 32G.Сервер с памятью 128G разделен на 2 узла.В каталоге данных мы делим 2 каталога и монтируем их на разные жесткие диски (должны быть разные физические жесткие диски). , а не раздел...) Это эквивалентно выполнению raid0, который может значительно улучшить скорость записи. Конечно, она не безгранична или существует узкое место в пропускной способности сетевой карты. Если облачный сервис представляет собой механический жесткий диск, это делает смысла делать это.
- Необходимые условия: одна машина, разные узлы, разные жесткие диски.
Этот подход является общим для других распределенных систем хранения.
Архив первого релиза Github:GitHub.com/Вопросы и ответы в сторону/B…