Основа самой полной серии ElasticSearch в истории (1)

Elasticsearch

предисловие

Текст был включен в мой репозиторий GitHub, добро пожаловать, звезда:GitHub.com/bin39232820…
Лучшее время посадить дерево было десять лет назад, затем сейчас

болтовня

Вчера было завершено внедрение ES, и установка завершена.Далее я должен рассказать о ES.Не знаю, сколько можно написать об этом деле.Все равно напишу немного.Эта серия Предполагается, что итерации происходят все время, что эквивалентно продукту, который постоянно обновляется, но время обновления неизвестно, ха-ха, но самые основные вещи и некоторые основополагающие принципы для того, чтобы справиться с интервью, определенно будут здесь рассмотрены. Что касается исходников, то я сейчас строчку код не читал, но если будет возможность, то все равно напишу.Далее предыдущая серия статей

Основные концепции Elasticsearch

почти в реальном времени

Почти в реальном времени, два значения, есть небольшая задержка (около 1 секунды) между записью данных и возможностью поиска данных; выполнение поиска и анализа на основе es может достигать второго уровня.

Кластер

Кластер содержит несколько узлов, и к какому кластеру принадлежит каждый узел, определяется конфигурацией (имя кластера, elasticsearch по умолчанию).Для приложений малого и среднего размера нормально иметь один узел в начале кластера.

Узел

Узел в кластере, узел также имеет имя (по умолчанию назначается случайным образом), имя узла очень важно (при выполнении операций управления эксплуатацией и обслуживанием), узел по умолчанию присоединится к кластеру с именем «elasticsearch», если вы запустите сразу кучу узлов, тогда они автоматически сформируют кластер elasticsearch, конечно, нода также может сформировать кластер elasticsearch.

Индекс (индекс - база данных)

Индекс содержит кучу данных документа с похожей структурой, например, может быть индекс клиента, индекс товарной классификации, индекс заказа, а индекс имеет имя. Индекс содержит много документов, а индекс представляет собой класс похожих или идентичных документов. Например, для создания товарного указателя, товарного указателя, в котором могут храниться все товарные данные и все товарные документы.

Индекс похож на «базу данных» в реляционных базах данных — это место, где мы храним и индексируем связанные данные.
намекать:

На самом деле наши данные хранятся и индексируются в осколках, а индекс — это просто логическое пространство, объединяющее один или несколько осколков. Впрочем, это лишь некоторые внутренние детали — нашей программе вообще наплевать на шардинг. Для нашей программы документы хранятся в файле index. Об остальных деталях позаботится Elasticsearch.

Единственное, что нам нужно сделать, это выбрать имя индекса. Имя должно быть написано строчными буквами, не может начинаться с подчеркивания и не может содержать запятые.

Тип (таблица типов)

У каждого индекса может быть один или несколько типов. Тип — это логическая классификация данных в индексе. Документы одного типа имеют одинаковые поля. Например, в системе блогов есть индекс, который может определять типы пользовательских данных, тип данных блога, данные комментариев тип.
Товарный индекс, в котором хранятся все товарные данные, товарный документ
Тем не менее, существует много типов продуктов, и поля каждого типа документа могут быть разными. Например, электрические продукты могут также включать некоторые специальные поля, такие как диапазоны времени послепродажного обслуживания; свежие продукты также включают такие поля, как срок годности свежих продуктов. специальное поле Например

  • Тип ежедневного химического продукта: product_id, product_name, product_desc, category_id, category_name
  • Тип электрического продукта: product_id, product_name, product_desc, category_id, category_name, service_period
  • Тип свежего продукта: product_id, product_name, product_desc, category_id, category_name, eat_period

Документ (строка документа)

Документ — это наименьшая единица данных в es. Документ может быть частью данных клиента, данными классификации продуктов или данными заказа, обычно представленными структурой данных JSON. Несколько документов могут храниться в типе под каждым индексом.

Поле (поле-столбец)

Поле — это наименьшая единица Elasticsearch. В документе есть несколько полей, и каждое поле является полем данных.

отображение

