Elasticsearch Vocabulary: 30 Terms for Search Engineers (англійською)

Elasticsearch забезпечує пошук у масштабі — від каталогів продуктів електронної комерції до аналітичних конвеєрів журналів. Якщо ви працюєте з ним щодня, ви вже знаєте команди. Але коли ви приєднуєтесь до англомовної команди, звичайні телефонні розмови і перегляд коду вводять шар жаргону, який може вас сповільнити. Цей посібник містить 30 термінів, які ви почуєте найчастіше, з визначеннями простою англійською мовою і діалогом розробника, щоб ви могли впевнено використовувати їх у розмові.

---

Основні терміни

** Індекс ** — У Elasticsearch індекс є збіркою пов’ язаних документів, приблизно аналогічним базі даних у реляційній системі. Ви зберігаєте, шукаєте і керуєте даними на рівні індексу.

«Ми розділяємо індекс журналів за місяцями, щоб гарячий рівень не заповнювався так швидко»

«Перед тим, як запустити цей запит, переконайтеся, що ви націлюєтеся на правильний індекс — є спадковий, який все ще сидить там з минулого року»

** Документ ** — документ є базовим об’ єктом даних у Elasticsearch, збереженим у форматі JSON. Кожен документ належить до індексу і має унікальний _id.

Структура документа змінилася в останньому спринті — поле user_id тепер вкладено під metadata

«Ми індексуємо близько двох мільйонів документів на день, тому ефективність картографування дійсно важлива»

Shard — Elasticsearch ділить індекс на менші частини, які називаються фрагментами. Кожен шард є самостійним індексом Lucene. Шардинг дозволяє Elasticsearch розповсюджувати дані по декількох вузлах і паралельно виконувати запити.

«Ми пере-шардували цей індекс на початку — двадцять шардів на п’ять гігабайтів це перебільшення»

“Запит повільний, тому що він послідовно вбиває всіх дванадцять осколків. Нам потрібно подивитися на маршрутизацію»

** Репліка осколка ** — осколок-репліка є точною копією первинного осколка. Репліки виконують дві функції: забезпечують високу доступність (якщо вузол не працює, репліки переймають його функції) і збільшують пропускну здатність читання (запити пошуку можна обробляти з будь- якої копії).

«Збільшити кількість реплік до двох перед тим, як ми перейдемо на живий — я не хочу, щоб один вузол зламався, зупиняючи пошук»

«Репліка шардів не допомагає з швидкістю індексування; вони тільки допомагають з читанням і стійкістю до помилок»

** Призначення** — Призначення визначає схему для документів у індексі: назви полів, типи даних (keyword, text, date, integer тощо), а також те, як слід аналізувати кожне поле. Уявіть, що це схема з типами, яку Elasticsearch використовує для серіалізації і запиту ваших даних.

«Підрахунок для цього поля є text, але нам потрібні точні збіги — змініть його на keyword»

“Ви не можете змінити існуюче поле на місці. Вам потрібно буде реіндексувати»

** Динамічне відображення проти явного відображення ** — За допомогою динамічного відображення Elasticsearch автоматично визначає і створює типи полів під час першого індексування документа. За допомогою явного призначення ви визначаєте схему самостійно перед індексуванням. Динамічне відображення зручне для створення прототипів, але може створювати несподіванки під час виробництва; явне відображення надає вам можливість точного керування поведінкою полів.

“Ми вимкнули динамічне відображення для цього індексу. У нас було занадто багато випадкових полів float, створених з рядкових даних»

«Ясне відображення є трохи більшою роботою, але це рятує вас від дивних проблем з релевантністю пізніше»

---

Індексування та внутрішнє зберігання

** Інверсійний індекс ** — інверсійний індекс є основною структурою даних, яка прискорює повнотекстовий пошук. Замість зберігання документів і сканування їх, Elasticsearch створює пошукову таблицю з кожного унікального терміна до списку документів, які його містять. Якщо ви шукатимете « optimise », Elasticsearch шукає цей термін у зворотному індексі і негайно отримує відповідні ідентифікатори документів.

«Причиною того, що пошук за ключовими словами такий швидкий, є інвертований індекс — це не сканування рядок за рядком, як це робила б база даних»

«Стоп-слова видаляються під час аналізу, щоб вони не роздули інвертований індекс без потреби»

**_ source field ** — Поле _source зберігає початковий JSON- документ, так як він був індексований. Коли ви отримуєте документ, Elasticsearch типово повертає _source. Ви можете вимкнути або відфільтрувати цю функцію, щоб заощадити місце у пам’ яті, але у такому випадку буде обмежено кількість даних, які можна отримати без повторного індексування.

«Ми вимикаємо _source на індексі метрики, щоб зменшити обсяг зберігання вдвічі, але тепер ми не можемо використовувати оновлення за запитом»

