Предкредитная система отвечает за реализацию всех бизнес-процессов от поступления до предварительного кредита, который включает в себя несколько комплексных запросов с большими объемами данных, различными условиями и сложностями.Внедрение ElasticSearch в основном предназначено для повышения эффективности запросов; и это есть надежда, что он основан на ElasticSearch, простом хранилище данных, обеспечивающем некоторые функции, связанные с OLAP. Есть некоторые резюме опыта, чтобы представить вам.
Запросы с использованием битовых индексов: • Мужские и женатые записи = 101110011 и 11010010 = 100100010, то есть 1-й, 4-й и 8-й пользователи — женатые мужчины. • Женские или незамужние записи = 010001100 | 001010100 = 011011100, то есть 2-й, 3-й, 5-й, 6-й и 7-й пользователи являются женщинами или незамужними.
Индекс первичного ключа на рис. 5 — это левая половина рис. 5 (если автономный первичный ключ не определен явно, в качестве кластеризованного индекса используется непустой уникальный индекс. Если уникального индекса нет, innodb автоматически сгенерирует 6-байтовый индекс. Первичный ключ скрыт для индекса кластеризации), а конечный узел хранит полную информацию о строке данных (хранящуюся в форме первичного ключа + row_data). Вторичный индекс также хранится в виде дерева B. В правой половине рисунка 5 отличие от первичного ключа состоит в том, что конечные узлы вторичного индекса хранят не данные строки, а значение ключа индекса и соответствующее значение первичного ключа. Можно сделать вывод, что запрос вторичного индекса выполняет еще один шаг, чтобы найти первичный ключ данных. Сохранение упорядоченного и сбалансированного N-арного дерева более сложным делом является корректировка положения узла при вставке узла, особенно когда вставляемый узел случайный и неупорядоченный, а при вставке упорядоченного узла происходит только корректировка узла во всем дереве, локальная область воздействия меньше, а эффективность выше. Вы можете обратиться к алгоритму вставки узлов красно-черного дерева: https://en.wikipedia.org/wiki/Red%E2%80%93black_tree. Поэтому, если таблица innodb имеет автоинкрементный первичный ключ, данные записывается по порядку, Эффективность будет очень высокой; если в таблице innodb нет автоинкрементного первичного ключа, вставка случайного значения первичного ключа приведет к большому количеству изменений в B+дереве, а эффективность низкий. Вот почему рекомендуется, чтобы таблица innodb имела автоматически увеличивающийся первичный ключ, который не имеет бизнес-значения, что может значительно повысить эффективность вставки данных. Примечание:• Mysql Innodb использует самоувеличивающиеся первичные ключи для эффективной вставки. • При использовании алгоритма генерации идентификаторов, подобного Snowflake, количество сгенерированных идентификаторов имеет тенденцию к увеличению, а эффективность вставки относительно высока.
Приведенный выше набор документов анализируется с помощью сегментации слов, и найдено 10 слов: [Google, карта, отец, смена работы, Facebook, присоединение, основатель, Ларс, уход и] с первым словом «Google» в качестве примера. : сначала дайте ему уникальный идентификатор «Word ID», значение равно 1, а частота документа равна 5, то есть появляются все 5 документов, кроме 3-го документа, который появляется дважды, остальные документы появляются один раз, поэтому есть Рисунок 11 Перевернутый индекс из .
Словарный индекс BTREE аналогичен вторичному индексу Innodb: слова сортируются по определенным правилам для создания индекса BTree, а узел данных является указателем на инвертированный индекс.
Двоичный поиск также сортирует слова в соответствии с определенными правилами, устанавливает упорядоченный массив слов и использует метод бинарного поиска при поиске; метод бинарного поиска может быть сопоставлен с упорядоченным сбалансированным двоичным деревом, как показано на рисунке 14.
FST (Finite State Transducers) реализует FST как конечный автомат передачи состояний FST имеет два преимущества: 1) Небольшой размер. За счет повторного использования префиксов и суффиксов слов в словаре пространство для хранения сжимается; 2) Скорость запроса высокая. O(len(str)) сложность времени запроса. Возьмите вставку из 5 слов «кошка», «глубокий», «делать», «собака», «собаки» в качестве примера для построения FST (примечание: должны быть отсортированы).15 Рисунок 15 В итоге мы получаем ориентированный ациклический граф, как и выше. Используя эту структуру, очень удобно выполнять запросы, например, по слову «собака» мы можем легко запросить, существует ли оно или нет через приведенную выше структуру, и даже мы можем связать слово с определенным числом или словом во время процесс построения, тем самым реализуя сопоставление ключ-значение. Конечно, есть и другие методы оптимизации, такие как использование Skip List, Trie, Double Array Trie и других структур для оптимизации, поэтому я не буду вдаваться в подробности.
• Существующие поля в сопоставлении не могут быть обновлены.Если поле было инициализировано (динамическое сопоставление путем вставки данных, предопределенное путем установки типа поля), то тип поля определяется, и при этом будет сообщено об ошибке. вставка несовместимых данных, таких как определение. Если записывается поле длинного типа, если записывается нечисловой тип данных, ES вернет подсказку об ошибке типа данных. В этом случае может потребоваться перестроить индекс, и упомянутый выше псевдоним пригодится; обычно это делается в 3 шага: 1) Создайте новый индекс, чтобы указать неправильное поле формата как правильный формат, 2) Используйте переиндексацию ES API переносит данные из старого индекса в новый индекс. 3) Используйте API псевдонимов, чтобы добавить псевдоним старого индекса в новый индекс и удалить связь между старым индексом и псевдонимом. Вышеуказанные шаги подходят для офлайн-миграции, но если вы хотите реализовать живую миграцию без простоев, шаги будут немного сложнее. • Основная операция API — добавление, удаление, изменение и поиск.Вы можете обратиться к официальной документации ES: https://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html. Для некоторых более сложных операций требуется ES Script , обычно используется Groovy-подобный безболезненный скрипт, этот скрипт поддерживает некоторые часто используемые JAVA API (установка ES использует JDK8, поэтому поддерживаются некоторые API JDK8), время Joda и т. д. также поддерживаются. Возьмем более сложный пример обновления, чтобы проиллюстрировать, как безболезненно используется сценарий: Описание требования: appSubmissionTime представляет время входа, LensStartDate представляет время начала класса, а expectLoanDate представляет время кредита. Требуется, чтобы дата поступления была 10 сентября 2018 г. Если разница между временем поступления и временем начала занятий составляет менее 2 дней, в качестве времени поступления будет установлено время кредита. Безболезненный сценарий выглядит следующим образом:
• Данные запроса здесь представляют собой подключаемый модуль ES ES-SQL: https://github.com/NLPchina/elasticsearch-sql/wiki/Basic-Queries-And-Conditions Этот подключаемый модуль предоставляет более богатый синтаксис запросов SQL, давайте Данные можно запрашивать с помощью знакомых операторов SQL. Среди них есть несколько моментов, на которые следует обратить внимание: • ES-SQL использует Http GET для отправки ситуации, поэтому длина SQL ограничена (4 КБ), которую можно изменить следующими параметрами: http.max_initial_line_length: "8k"• Вычислить сумму, среднее значение и другие числовые операции. Если для поля задан нечисловой тип, при непосредственном использовании ESQL будет сообщено об ошибке. Вместо этого вы можете использовать безболезненные скрипты. • Результат, полученный с помощью синтаксиса Выбрать как, отличается от общего результата запроса, структура расположения данных отличается и требует отдельной обработки. • NRT (почти в реальном времени): вставьте запись в ES в квазиреальном времени, а затем запросите ее. Как правило, можно найти самую последнюю запись. ES похожа на поисковую систему в реальном времени, чего мы и ожидаем. Однако на самом деле это не всегда так, это связано с механизмом записи ES.Сделаем краткое введение: — Сегмент индекса Lucene-> Данные, записываемые индексом ES в ES, сначала записываются в сегмент индекса Lucene, а затем записываются в индекс ES.Перед записью в индекс ES все старые данные находятся. — commit: данные в сегменте индекса операции атомарной записи будут записаны в индекс ES в режиме атомарной записи, поэтому можно гарантировать, что запись, отправленная в ES, будет полностью успешно записана, не беспокоясь о том, что только ее часть пишется, а другой Some записывает с ошибкой. – обновление: операция обновления гарантирует, что последняя отправка будет найдена в сегменте индекса, и есть последний шаг: обновление.После завершения этого шага можно искать данные в новом индексе. Из соображений производительности Lucene откладывает обновления, требующие много времени, поэтому он не обновляется каждый раз при добавлении документа, а обновляется каждую секунду по умолчанию. Это обновление уже происходит очень часто, но есть много приложений, требующих более высокой частоты обновления. Если это так, либо используйте другой метод, либо проверьте, являются ли требования разумными. Однако ES предоставляет нам удобный интерфейс запроса в реальном времени.Данные, запрашиваемые с помощью этого интерфейса, всегда самые свежие.Метод вызова описывается следующим образом: GET http://IP:PORT/index_name/type_name/id Приведенный выше интерфейс использует метод HTTP GET для запроса на основе первичного ключа данных (id). Этот метод запроса будет искать данные в индексе ES и сегменте индекса Lucene. в то же время, и объединить их, поэтому окончательный результат всегда актуален. Но есть побочный эффект: каждый раз, когда выполняется эта операция, ES будет принудительно выполнять операцию обновления, что приведет к IO, а при частом использовании это также повлияет на производительность ES. • Обработка массивов Обработка массивов — это особое явление, поэтому давайте поговорим о нем отдельно. – Представление представляет собой обычный формат массива JSON, например: • [1, 2, 3], [“a”, "b"], [ { "first" : "John", "last" : "Smith" },{"first" : "Alice", "last" : "White"} ] - Обратите внимание, что он не существует в ES Тип массива в конечном итоге будет преобразован в объект, ключевое слово и другие типы. – Проблема обычного запроса объекта массива. Хранение обычных объектов массива будет сглаживать данные и хранить поля отдельно, например:
указатель
Описание: структура данных, предназначенная для быстрого поиска данных. Индекс похож на оглавление перед книгой, что может ускорить скорость запросов к базе данных. Понимание построения и использования индексов очень полезно для понимания режима работы ES.Введение в общие индексы
1. Битовый индекс 2. Хэш-индекс 3. Индекс BTREE 4. Инвертированный индекс1.1. Растровый индекс (BitMap)
Битовый индекс подходит для случая, когда значение поля представляет собой ограниченное число перечислимых значений.Битовый индекс использует строку двоичных чисел (bitMap), чтобы определить, существуют ли данные, 1 указывает, что в текущем местоположении есть данные (последовательный число), а 0 указывает на отсутствие данных в текущем местоположении. На рисунке 1 ниже представлена пользовательская таблица, в которой хранятся два поля пола и семейного положения, а на рисунке 2 установлены два битовых индекса для пола и семейного положения соответственно. Например: Пол->Мужской. Соответствующий индекс: 101110011, указывающий, что 1-й, 3-й, 4-й, 5-й, 8-й и 9-й пользователи — мужчины. Другие свойства и так далее.Запросы с использованием битовых индексов: • Мужские и женатые записи = 101110011 и 11010010 = 100100010, то есть 1-й, 4-й и 8-й пользователи — женатые мужчины. • Женские или незамужние записи = 010001100 | 001010100 = 011011100, то есть 2-й, 3-й, 5-й, 6-й и 7-й пользователи являются женщинами или незамужними.
1.2. Хэш-индекс
Как следует из названия, это относится к структуре индекса, которая использует определенную хеш-функцию для реализации сопоставления ключ-> значение. Хэш-индекс подходит для поиска равных значений, а местоположение данных можно определить с помощью одного хеш-вычисления. На рис. 3 ниже показана структура хеш-индекса, которая аналогична реализации HashMap в JAVA и использует таблицу конфликтов для разрешения хэш-конфликтов.Рисунок 31.3 Индекс BTREE
Индекс BTREE — это наиболее часто используемая структура индекса в реляционных базах данных, которая упрощает операции запроса данных. BTREE: Упорядоченное сбалансированное дерево порядка N, каждый узел имеет N ключевых значений и N+1 указателей, указывающих на N+1 дочерних узлов. Простая структура BTREE показана ниже на рисунке 4. Это двухуровневое трехмерное дерево с 7 фрагментами данных:На рис. 4 в качестве примера для описания применения индекса BTREE используется наиболее часто используемый движок InnoDB для Mysql. Таблицы в Innodb хранятся в виде индексно-организованных таблиц, то есть вся таблица данных хранится в структуре B+tree, как показано на рисунке 5.Индекс первичного ключа на рис. 5 — это левая половина рис. 5 (если автономный первичный ключ не определен явно, в качестве кластеризованного индекса используется непустой уникальный индекс. Если уникального индекса нет, innodb автоматически сгенерирует 6-байтовый индекс. Первичный ключ скрыт для индекса кластеризации), а конечный узел хранит полную информацию о строке данных (хранящуюся в форме первичного ключа + row_data). Вторичный индекс также хранится в виде дерева B. В правой половине рисунка 5 отличие от первичного ключа состоит в том, что конечные узлы вторичного индекса хранят не данные строки, а значение ключа индекса и соответствующее значение первичного ключа. Можно сделать вывод, что запрос вторичного индекса выполняет еще один шаг, чтобы найти первичный ключ данных. Сохранение упорядоченного и сбалансированного N-арного дерева более сложным делом является корректировка положения узла при вставке узла, особенно когда вставляемый узел случайный и неупорядоченный, а при вставке упорядоченного узла происходит только корректировка узла во всем дереве, локальная область воздействия меньше, а эффективность выше. Вы можете обратиться к алгоритму вставки узлов красно-черного дерева: https://en.wikipedia.org/wiki/Red%E2%80%93black_tree. Поэтому, если таблица innodb имеет автоинкрементный первичный ключ, данные записывается по порядку, Эффективность будет очень высокой; если в таблице innodb нет автоинкрементного первичного ключа, вставка случайного значения первичного ключа приведет к большому количеству изменений в B+дереве, а эффективность низкий. Вот почему рекомендуется, чтобы таблица innodb имела автоматически увеличивающийся первичный ключ, который не имеет бизнес-значения, что может значительно повысить эффективность вставки данных. Примечание:• Mysql Innodb использует самоувеличивающиеся первичные ключи для эффективной вставки. • При использовании алгоритма генерации идентификаторов, подобного Snowflake, количество сгенерированных идентификаторов имеет тенденцию к увеличению, а эффективность вставки относительно высока.
1.4 Инвертированный индекс (Inverted Index)
Инвертированный индекс также называют обратным индексом, который можно сравнить с прямым индексом. Прямой индекс отражает соответствие между документом и ключевыми словами в документе; по идентификатору документа можно получить информацию о ключевых словах, частоте слов и положении слова в текущем документе, как показано на рисунке 6. слева, а индексы справа.картина 6 Обратный индекс относится к соответствию между ключевым словом и документом, в котором находится это слово; при наличии идентификатора ключевого слова вы можете получить список всех документов, в которых находится ключевое слово, включая частоту слова, местонахождение и другую информацию, как показано на рисунке 7 показано.Набор слов и документов с обратным индексом (инвертированный индекс) на рисунке 7 составляет «матрицу слово-документ», как показано на рисунке 8, а отмеченные ячейки указывают на то, что между словом и документом существует отношение отображения.Для структуры хранения инвертированного индекса на фиг. 8 можно сделать ссылку на фиг. 9. Словарь хранится в памяти, а словарь представляет собой список всех слов, разобранных из всего набора документов, каждое слово указывает на соответствующий ему инвертированный список, а набор инвертированных списков составляет инвертированный файл. диске, а информация о соответствующем слове в документе записывается в инвертированный список, то есть такая информация, как упомянутая выше частота и позиция слова.Рис. 9 Структура инвертированного индекса Ниже приведен конкретный пример, описывающий создание инвертированного индекса из коллекции документов. Как показано на рисунке 10, всего имеется 5 документов, первый столбец — это номер документа, а второй столбец — это текстовое содержимое документа.Приведенный выше набор документов анализируется с помощью сегментации слов, и найдено 10 слов: [Google, карта, отец, смена работы, Facebook, присоединение, основатель, Ларс, уход и] с первым словом «Google» в качестве примера. : сначала дайте ему уникальный идентификатор «Word ID», значение равно 1, а частота документа равна 5, то есть появляются все 5 документов, кроме 3-го документа, который появляется дважды, остальные документы появляются один раз, поэтому есть Рисунок 11 Перевернутый индекс из .
1.4.1. Оптимизация запросов словарного словаря
Для крупномасштабной коллекции документов, которая может содержать сотни тысяч или даже миллионы разных слов, возможность быстрого нахождения слова будет напрямую влиять на скорость отклика во время поиска.Схема оптимизации заключается в создании словаря слов для индекса, существуют следующие схемы для справки: Словарь Хэш-индекс Хэш-индекс является простым и прямым, чтобы запросить слово, вычислив хеш-функцию, если хеш-таблица попадает, это означает, что данные существуют, в противном случае он может напрямую возвращаться пустым; подходит для точного совпадения, равнозначного запроса. Как показано на рис. 12, слова с одинаковым значением хеш-функции помещаются в таблицу конфликтов.Словарный индекс BTREE аналогичен вторичному индексу Innodb: слова сортируются по определенным правилам для создания индекса BTree, а узел данных является указателем на инвертированный индекс.
Двоичный поиск также сортирует слова в соответствии с определенными правилами, устанавливает упорядоченный массив слов и использует метод бинарного поиска при поиске; метод бинарного поиска может быть сопоставлен с упорядоченным сбалансированным двоичным деревом, как показано на рисунке 14.
FST (Finite State Transducers) реализует FST как конечный автомат передачи состояний FST имеет два преимущества: 1) Небольшой размер. За счет повторного использования префиксов и суффиксов слов в словаре пространство для хранения сжимается; 2) Скорость запроса высокая. O(len(str)) сложность времени запроса. Возьмите вставку из 5 слов «кошка», «глубокий», «делать», «собака», «собаки» в качестве примера для построения FST (примечание: должны быть отсортированы).15 Рисунок 15 В итоге мы получаем ориентированный ациклический граф, как и выше. Используя эту структуру, очень удобно выполнять запросы, например, по слову «собака» мы можем легко запросить, существует ли оно или нет через приведенную выше структуру, и даже мы можем связать слово с определенным числом или словом во время процесс построения, тем самым реализуя сопоставление ключ-значение. Конечно, есть и другие методы оптимизации, такие как использование Skip List, Trie, Double Array Trie и других структур для оптимизации, поэтому я не буду вдаваться в подробности.
Два опыта работы с ElasticSearch
Ниже приводится краткое изложение некоторого опыта ES, основанного на конкретных случаях использования системы предварительного кредита.- Версия ES, используемая в настоящее время: 5.6
- Адрес официального сайта: https://www.elastic.co/products/elasticsearch
- Введение в одно предложение ES: The Heart of the Elastic Stack (с официального сайта)
- Некоторая ключевая информация от ES:
- Впервые выпущен в феврале 2010 г.
- Магазин Elasticsearch, поиск и анализ
- Богатый спокойный интерфейс
основная концепция
• Индекс (индекс) Индекс ЭП, то есть Index, не то же самое понятие, что упомянутый выше индекс, здесь имеется в виду совокупность всех документов, которые можно сравнить с базой данных в РБД. • Документ — это запись, записываемая в ES, обычно в формате JSON. • Сопоставление описания метаданных структуры данных документа, обычно в форме схемы JSON, которая может быть динамически сгенерирована или определена заранее. •типИз-за ошибок в понимании и использовании тип устарел, в настоящее время для индекса в используемой нами ES установлен только один тип по умолчанию. • Узел Служебный экземпляр ES называется сервисным узлом. Чтобы обеспечить безопасность и надежность данных, а также повысить производительность запросов к данным, ES обычно развертывается в кластерном режиме. • Несколько узлов ES в кластере взаимодействуют друг с другом и совместно используют хранилище данных и запросы, образуя таким образом кластер. • Разделение Разделение в основном предназначено для хранения большого объема данных, разделения данных на несколько частей, и разделение обычно равномерно распределяется на каждом узле ES. Примечание. Количество осколков изменить нельзя. • Полная копия данных осколка реплики.Как правило, у осколка будет одна реплика.Реплика может обеспечивать запросы данных, а производительность запросов может быть повышена в кластерной среде. Установка и развертывание • Версия JDK: JDK1.8• Процесс установки относительно прост, обратитесь к официальному веб-сайту: Загрузите установочный пакет -> Разархивировать -> Выполнить • Ошибка во время установки: запуск ES занимает много системных ресурсов, и системные параметры, такие как количество файловых дескрипторов, потоков и памяти, необходимо настроить.Пожалуйста, обратитесь к следующим документам. http://www.cnblogs.com/sloveling/p/elasticsearch.htmlПример объяснения
Далее описывается использование ES с некоторыми специфическими операциями: Initialize the index для инициализации индекса, в основном для создания нового индекса в ES и инициализации некоторых параметров, включая имя индекса, отображение документа (Mapping), псевдоним индекса, количество осколков ( по умолчанию: 5), количество реплик (по умолчанию: 1) и т. д. Количество шардов и реплик может напрямую использовать значения по умолчанию, когда объем данных невелик, и настройка не требуется. Вот два способа инициализации индекса: один использует динамическое сопоставление на основе динамического шаблона, а другой использует явное предопределенное сопоставление. 1. Динамические шаблоны (Динамический шаблон)<p style="line-height: 2em;"><span style="font-size: 14px;">curl -X PUT http://ip:9200/loan_idx -H 'content-type: application/json' <br> -d '{"mappings":{ "order_info":{ "dynamic_date_formats":["yyyy-MM-dd HH:mm:ss||yyyy-MM-dd],<br> "dynamic_templates":[<br> {"orderId2":{<br> "match_mapping_type":"string",<br> "match_pattern":"regex",<br> "match":"^orderId$",<br> "mapping":{<br> "type":"long"<br> }<br> }<br> },<br> {"strings_as_keywords":{<br> "match_mapping_type":"string",<br> "mapping":{<br> "type":"keyword",<br> "norms":false<br> }<br> }<br> }<br> ]<br> }<br>},<br>"aliases":{<br> "loan_alias":{}<br>}}'<br></span></p>
Приведенная выше строка JSON представляет собой динамический шаблон, который мы используем, который определяет формат даты: поле dynamic_date_formats; определяет правило orderId2: всякий раз, когда встречается поле orderId, оно будет преобразовано в длинный тип; определяет правило strings_as_keywords: всякий раз, когда строка Обнаружены все поля типа сопоставляются с типом ключевого слова, а атрибут норм имеет значение false; о типе ключевого слова и ключевом слове норм они будут представлены в разделе типа данных ниже. 2. Предопределенное сопоставление Разница между предопределенным сопоставлением и описанным выше заключается в том, что все известные описания типов полей записываются в сопоставление заранее.На следующем рисунке в качестве примера показана часть:16 Верхняя часть структуры JSON на рисунке 16 такая же, как у динамического шаблона.Содержимое в красном поле представляет собой предопределенные атрибуты: apply.applyInfo.appSubmissionTime, apply.applyInfo.applyId, apply.applyInfo.applyInputSource и другие поля, тип указывает тип поля.После завершения определения сопоставления вставленные данные должны соответствовать определению поля, иначе ES вернет исключение. •
Общие типы данных: общие типы данных: текст, ключевое слово, дата, длинный, двойной, логический, ip. При фактическом использовании тип строки определяется как ключевое слово вместо текста. Основная причина заключается в том, что будут использоваться данные текстового типа. как текст для анализа синтаксиса, выполнять сегментацию слов, фильтрацию и другие операции, а тип ключевого слова сохраняется как полные данные, что устраняет избыточные операции и повышает производительность индекса. Существует также норма ключевого слова, используемая в сочетании с ключевым словом, для которого установлено значение false, чтобы указать, что текущее поле не участвует в оценке; так называемая оценка относится к присвоению оценки результату запроса в соответствии с TF/ IDF или некоторые другие правила слова для отображения результатов поиска.
В общих бизнес-сценариях такая операция сортировки не требуется (есть четкие поля сортировки), чтобы дополнительно оптимизировать эффективность запросов. • Имя индекса нельзя изменить. Чтобы инициализировать индекс, имя индекса должно быть явно указано в URL-адресе. После указания его нельзя изменить. Поэтому для построения индекса необходимо указать псевдоним по умолчанию:<p style="line-height: 2em;"><span style="font-size: 14px;">"aliases":{ "loan_alias":{ }<br> }<br></span></p>
Псевдонимы и имена индексов находятся в отношениях «многие ко многим», то есть индекс может иметь несколько псевдонимов, а псевдоним может отображать несколько индексов; в режиме «один к одному» псевдонимы могут использоваться везде, где используются имена индексов. ; Преимущество псевдонимов в том, что их можно изменить в любое время, что очень гибко.• Существующие поля в сопоставлении не могут быть обновлены.Если поле было инициализировано (динамическое сопоставление путем вставки данных, предопределенное путем установки типа поля), то тип поля определяется, и при этом будет сообщено об ошибке. вставка несовместимых данных, таких как определение. Если записывается поле длинного типа, если записывается нечисловой тип данных, ES вернет подсказку об ошибке типа данных. В этом случае может потребоваться перестроить индекс, и упомянутый выше псевдоним пригодится; обычно это делается в 3 шага: 1) Создайте новый индекс, чтобы указать неправильное поле формата как правильный формат, 2) Используйте переиндексацию ES API переносит данные из старого индекса в новый индекс. 3) Используйте API псевдонимов, чтобы добавить псевдоним старого индекса в новый индекс и удалить связь между старым индексом и псевдонимом. Вышеуказанные шаги подходят для офлайн-миграции, но если вы хотите реализовать живую миграцию без простоев, шаги будут немного сложнее. • Основная операция API — добавление, удаление, изменение и поиск.Вы можете обратиться к официальной документации ES: https://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html. Для некоторых более сложных операций требуется ES Script , обычно используется Groovy-подобный безболезненный скрипт, этот скрипт поддерживает некоторые часто используемые JAVA API (установка ES использует JDK8, поэтому поддерживаются некоторые API JDK8), время Joda и т. д. также поддерживаются. Возьмем более сложный пример обновления, чтобы проиллюстрировать, как безболезненно используется сценарий: Описание требования: appSubmissionTime представляет время входа, LensStartDate представляет время начала класса, а expectLoanDate представляет время кредита. Требуется, чтобы дата поступления была 10 сентября 2018 г. Если разница между временем поступления и временем начала занятий составляет менее 2 дней, в качестве времени поступления будет установлено время кредита. Безболезненный сценарий выглядит следующим образом:
<p style="line-height: 2em;"><span style="font-size: 14px;">POST loan_idx/_update_by_query<br> { "script":{ "source":"long getDayDiff(def dateStr1, def dateStr2){ <br> LocalDateTime date1= toLocalDate(dateStr1); LocalDateTime date2= toLocalDate(dateStr2); ChronoUnit.DAYS.between(date1, date2);<br> }<br> LocalDateTime toLocalDate(def dateStr)<br> { <br> DateTimeFormatter formatter = DateTimeFormatter.ofPattern(\"yyyy-MM-dd HH:mm:ss\"); LocalDateTime.parse(dateStr, formatter);<br> }<br> if(getDayDiff(ctx._source.appSubmissionTime, ctx._source.lenssonStartDate) < 2)<br> { <br> ctx._source.expectLoanDate=ctx._source.appSubmissionTime<br> }", "lang":"painless"<br> }<br> , "query":<br> { "bool":{ "filter":[<br> { "bool":{ "must":[<br> { "range":{ <br> "appSubmissionTime":<br> {<br> "from":"2018-09-10 00:00:00", "to":"2018-09-10 23:59:59", "include_lower":true, "include_upper":true<br> }<br> }<br> }<br> ]<br> }<br> }<br> ]<br> }<br> }<br>}<br></span></p>
Объяснение: Весь текст разделен на две части, ключевое слово запроса в нижней части представляет собой запрос по временному диапазону (10 сентября 2018 г.), а скрипт в верхней части представляет собой операцию над совпадающей записью, которая представляет собой кусок Groovy-подобного кода (основы Java легко читаются), отформатированного следующим образом, в котором определены два метода getDayDiff() и toLocalDate(), а оператор if содержит определенные операции:<p style="line-height: 2em;"><span style="font-size: 14px;">long getDayDiff(def dateStr1, def dateStr2){<br> LocalDateTime date1= toLocalDate(dateStr1);<br> LocalDateTime date2= toLocalDate(dateStr2);<br> ChronoUnit.DAYS.between(date1, date2);<br>}<br>LocalDateTime toLocalDate(def dateStr){<br> DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");<br> LocalDateTime.parse(dateStr, formatter);<br>}if(getDayDiff(ctx._source.appSubmissionTime, ctx._source.lenssonStartDate) < 2){<br> ctx._source.expectLoanDate=ctx._source.appSubmissionTime<br>}<br></span></p>
Затем отправьте запрос POST, чтобы завершить изменение данных.• Данные запроса здесь представляют собой подключаемый модуль ES ES-SQL: https://github.com/NLPchina/elasticsearch-sql/wiki/Basic-Queries-And-Conditions Этот подключаемый модуль предоставляет более богатый синтаксис запросов SQL, давайте Данные можно запрашивать с помощью знакомых операторов SQL. Среди них есть несколько моментов, на которые следует обратить внимание: • ES-SQL использует Http GET для отправки ситуации, поэтому длина SQL ограничена (4 КБ), которую можно изменить следующими параметрами: http.max_initial_line_length: "8k"• Вычислить сумму, среднее значение и другие числовые операции. Если для поля задан нечисловой тип, при непосредственном использовании ESQL будет сообщено об ошибке. Вместо этого вы можете использовать безболезненные скрипты. • Результат, полученный с помощью синтаксиса Выбрать как, отличается от общего результата запроса, структура расположения данных отличается и требует отдельной обработки. • NRT (почти в реальном времени): вставьте запись в ES в квазиреальном времени, а затем запросите ее. Как правило, можно найти самую последнюю запись. ES похожа на поисковую систему в реальном времени, чего мы и ожидаем. Однако на самом деле это не всегда так, это связано с механизмом записи ES.Сделаем краткое введение: — Сегмент индекса Lucene-> Данные, записываемые индексом ES в ES, сначала записываются в сегмент индекса Lucene, а затем записываются в индекс ES.Перед записью в индекс ES все старые данные находятся. — commit: данные в сегменте индекса операции атомарной записи будут записаны в индекс ES в режиме атомарной записи, поэтому можно гарантировать, что запись, отправленная в ES, будет полностью успешно записана, не беспокоясь о том, что только ее часть пишется, а другой Some записывает с ошибкой. – обновление: операция обновления гарантирует, что последняя отправка будет найдена в сегменте индекса, и есть последний шаг: обновление.После завершения этого шага можно искать данные в новом индексе. Из соображений производительности Lucene откладывает обновления, требующие много времени, поэтому он не обновляется каждый раз при добавлении документа, а обновляется каждую секунду по умолчанию. Это обновление уже происходит очень часто, но есть много приложений, требующих более высокой частоты обновления. Если это так, либо используйте другой метод, либо проверьте, являются ли требования разумными. Однако ES предоставляет нам удобный интерфейс запроса в реальном времени.Данные, запрашиваемые с помощью этого интерфейса, всегда самые свежие.Метод вызова описывается следующим образом: GET http://IP:PORT/index_name/type_name/id Приведенный выше интерфейс использует метод HTTP GET для запроса на основе первичного ключа данных (id). Этот метод запроса будет искать данные в индексе ES и сегменте индекса Lucene. в то же время, и объединить их, поэтому окончательный результат всегда актуален. Но есть побочный эффект: каждый раз, когда выполняется эта операция, ES будет принудительно выполнять операцию обновления, что приведет к IO, а при частом использовании это также повлияет на производительность ES. • Обработка массивов Обработка массивов — это особое явление, поэтому давайте поговорим о нем отдельно. – Представление представляет собой обычный формат массива JSON, например: • [1, 2, 3], [“a”, "b"], [ { "first" : "John", "last" : "Smith" },{"first" : "Alice", "last" : "White"} ] - Обратите внимание, что он не существует в ES Тип массива в конечном итоге будет преобразован в объект, ключевое слово и другие типы. – Проблема обычного запроса объекта массива. Хранение обычных объектов массива будет сглаживать данные и хранить поля отдельно, например:
<p style="line-height: 2em;"><span style="font-size: 14px;">{ "user":[<br> { "first":"John", "last":"Smith"<br> },<br> { "first":"Alice", "last":"White"<br> }<br> ]<br>}<br></span></p>
будет преобразован в следующий текст<p style="line-height: 2em;"><span style="font-size: 14px;">{ "user.first":[ "John", "Alice"<br> ], "user.last":[ "Smith", "White"<br> ]<br>}<br></span></p>
Связь между исходными текстами нарушена.На рисунке 17 показан краткий процесс обработки этих данных от входа в индекс до запроса: 1. Соберите данные, текст в структуру JSONArray. 2. После записи в ES по умолчанию устанавливается тип object. 3. Запросить документы, у которых user.first — Алиса, а user.last — Смит (на самом деле не существует такой вещи, как выполнение этих двух условий одновременно). 4. Возвращает неожиданные результаты.17–
Вложенные объекты массива Запросы вложенных объектов массива могут решить проблему несоответствия вышеуказанных запросов.Решение ES заключается в создании отдельного документа для каждого объекта в массиве, независимого от исходного документа. Как показано на рис. 18, после объявления данных вложенными выполняется тот же запрос, и возвращаемый результат пуст, потому что действительно нет документа, в котором user.first является Алисой, а user.last — Смитом.18–
Как правило, модификация массива полная, если нужно модифицировать поле отдельно, то нужно использовать безболезненный скрипт. update.htmlБезопасность
Безопасность данных является важнейшим звеном, которое в основном обеспечивает контроль безопасности доступа к данным с помощью следующих трех пунктов: • XPACKXPACK предоставляет подключаемый модуль безопасности, который может обеспечить контроль доступа на основе имени пользователя и пароля, а также может предоставить бесплатную пробную версию на один месяц. периода, по истечении которого будет взиматься определенная плата в обмен на лицензию. • Белый список IP-адресов означает, что на сервере ES включен брандмауэр, и только несколько серверов в интрасети могут напрямую подключаться к этой службе. • Обычно прокси-сервер не позволяет бизнес-системе напрямую подключаться к сервису ES для запросов. Ему необходимо выполнить слой упаковки для интерфейса ES, и прокси-сервер должен выполнить эту работу, а прокси-сервер может обеспечить некоторую безопасность. проверка подлинности работает, даже если XPACK неприменим, он также может обеспечить контроль безопасности.Интернет
• Серверу ElasticSearch по умолчанию необходимо открыть два порта 9200 и 9300. Нижеследующее в основном представляет ошибку, связанную с сетью. Если вы столкнетесь с похожей ошибкой, вы можете извлечь из нее уроки. Прежде чем вызывать исключения, введите ключевое слово, связанное с сетью, keepalive: HTTP keepalive и Tcp keepalive. «Соединение: Keep-Alive» включено по умолчанию в HTTP 1.1, что означает, что это HTTP-соединение можно использовать повторно, а следующий HTTP-запрос может напрямую использовать текущее соединение, тем самым повышая производительность.Как правило, keep-alive используется для HTTP. реализации пула соединений Роль проверки активности TCP отличается от роли HTTP. TPC в основном используется для реализации поддержки активности соединения. Соответствующая конфигурация в основном представляет собой параметр net.ipv4.tcp_keepalive_time, который указывает, сколько времени это занимает (по умолчанию 2 часа). ) для обмена данными для TCP-соединения. , он отправляет пакет пульса, чтобы определить, действительна ли текущая ссылка. При нормальных обстоятельствах он получает пакет подтверждения от другой стороны, указывающий, что соединение доступно. Конкретная информация об исключении приведена ниже.Описание выглядит следующим образом: развернуты два бизнес-сервера, кластер ES (в кластере три машины), подключенный через restClient (на основе HTTPClient, реализующий долгосрочное соединение), и сервер ES. в разных сегментах сети, и есть исключения.Будут регулярные события: ненормальное соединение будет происходить около 9 часов каждый день сброс по пиру.И есть три сброса соединения по пиру подряд<p style="line-height: 2em;"><span style="font-size: 14px;">Caused by: java.io.IOException: Connection reset by peer <br> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) <br> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) <br> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) <br> at sun.nio.ch.IOUtil.read(IOUtil.java:197)<br></span></p>
Чтобы решить эту проблему, мы пробовали различные решения, проверяя официальные документы, сравнивая коды и перехватывая пакеты. . . После нескольких дней напряженной работы я, наконец, обнаружил, что это исключение связано с упомянутым выше ключевым словом keepalive (благодаря помощи коллег из группы эксплуатации и обслуживания). В реальной онлайн-среде между бизнес-сервером и кластером ES установлен брандмауэр, и политика брандмауэра определяет время ожидания простоя соединения, например, 1 час, что несовместимо со значением по умолчанию для упомянутого выше сервера Linux. например, 2 часа. Поскольку в нашей текущей системе ночью меньше трафика, некоторые соединения не использовались более 2 часов. Через 1 час брандмауэр автоматически разрывает текущее соединение. Через 2 часа сервер пытается отправить подтверждение активности соединения, который напрямую блокируется брандмауэром.После нескольких попыток сервер отправляет RST для прерывания соединения, но клиент в это время не знает об этом, при использовании недействительного запроса ссылки на следующее утро сервер возвращает RST напрямую, и клиент сообщает об ошибке Connection
сбрасывается одноранговым узлом, попробовал три сервера в кластере, и все они вернули одну и ту же ошибку, поэтому было сообщено о 3 одинаковых исключениях подряд. Решение также относительно простое: изменить настройку тайм-аута проверки активности на стороне сервера, которая составляет менее 1 часа для брандмауэра.Ссылаться на
«Глубокое понимание ElasticSearch» http://www.cnblogs.com/Creator/p/3722408.htmlhttps://yq.aliyun.com/articles/108048http://www.cnblogs.com/LBSer/p/4119841.html
http://www.cnblogs.com/yjf512/p/5354055.html
◆ ◆ ◆ ◆ ◆
Если вы обнаружите ошибки в статье или у вас возникнут вопросы по содержанию, вы можете подписаться на публичный аккаунт WeChat Технологического института Исинь (CE_TECH), оставьте нам сообщение в фоновом режиме. Каждую неделю мы будем выбирать сердечного друга и отправлять красивый маленький подарок. Приходите отсканировать код, чтобы следовать за нами!