Для хранения данных в объекте индекса требуется конфигурация сопоставления, в том числе: тип данных, следует ли сохранять, сегментировать ли и т. д.

Это создает индекс с именем blog. Тип не нужно создавать отдельно, его можно указать при создании Mapping. Отображение используется для определения типа каждого поля в Документе, то есть используемого анализатора, индексируется оно или нет, что очень критично. Пример кода для создания сопоставления выглядит следующим образом:

client.indices.putMapping({
    index : 'blog',
    type : 'article',
    body : {
        article: {
            properties: {
                id: {
                    type: 'string',
                    analyzer: 'ik',
                    store: 'yes',
                },
                title: {
                    type: 'string',
                    analyzer: 'ik',
                    store: 'no',
                },
                content: {
                    type: 'string',
                    analyzer: 'ik',
                    store: 'yes',
                }
            }
        }
    }
});

Вышеизложенное является основной концепцией, которую следует использовать в es. Поскольку мы рассматриваем его как базу данных, я буду напрямую сравнивать его с mysql.

Аналогия между elasticsearch и базой данных

Реляционная база данных (например, Mysql) Нереляционная база данных (Elasticsearch)
База данныхБаза данных показатель
Таблица ТипТип
Строка данных Строка ДокументДокумент
Столбец данных Столбец Поле
Схема ограничения Отображение

ES сохранять данные и механизм поиска данных

Объясню на просторечии: во-первых, данные хранятся путем сегментации слов, каждое слово является индексом, и каждый индекс может найти эти данные, а при сохранении данных формируется инвертированный индекс для облегчения запроса.

основное использование

Он очень прост в использовании.У вас должно быть много инструментов для тестирования интерфейса для разработки.Подойдет любой.Сегодня мы поиграемся с его добавлениями,удалениями и изменениями.Это не путь клиента Java. Мы будем использовать restApi для его работы.

Во-первых, конечно, создать индекс

грамматика

PUT /{index}/{type}/{id}
{
  "field": "value",
  ...
}

Например, наш индекс называется «веб-сайт», тип — «блог», а идентификатор, который мы выбираем, — «123», тогда запрос индекса будет выглядеть так:

PUT /website/blog/123
{
  "title": "My first blog entry",
  "text":  "Just trying this out...",
  "date":  "2014/01/01"
}

Потом возврат консоли

Вышеприведенный пример является пользовательским идентификатором, и идентификатор также может автоматически увеличиваться, если не передано третье поле.

POST /website/blog/
{
  "title": "My second blog entry",
  "text":  "Still trying this out...",
  "date":  "2014/01/01"
}

Если разница связана с идентификатором автоинкремента, запрос POST.

Получить документы

Для получения документов из Elasticsearch используем те же _index, _type, _id, но метод HTTP изменен на GET:

GET /website/blog/123

Ответ содержит уже знакомый узел метаданных с добавлением поля _source, которое содержит исходный документ, который мы отправили в Elasticsearch при создании индекса.

{
  "_index" :   "website",
  "_type" :    "blog",
  "_id" :      "123",
  "_version" : 1,
  "found" :    true,
  "_source" :  {
      "title": "My first blog entry",
      "text":  "Just trying this out...",
      "date":  "2014/01/01"
  }
}

Содержимое ответа, возвращаемое запросом GET, включает {"found": true}. Это означает, что документация найдена. Если мы запросим несуществующий документ, мы все равно получим JSON, но найденное значение станет ложным.

Я только что получил все документы.Иногда нужны не все поля, а только часть.Как это сделать?

Как правило, запрос GET возвращает весь документ, хранящийся в параметре _source. Но, может быть, поле, которое вас интересует, это просто название. Для запроса отдельных полей можно использовать параметр _source. Несколько полей могут быть разделены запятыми:

GET /website/blog/123?_source=title,text

Выше на одно поле даты меньше, и результат правильный.

обновить документацию

Документы неизменяемы в Elasticsearch — мы не можем их изменить. Если существующий документ необходимо обновить, мы можем использовать индексный API, упомянутый в главе «Индексирование документов», чтобы переиндексировать или заменить его.

