вышеГоворя об эволюции архитектуры поисковой системы Youzan, для поддержки развивающейся технической архитектуры, в дополнение к обслуживанию и оптимизации Elasticsearch, мы также разработали промежуточное программное обеспечение верхнего уровня, чтобы справиться с постоянно растущими требованиями к стабильности и производительности.
Эффективность выполнения поиска Elasticsearch можно выразить следующим образом:O(num_of_files * logN)
Среди них num_of_files представляет количество сегментов файла индекса, а N представляет объем данных, которые необходимо пройти Отсюда мы можем суммировать два момента, которые можно учитывать для повышения производительности запросов:
- Уменьшите количество просматриваемых индексных файлов.
- Уменьшить общее количество проиндексированных документов, пройденных
Из самого Elasticsearch вы можете обратиться к следующим пунктам для уменьшения количества индексных файлов:
- Принудительное объединение сегментов через интерфейс оптимизации
- Увеличьте буфер индекса/интервал_обновления, уменьшите создание небольших сегментов и контролируйте количество новых сегментов, генерируемых тем же количеством документов.
Будь то принудительное слияние или буфер индекса/интервал_обновления, в сценариях его применения есть ограничения. Например, настройка буфера индекса/интервала_обновления соответственно увеличит время видимости данных; оптимизация больше подходит для холодных наборов данных. Если данные постоянно меняются , в дополнение к новым. При создании сегмента старые данные могут быть физически не удалены, поскольку старый сегмент слишком велик, но это вызовет большую нагрузку.
С точки зрения сокращения общего количества документов также могут быть сделаны соответствующие оптимизации:
- Уменьшить количество обновлений документации
- Укажите _routing для маршрутизации запросов к указанному сегменту.
- Холодная и горячая изоляция через опрокидывающийся интерфейс
Особое внимание здесь следует уделить сокращению количества обновлений документа.Из-за метода организации данных дополнительной записи LSM обновленные данные фактически представляют собой комбинацию новых данных + помеченные старые данные как удаленные.Фактический объем данных, участвующих в вычисление действительных данных и помеченных удаленных данных. Помимо уменьшения количества помеченных удалений, это также может сократить потребление слияния сегментов и обновления индекса.
Учитывая реальный бизнес-сценарий, если большой объем данных хранится в одном индексе, поскольку количество осколков неизменно, с одной стороны, индекс будет выделять большое количество осколков, а постоянный рост объема данных будет постепенно снижать производительность доступа к индексу.Улучшение производительности чтения и записи за счет расширения сегментов требует восстановления огромных объемов данных, что довольно дорого.
разделение индекса
Чтобы расширить возможности горизонтального расширения индекса, мы разделили индекс на уровне промежуточного программного обеспечения и разделили большой индекс на несколько небольших индексов в соответствии с реальным бизнес-сценарием. Перед разделением индекса сначала необходимо проверить, соответствует ли бизнес, соответствующий индексу, трем необходимым условиям для разделения:
- Операции чтения и записи должны приводить к фиксированным условиям
- Размер операции чтения и записи уникален
- Пользователей не волнуют глобальные результаты поиска
Типичным примером является поиск товаров в магазине. И покупатели, и продавцы заботятся только о результатах поиска товаров в фиксированном магазине, и нет необходимости в поиске между магазинами. Также существует фиксированная связь между внутренними магазинами и товарами. , чтобы запросы на чтение и запись могли быть прочитаны и записаны на уровне промежуточного ПО.Выполняйте синтаксический анализ и маршрутизируйте к соответствующему подиндексу, уменьшая общий объем пройденных документов и значительно повышая производительность.
По сравнению с _routing, поставляемым с Elasticsearch, это решение имеет более гибкую степень детализации управления. Например, вы можете настроить белый список для маршрутизации некоторых данных хранилища в другие индексы или кластеры с другими уровнями SLA. Конечно, вы можете сотрудничать с _routing для достижения лучших результатов. представление.
Разделение индекса, во-первых, приведет к проблеме роста данных файла глобального индекса, но, поскольку нет требования глобального поиска, оно не окажет существенного влияния; во-вторых, необходимо обратить внимание на проблему перекоса данных, которую необходимо устранить. рассчитываются в автономном режиме перед разделением. Смоделируйте эффект разделения индекса. Если вы обнаружите, что данные серьезно искажены, вы можете рассмотреть возможность повторной балансировки данных субиндекса.
Как показано на рисунке, перебалансировка данных добавляет шаг логического разделения к исходному разделению:
- Данные сначала разбиваются на 5 логических индексов.
- Установите коэффициент перебалансировки, скажем, N
- Последовательно хешируйте данные логического индекса в N последовательных физических индексов в соответствии с коэффициентом перебалансировки.
Как показано на рисунке, после ребалансировки по коэффициенту балансировки 3 максимальная разница объема данных документа уменьшается с 510 до 160, а доля отдельного индекса в общем объеме данных уменьшается с прежних 53% до 26. %, что может обеспечить хороший эффект баланса данных.
Изоляция от холода и тепла
В сценариях, где измерение запроса не является уникальным, разделение индекса неприменимо.Чтобы решить проблемы с производительностью в таких сценариях, вы можете рассмотреть возможность изоляции индекса от горячего и холодного. Например, данные типа журнал/заказ имеют очевидные временные характеристики, а большое количество операций сосредоточено в недавнем периоде времени, в это время можно рассмотреть возможность разделения их на горячие и холодные индексы на основе поля времени.
Elasticsearch поставляется с ролловерным интерфейсом для автоматической ротации индексов.В качестве условий ротации используются время существования индекса и количество сохраненных документов.Если одно из них выполнено, можно создать новый индекс и использовать его в качестве текущего активного индекса. В реальном процессе приложения интерфейс прокрутки требует, чтобы пользователь воспринял изменение активного индекса и вычислил диапазон индекса, к которому должен получить доступ запрос.С точки зрения пользователя необходимо получить доступ только к фиксированному индексу и ввести фиксированное поле.
Во-первых, настройте таблицу маршрутизации и определите различные правила маршрутизации в соответствии с различными временными интервалами.Например, приращение данных на начальном этапе бизнеса невелико, и субиндекс может быть создан с временным интервалом 50. После приращение бизнеса становится больше, временной интервал постепенно сокращается до 10. для создания субиндекса. Вычислите соответствующие смещения субиндекса из таблицы маршрутизации через начальную и конечную точки времени условия запроса, чтобы получить начальный и конечный диапазоны.В качестве примера на приведенном выше рисунке непрерывный диапазон субиндексов от индекса2 до индекса14, что то есть условие попадет в индекс в пределах этого интервала.Для всех субиндексов операция записи аналогична, разница в том, что записываемые данные попадут только в один субиндекс, который обычно является текущим активным индексом. Таким образом, разделение горячих и холодных продуктов может быть совместимо с требованиями многомерного запроса, такими как измерение запроса покупателя и продавца в заказе, а правила разделения являются более гибкими и могут динамически корректироваться. data, нужно удалить только весь индекс с истекшим сроком действия, и нет необходимости передавать delete_by_query.способ медленного удаления данных индекса. Кроме того, чтобы лучше сотрудничать с пользователями, мы также разработали вспомогательные функции, такие как автоматическая ротация указателей/очистка по времени.
HA
С широким использованием поисковой системы пользователи также выдвигают повышенные требования к стабильности системы, например, в случае сбоя питания в машинном зале, обслуживание все еще может быть гарантировано, что требует от нас возможность реплицировать данные в компьютерном зале Синхронизировать. Первое решение, которое следует рассмотреть, это построение кластера Elasticsearch через компьютерный зал, что очень просто реализовать, но проблема в том, что сетевое взаимодействие в компьютерном зале осуществляется через выделенную линию, и будет большое потребление полосы пропускания. в процессе восстановления данных из кластера простои, что может привести к перегрузке сети в машинном зале, поэтому это решение неосуществимо. Сам Elasticsearch также разрабатывает функцию Changes API, которую можно использовать для синхронизации данных между кластерами, но, к сожалению, эта функция все еще находится в стадии разработки.После обращения к основным методам синхронизации данных мы разработали набор асинхронных данных на уровне промежуточного программного обеспечения. система репликации.
Убедившись, что репликация индекса в нескольких машинных комнатах включена, сначала запустите добавочную синхронизацию на стороне прокси, отправьте сообщение синхронизации в mq как источник добавочных данных клонов программы синхронизации, а затем используйте функцию переиндексации для полного копирования. данные из первичного индекса во вторичный индекс.
В процессе межмашинной синхронизации данные легко выходят из строя из-за влияния MQ, асинхронной отправки прокси-сервера и т. д. Elasticsearch может использовать оптимистическую блокировку, чтобы обеспечить согласованность изменений данных и избежать влияния внесистемной синхронизации. порядок, при условии, что версия всегда может быть сохранена в индексе. Однако в режиме физического удаления, поскольку данные физически очищаются, номер версии не может быть сохранен, что может привести к грязной записи синхронизации данных в машинном зале.
Чтобы избежать сбоя оптимистической блокировки, нашим решением является мягкое удаление:
- Операция удаления преобразуется в операцию индексирования в промежуточном программном обеспечении.Содержимое документа содержит только специальное поле, которое не будет соответствовать обычным условиям поиска, то есть документ не может быть найден при нормальных обстоятельствах для достижения фактического эффекта удаления. .
- Преобразование таких операций, как создание/получение/обновление/удаление, в запросы сценариев в промежуточном программном обеспечении, сохраняя исходную семантику неизменной.
- Периодически очищайте данные путем обратимого удаления временных меток, записанных в специальных полях документа (необязательно)
Чтобы иметь возможность воспринимать непротиворечивость данных и задержку синхронизации между главным и подчиненным индексами, существует также набор вспомогательных систем согласования данных, работающих в режиме реального времени, которые можно использовать для проверки и восстановления данных главного и подчиненного индексов. и рассчитать данные ведущего и ведомого через задержку задержки потребления MQ.
резюме
Здесь представлена общая структура подобной поисковой системы.Из-за недостатка места все еще существует много подробных функциональных проектов, которые не были полностью описаны.Заинтересованные студенты могут связаться с нами для совместного обсуждения.Если в описании есть ошибки , вы можете связаться с нами правильно. Ни одна из двух статей об Elasticsearch на этот раз не имеет к этому особого отношения, и мы дадим вам ее в качестве расширенного чтения после того, как разберемся.