Ви можете використовувати _source фільтрування в своєму запиті, щоб повернути тільки ті поля, які вам дійсно потрібні

** Інтервал оновлення ** — Elasticsearch записує нові документи до буфера пам’ яті і періодично робить їх видимими для пошуку за допомогою процесу, який називається оновленням. Інтервал оновлення (типове значення: одна секунда) визначає, як часто цей процес буде виконуватися. Для пошуку з високою пропускною здатністю збільшення інтервалу зменшує витрати; для пошуку у режимі майже реального часу зберігайте його на низькому рівні.

«Встановити інтервал оновлення до тридцяти секунд під час масового завантаження, а потім знизити його до однієї секунди, коли ви закінчите»

«Дата з’являється в індексі, але поки що не піддається пошуку — вона все ще чекає на оновлення»

** Керування циклом життя індексу (ILM) ** — ILM є вбудованим рушієм політики Elasticsearch для керування індексами протягом часу. Ви визначаєте фази — гарячу, теплу, холодну, заморожену, вилучення — і Elasticsearch автоматично пересуває індекси між ними, зменшуючи об’ єми, примушуючи об’ єднання сегментів або вилучаючи старі дані відповідно до ваших правил.

«У нас є політика ILM, яка перевертає індекс, коли він досягає п’ятдесяти гігабайтів або тридцяти днів, в залежності від того, що настає першим»

“Без ILM, комусь потрібно вручну очищати старі індекси. Це те, що забувають, поки диск не заповниться о 3 годині ранку»

---

Запитання і відповіді

** Оцінка відповідності (BM25) ** — Під час виконання повнотекстового запиту Elasticsearch ранжує результати за оцінкою відповідності. Типовим алгоритмом оцінювання є BM25 (Найкраще збігнення 25), який враховує частоту виразів, обернену частоту документів і довжину полів. Вищий бал означає ближчі матчі.

«Відмінні результати виглядають неправильно — BM25 підвищує короткі документи занадто сильно через нормалізацію довжини поля»

“Ви можете пояснити запит, щоб побачити, як BM25 обчислив оцінку кожного документа. Дуже корисно для зневадження проблем з рейтингом»

Query DSL — Query DSL (Domain-Specific Language) від Elasticsearch є мовою, заснованою на JSON для виразів запитів. Замість написання SQL, ви створюєте вкладені об’ єкти JSON, які описують те, що ви бажаєте знайти, і як оцінити результати.

«Query DSL виглядає розгорнутим на початку, але як тільки ви зрозумієте лист і складний шаблон запиту, він клацає»

Не будуйте Query DSL рядки за допомогою з’єднання — використовуйте клієнтську бібліотеку, яка правильно конструює JSON

** term query ** — запит term відповідає документам, які містять точне, не проаналізоване значення у полі. Використовуйте його для полів keyword, ідентифікаторів, станів і інших структурованих даних, для яких вам потрібні точні відповідності.

«Використовуйте запит term для поля status, а не match — ви хочете точну рівність рядків, а не повнотекстовий аналіз»

** match query ** — Запит match виконує рядок пошуку через аналізатор поля перед порівнянням. Це робить його підходящим для полів повного тексту, до яких ви бажаєте застосувати символізацію, вилучення кореня і вилучення слів- зупинок.

«Запит match пробачає — він аналізує вхідні дані таким же чином, яким було індексовано поле, тому ‘running’ відповідає ‘run’.”

** boolean query ** — запит bool надає вам змогу об’ єднати декілька запитів за допомогою логічних клаузул: must (обов’ язковий, впливає на оцінку), should (необов’ язковий, підвищує оцінку), must_not (виключення, не впливає на оцінку) і filter (обов’ язковий, не впливає на оцінку).

«Загорніть ваші фільтри в клаузулу filter запиту bool — вони кешуються і не впливають на оцінку, тому продуктивність набагато краща»

«Клаузула should це те, що дає вам те «приємне» підвищення без важкого вимоги терміну»

** range query ** — запит range відповідає документам, у яких значення поля знаходиться у межах вказаних меж. Застосування для дат, цін і числових показників.

«Використовуйте запит range на полі created_at для отримання результатів за останні тридцять днів»

---

Аналіз і текстова обробка

** Аналітик ** — Аналітик — це конвеєр, який Elasticsearch використовує для обробки тексту під час індексування і пошуку. Зазвичай, він складається з символьного фільтра (необов’ язковий), токенізатора і одного або декількох токенних фільтрів. Вибір аналізатора визначає, що буде в кінцевому підсумку вказано в інверсному індексі.

“Типовий аналізатор standard розпізнає малі літери і символізує пробіли та пунктуацію. Це добре для більшості англійського контенту»

«Ми використовуємо аналізатор english для вмісту блогу — він автоматично обробляє слова stem і stop.»