PUT /website/blog/123
{
  "title": "My first blog entry",
  "text":  "I am starting to get the hang of this...",
  "date":  "20
  }

На самом деле, так называемое обновление предназначено только для того, чтобы покрыть документ выше.Вы можете видеть, что версия этого документа также увеличилась на 1.

удалить документ

Шаблон синтаксиса для удаления документа в основном такой же, как и раньше, за исключением того, что используется метод DELETE:

DELETE /website/blog/123

Если документ будет найден, Elasticsearch вернет код состояния 200 OK и следующее тело ответа. Обратите внимание, что номер _version был увеличен.

{
  "found" :    true,
  "_index" :   "website",
  "_type" :    "blog",
  "_id" :      "123",
  "_version" : 3
}

Если документ не найден, мы получим код состояния 404 Not Found с телом ответа, подобным этому:

{
  "found" :    false,
  "_index" :   "website",
  "_type" :    "blog",
  "_id" :      "123",
  "_version" : 4
}

Вы можете узнать, успешно ли удаление, непосредственно на основе кода состояния.

оптимистичный контроль параллелизма

Elasticsearch распространяется. Когда документ создается, обновляется или удаляется, новая версия документа реплицируется на другие узлы в кластере. Elasticsearch является как синхронным, так и асинхронным, что означает, что эти запросы на репликацию отправляются параллельно и достигают места назначения не по порядку. Для этого требуется способ гарантировать, что более старые версии документов никогда не перезапишут более новые версии. Когда мы упомянули запросы index, get, delete выше, мы указали, что каждый документ имеет номер _version, который увеличивается на единицу при изменении документа. Elasticsearch использует эту _version, чтобы убедиться, что все модификации упорядочены правильно. Когда старая версия появляется после новой версии, она просто игнорируется.

Мы используем это преимущество _version, чтобы гарантировать, что данные не будут потеряны из-за конфликтующих изменений. Мы можем указать версию документа, чтобы внести нужные изменения. Если этот номер версии не актуален, наш запрос завершается ошибкой.

Используйте версию, чтобы обеспечить параллельную последовательную согласованность

Частичное обновление документа (по сути, операция повторного создания документа, только что инкапсулированного)

В главе «Обновление документов» мы говорили о способе обновления документов путем индексации, извлечения, изменения и последующего перестроения всего документа. это верно. Однако с помощью API обновления мы можем использовать один запрос для реализации частичных обновлений, таких как операции, увеличивающие число.

Мы также говорили, что документы неизменны — их нельзя изменить, только заменить. API обновления должен соответствовать тем же правилам. На первый взгляд кажется, что мы обновляем местоположение документа локально, но внутренне мы используем API обновления для обработки того же процесса поиска-модификации-переиндексации так же просто, как мы говорили ранее, и мы также уменьшаем модификации, которые другие процессы могут возникнуть конфликты. .

Простейшая форма запроса на обновление принимает локальный документ параметра документа, который объединяется с существующим документом — объекты объединяются вместе, существующие скалярные поля перезаписываются и добавляются новые поля. Например, мы можем добавить в блог поле тегов и поле просмотров, используя следующий запрос:


POST /website/blog/1/_update
{
   "doc" : {
      "tags" : [ "testing" ],
      "views": 0
   }
}

Получить несколько документов

Как и в случае с Elasticsearch, поиск нескольких документов выполняется очень быстро. Объединение нескольких запросов позволяет избежать сетевых накладных расходов на каждый запрос по отдельности. Если вам нужно получить несколько документов из Elasticsearch, быстрее использовать API-интерфейс multi-get или mget в одном запросе, чем извлекать их по одному.

Параметр mget API представляет собой массив документов, каждый узел массива определяет метаданные _index, _type, _id документа. Если вы хотите получить только одно или несколько определенных полей, вы также можете определить параметр _source:

POST /_mget
{
   "docs" : [
      {
         "_index" : "website",
         "_type" :  "blog",
         "_id" :    2
      },
      {
         "_index" : "website",
         "_type" :  "pageviews",
         "_id" :    1,
         "_source": "views"
      }
   ]
}

