вопросы интервью
Как es может повысить эффективность запросов при наличии большого объема данных (миллиарды уровней)?
Психологический анализ интервьюера
Этот вопрос нужно задать, грубо говоря, это зависит от того, действительно ли вы сделали эс, из-за чего? На самом деле производительность es не так хороша, как вы думаете. Много раз объем данных велик, особенно когда есть сотни миллионов фрагментов данных, вы можете столкнуться с трудностями при поиске в течение 5–10 секунд. Когда выполняется первый поиск, это занимает от 5 до 10 секунд, но после этого он выполняется быстрее, может быть, несколько сотен миллисекунд.
Вы очень запутались, первый визит каждого пользователя будет медленнее, он больше застрял? Итак, если вы не играли в es или просто играете в демо-версию сами, то легко запутаться, когда вам зададут этот вопрос, который показывает, что вы действительно не очень хорошо играете в es?
Анализ вопросов интервью.
Честно говоря, для оптимизации производительности es не существует панацеи, что это значит? Просто не ожидайте, что параметр можно настроить по желанию, и вы можете универсально справиться со всеми сценариями низкой производительности. Возможно, в некоторых сценариях можно изменить параметры или настроить синтаксис, но это точно не во всех сценариях.
Убийца оптимизации производительности — кеш файловой системы
Данные, которые вы записываете в es, на самом деле записываются в файл на диске.При запросе операционная система автоматически кэширует данные в файле на диске в кеше файловой системы.
Поисковая система es в значительной степени зависит от базового кеша файловой системы.Если вы предоставите кешу файловой системы больше памяти, попытайтесь сделать так, чтобы память могла вместить все файлы данных индекса файла сегмента idx, тогда при поиске вы будете в основном обращаться к памяти, производительность будет очень высокой.
Насколько большим может быть разрыв в производительности? Во многих наших предыдущих тестах и нагрузочных тестах, если зайти на диск, то это обычно занимает секунды, а производительность поиска точно на втором уровне, 1 секунда, 5 секунд, 10 секунд. Но если вы используете кэш файловой системы, то есть чистую память, то вообще говоря, производительность на порядок выше, чем у диска, в основном в миллисекундах, от нескольких миллисекунд до сотен миллисекунд.
Вот реальный случай. У узла es компании есть 3 машины, у каждой машины много памяти, 64G, а общая память 64 * 3 = 192G. Куча es jvm для каждой машины составляет 32Гб, поэтому остаток для кеша файловой системы составляет всего 32Гб на машину, а общая память для кеша файловой системы в кластере составляет 32 * 3 = 96Гб. В настоящее время файлы данных индекса на всем диске занимают в общей сложности 1 ТБ дискового пространства на 3 машинах, а объем данных es составляет 1 ТБ, поэтому объем данных каждой машины составляет 300 ГБ. Хорошо ли это работает? Память кэша файловой системы всего 100G, десятая часть данных может храниться в памяти, а остальные на диске, а дальше вы выполняете поисковые операции, большая часть которых выполняется на диске, и производительность безусловно беден.
В конечном счете, вы хотите, чтобы es работал лучше, и в лучшем случае память вашей машины могла вместить как минимум половину вашего общего объема данных.
Согласно нашему собственному практическому опыту в производственной среде, лучше всего хранить небольшой объем данных только в es, то есть индексах, которые вы хотите искать.Если память, зарезервированная для кеша файловой системы, составляет 100 ГБ, то вы данные индекса контролируются в пределах 100G. В этом случае почти все ваши данные ищутся в памяти, и производительность очень высока, как правило, в течение 1 секунды.
Скажем, теперь у вас есть ряд данных. id, имя, возраст .... 30 полей. Но если вы ищете сейчас, вам нужно искать только по трем полям: идентификатор, имя и возраст. Если тупо прописать все поля строки данных в es, то получится сказать, что 90% данных не используются для поиска, а результат просто займет место кеша файловой системы на es-машине. чем больше объем данных в одном фрагменте данных, тем больше это приведет к тому, что кэш файловой системы сможет кэшировать меньше данных. На самом деле, достаточно написать всего несколько полей, которые будут использоваться для поиска в es, например, написать три поля es id, name, age, а затем вы можете хранить данные других полей в mysql/hbase, мы вообще рекомендуется использовать такую структуру как es+hbase.
Особенность hbase в том, что он подходит для онлайн-хранения массивных данных, то есть может записывать массивные данные в hbase, но не делать сложных поисков, а просто выполнять некоторые простые операции, такие как запросы на основе id или диапазона. Выполните поиск по имени и возрасту в es, и результатом может быть 20 идентификаторов документов, а затем в соответствии с идентификатором документа перейдите к hbase, чтобы запросить полные данные, соответствующие каждому идентификатору документа, найдите его, а затем верните на передний план. конец.
Данные, записываемые в es, предпочтительно меньше или равны или немного больше объема памяти кэша файловой системы es. Затем вы можете потратить 20 мс на получение из es, а затем перейти к hbase для запроса в соответствии с идентификатором, возвращенным es, и проверить 20 фрагментов данных, это может занять 30 мс.Может быть, вы раньше так играли, 1T данных помещается в es, и каждый раз запрос составляет 5~10 секунд, а сейчас производительность может быть очень высокой, и каждый запрос составляет 50 мс.
Прогрев данных
Предположим, даже если вы будете следовать приведенному выше плану, объем данных, записываемых каждой машиной в кластере es, по-прежнему более чем в два раза превышает размер кеша файловой системы. составляет 30 ГБ, на диске осталось еще 30 ГБ данных.
Фактически, предварительный нагрев данных может быть выполнен.
Например, возьмем Weibo в качестве примера, вы можете поставить какой-то большой V, как правило, много данных людей, вы можете настроить систему в фоновом режиме заранее, время от времени, свою собственную фоновую систему для поиска горячих данных , очистите файловую систему Когда пользователи действительно просматривают эти горячие данные позже, они просто ищут их прямо в памяти, очень быстро.
Или для электронной коммерции вы можете сделать некоторые продукты, которые вы чаще всего просматриваете, такие как iphone 8, и заранее создать программу в фоновом режиме, и активно получать к ней доступ каждую 1 минуту, и прошивать ее в кеш файловой системы.
Для тех данных, которые вы считаете горячими и к которым часто обращаются, лучше всего сделать специальную подсистему предварительного нагрева кеша, то есть время от времени обращаться к горячим данным заранее, чтобы позволить данным попасть в кеш файловой системы. Таким образом, производительность будет намного лучше, когда другие посетят его в следующий раз.
Горячее и холодное разделение
es может делать горизонтальное разбиение аналогично mysql, то есть писать отдельный индекс для большого объема данных, к которым обращаются редко и нечасто, а затем писать отдельный индекс для горячих данных, к которым обращаются часто. Лучше всего записывать холодные данные в один индекс, а затем записывать горячие данные в другой индекс, чтобы гарантировать, что после разогрева горячих данных старайтесь держать их в кэше файловой системы ОС, и не давайте холодным данным краснеть Потерять.
Видите ли, допустим, у вас есть 6 машин, 2 индекса, один для холодных данных, один для горячих данных, по 3 сегмента на индекс. 3 машины поставили индекс тепловых данных, а остальные 3 машины поставили индекс холодных данных. В этом случае вы тратите много времени на доступ к индексу горячих данных, а горячие данные могут составлять 10% от общего объема данных, в это время объем данных очень мал, и почти все хранится в кеш файловой системы, который может обеспечить доступ к горячим данным.Производительность высокая. Но для холодных данных он находится в другом индексе, не на той же машине, что и индекс для горячих данных, и все друг с другом не связаны. Если кто-то обращается к холодным данным, на диске может быть большой объем данных.В это время производительность низкая, 10% людей обращаются к холодным данным, а 90% людей обращаются к горячим данным, это не не важно.
макет документа
Для MySQL у нас часто возникают сложные реляционные запросы. Как играть в es, старайтесь не использовать сложные реляционные запросы в es, после использования производительность вообще не очень.
Лучше всего сначала завершить ассоциацию в системе Java и записать связанные данные непосредственно в es. При поиске нет необходимости использовать синтаксис поиска es для завершения связанных поисков, таких как объединение.
Дизайн модели документа очень важен.Операций много.Не хочется выполнять разные сложные и грязные операции при поиске. Существует не так много операций, которые может поддерживать es, не рассматривайте возможность использования es для некоторых вещей, с которыми непросто работать. Если есть такая операция, постарайтесь выполнить ее, когда модель документа будет разработана и написана. Кроме того, следует по возможности избегать некоторых слишком сложных операций, таких как объединение/вложение/поиск родитель-потомок, а производительность будет очень низкой.
Оптимизация производительности пейджинга
Пагинация es более ямочная, почему? Например, если у вас есть 10 фрагментов данных на странице, и вы хотите запросить 100-ю страницу, вы фактически проверите первые 1000 фрагментов данных, хранящихся на каждом сегменте, на координирующем узле. данные для каждого шарда, а затем координирующий узел объединяет и обрабатывает эти 5000 фрагментов данных, после чего получает последние 10 фрагментов данных на 100-й странице.
Распределенный, вы хотите проверить 10 кусков данных на странице 100. Нельзя сказать, что из 5 шардов каждый шард будет проверять 2 куска данных, и окончательно сливаться в 10 кусков данных на координирующем узле, верно? Вы должны проверить 1000 фрагментов данных из каждого сегмента, затем отсортировать, отфильтровать и т. д. в соответствии с вашими потребностями и, наконец, снова разбить на страницы, чтобы получить данные на 100-й странице. Когда вы перелистываете страницы, чем глубже вы перелистываете, тем больше данных возвращает каждый шард и тем дольше обрабатывается координирующий узел, что очень раздражает. Поэтому, когда вы используете es для пейджинга, вы обнаружите, что чем больше вы поворачиваетесь назад, тем медленнее он будет.
Мы также сталкивались с этой проблемой раньше.Используя es в качестве нумерации страниц, первые несколько страниц занимают всего несколько десятков миллисекунд.Когда мы переходим к 10 или десяткам страниц, в основном требуется 5-10 секунд, чтобы найти страницу данных.
Есть ли решение?
Глубокое пейджинг не разрешено (низкая производительность глубокого пейджинга по умолчанию)
Скажите продакт-менеджеру, что ваша система не позволяет вам так глубоко перелистывать страницы. Чем глубже вы перелистываете по умолчанию, тем хуже производительность.
Похожие на рекомендуемые товары в приложении постоянно вытягиваются страница за страницей
Подобно Weibo, прокрутите вниз, чтобы провести Weibo, и пролистайте страницу за страницей, вы можете использовать API прокрутки для поиска в Интернете того, как его использовать.
прокрутка будет генерировать снимок всех данных для вас за один раз, а затем каждый раз, когда вы скользите и переворачиваете страницу назад, вы будете перемещаться по курсору scroll_id, чтобы получить следующую страницу и следующую страницу.Производительность будет намного выше чем производительность пейджинга, упомянутая выше.Много, в основном в миллисекундах. Однако единственный момент заключается в том, что это подходит для сцены, похожей на прокрутку страниц Weibo, где вы не можете перейти на любую страницу по своему желанию. То есть нельзя перейти на страницу 10, потом перейти на страницу 120, потом вернуться на страницу 58, и нельзя просто прыгать. Поэтому многие продукты сейчас не позволяют листать страницы по желанию, есть приложения, а есть и некоторые веб-сайты, которые делают то, что вы можете только прокручивать вниз и листать страницу за страницей.
Параметр прокрутки должен быть указан при инициализации, сообщая es, как долго сохранять контекст этого поиска. Вы должны убедиться, что пользователь не будет перелистывать страницы в течение нескольких часов, иначе это может привести к сбою с тайм-аутом.
В дополнение к прокрутке API, вы также можете использовать search_after.Идея search_after заключается в том, чтобы использовать результаты предыдущей страницы, чтобы помочь получить данные следующей страницы.Очевидно, что этот метод не позволяет вам перелистывать страницы в будет, вы можете использовать только одну страницу назад. При инициализации необходимо использовать поле с уникальным значением в качестве поля сортировки.
Источник | 8rr.co/5Csc