** Tokenizer ** — Tokenizer — це компонент у межах аналізатора, який розбиває рядок на окремі токени (терміни). standard токенізатор розділяє на пробіли і пунктуацію; whitespace токенізатор розділяє тільки на пробіли; ngram токенізатори виробляють фрагменти рівня символів для часткового збігу.

«Ми перейшли на ngram токенізатор для пошуку-як-ви-вводите функції, так що часткові рядки збігаються правильно.»

«Токенізатор є лише однією частиною ланцюга аналізу — фільтри працюють після того, як змінюються токени»

** Filter (фільтр токенів) ** — фільтр токенів змінює, вилучає або додає токен після запуску токена. Поширені фільтри включають lowercase, stop (вилучає слова-зупинки), stemmer (зменшує слова до їх кореневої форми), і synonym.

Додати synonym фільтр, щоб ‘k8s’ відповідав ‘kubernetes’ в індексі

“Фільтр stop вилучає ‘not’ з запиту, що повністю перевертає його значення. Вимкніть його для цього поля»

---

Aggregations

** Агрегація ** — агрегації надають вам змогу обчислювати аналітичні дані щодо результатів вашого пошуку. Замість простого отримання відповідних документів, ви можете підрахувати їх, додати значення, знайти середні значення, побудувати гістограми тощо. Вони визначені в розділі aggs запиту.

«Ми використовуємо агрегації для живлення граненої навігації на сторінці списку продуктів — категорії, діапазони цін, фільтри брендів»

Якщо вам потрібен тільки результат агрегації, а не сирі пошуки, встановіть size: 0, щоб уникнути надмірного завантаження документів

** Агрегування контейнерів ** — агрегування контейнерів групує документи у контейнери за певним критерієм — значенням поля, діапазоном дат, географічною межею. Кожне відділення може містити додаткові підагрегації.

«terms агрегація є bucket агрегацією — вона створює один bucket на унікальний значення поля.»

«Вкладіть метричну агрегацію всередині кожного відра, щоб отримати, скажімо, середню вартість замовлення за країною»

** Метрична агрегація ** — Метрична агрегація обчислює одне числове значення (або набір значень) з документів у контейнері: sum, avg, min, max, cardinality, percentiles і т. д.

“Агрегація cardinality дає вам приблизний різний рахунок. Це не точно, але це достатньо швидко для датчиків»

---

Як використовувати їх у розмові

** Сценарій 1 — Пояснення проблеми продуктивності в станді-ап: ** «Запити панелі управління повільні, тому що ми запускаємо terms агрегування по всьому індексу без фільтра. Я додам фільтр діапазону дат в клаузулі bool запиту filter, щоб Elasticsearch міг використовувати індекс теплого рівня, керований ILM, замість сканування всього»

** Сценарій 2 — Перегляд зміни у відповідності у запиті на завантаження: ** “Це поле має бути keyword, а не text. Ми тільки завжди робимо точні збіги на ній — використання text означає, що Elasticsearch проаналізує її і створить непотрібні записи в інверсному індексі. Також, динамічне відображення все ще включено для цього індексу; давайте визначимо явне відображення, щоб уникнути сюрпризів»

** Сценарій 3 — Зневадження рейтингу відповідності з колегою: ** “БМ25 оглядають короткі документи. Чи можете ви запустити API _explain на одному з цих результатів, щоб ми могли побачити, як було обчислено оцінку відповідності? Я підозрюю, що нормалізація довжини поля надмірно карає довші, більш повні записи»

** Сценарій 4 — Обговорення ILM під час виклику планування обсягу: ** “Зараз ми зберігаємо все на гарячому рівні на неопределенный срок, что и является причиной роста стоимости хранения. Якщо ми встановимо політику ILM для пересування індексів, які старші за чотирнадцять днів, щоб розігріти і вилучити після дев’яноста, ми можемо зменшити відбиток SSD на шістдесят відсотків. “

---

Краткий справочник

Term	What it means
Index	A named collection of documents; the top-level data container
Shard	A horizontal slice of an index; enables distribution and parallelism
Replica shard	A copy of a primary shard for redundancy and read throughput
Mapping	The schema defining field names, types, and analysis settings
Inverted index	The internal lookup structure mapping terms to document IDs
BM25	The default relevance scoring algorithm for full-text queries
bool query	A compound query combining must, should, filter, must_not clauses
Analyser	The pipeline (tokenizer + filters) that processes text for indexing and search
Bucket aggregation	Groups documents into named buckets (e.g. by category, date range)
ILM	Policy engine that automates index lifecycle phases (hot → warm → delete)

Завдання з цим словником допоможе вам не лише точніше спілкуватися англійською мовою, але і покращить ваше розуміння самої Elasticsearch. Кожен термін відображає рішення про дизайн, і розуміння мови є першим кроком до чіткого обґрунтування архітектури пошуку.