результат

{
    "docs": [
        {
            "_index": "website",
            "_type": "blog",
            "_id": "1",
            "_version": 2,
            "_seq_no": 1,
            "_primary_term": 1,
            "found": true,
            "_source": {
                "doc": {
                    "ada": [
                        "testing"
                    ],
                    "da": 0
                }
            }
        },
        {
            "_index": "website",
            "_type": "pageviews",
            "_id": "1",
            "found": false
        }
    ]
}

Если документы, которые вы хотите получить, находятся в одном и том же _index (или даже в одном и том же _type), вы можете определить /_index или /_index/_type по умолчанию в URL-адресе.

Вы по-прежнему можете использовать эти значения в отдельных запросах:

POST /website/blog/_mget
{
   "docs" : [
      { "_id" : 2 },
      { "_type" : "pageviews", "_id" :   1 }
   ]
}

На самом деле, если все документы имеют одинаковые _index и _type, вы можете заменить полный массив документов простым массивом ids:

POST /website/blog/_mget
{
   "ids" : [ "2", "1" ]
}

Массовые операции при обновлении

Точно так же, как mget позволяет нам получать несколько документов одновременно, массовый API позволяет нам создавать, индексировать, обновлять или удалять несколько документов с помощью одного запроса. Это полезно для индексации потоков данных, таких как журнал действий, которые можно индексировать последовательно в пакетах из сотен или тысяч данных.

Тело массового запроса выглядит следующим образом, оно немного необычно:

{ action: { metadata }}\n
{ request body        }\n
{ action: { metadata }}\n
{ request body        }\n
...

Этот формат подобен потоку построчных документов JSON, соединенных символами "\n". Два важных момента, на которые стоит обратить внимание:

  • Каждая строка должна заканчиваться символом "\n", включая последнюю строку. Они отмечены как допустимые разделения для каждой строки.
  • Каждая строка данных не должна содержать неэкранированных символов новой строки, которые могут помешать синтаксическому анализу, а это означает, что JSON не может быть распечатан красиво.

Действие/метаданные строки определяют, над каким документом происходит действие документа (какое действие).

Действия должны быть одним из следующих:

поведение объяснять
create Создается, когда документ не существует.
index Создавайте новые документы или заменяйте существующие документы.
update Локально обновляемая документация.
delete Удалить документ.

Сказав так много, все могут немного запутаться, давайте перейдем непосредственно к коду

Метаданные, такие как _index, _type и _id документа, должны быть указаны при индексировании, создании, обновлении или удалении. Например, запрос на удаление выглядит так:

{ "delete": { "_index": "website", "_type": "blog", "_id": "123" }}

Потому что если его удалить, тела запроса не будет, вот и все

Создайте

{ "create":  { "_index": "website", "_type": "blog", "_id": "123" }}
{ "title":    "My first blog post" }

вернуть

{
    "took": 5,
    "errors": false,
    "items": [
        {
            "delete": {
                "_index": "website",
                "_type": "blog",
                "_id": "123",
                "_version": 1,
                "result": "not_found",
                "_shards": {
                    "total": 2,
                    "successful": 1,
                    "failed": 0
                },
                "_seq_no": 3,
                "_primary_term": 1,
                "status": 404
            }
        }
    ]
}

конец

На самом деле, сегодня я расскажу о его структуре и простейшей хрени. Вы можете просто сделать это снова. Завтра мы будем использовать Java для работы с добавлениями, удалениями и изменениями. Собственно, самый важный запрос сегодня подробно не рассматривается. есть о чем поговорить

ежедневные комплименты

Хорошо всем, вышеизложенное является полным содержанием этой статьи. Люди, которые могут видеть это здесь, всенастоящий порошок.

Творить нелегко. Ваша поддержка и признание — самая большая мотивация для моего творчества. Увидимся в следующей статье.

Six Meridians Excalibur | Text [Original] Если в этом блоге есть какие-то ошибки, прошу покритиковать и посоветовать, буду очень признателен!

Категории