Федеративний пошук: де ламається єдина видача
Федеративний пошук відповідає на один запит одразу з кількох систем: каталог, база заявок, файлове сховище, зовнішні сервіси. Запит вирушає в усі розрізнені джерела паралельно, а відповіді зводяться в єдину видачу.
Ламається це на асиметрії: час відповіді на запит задає найповільніше джерело, решта весь цей час чекає.
Поки один сегмент відповідає в рази довше за інших, користувач отримує або порожній екран, або половину результатів. Друге джерело збою — розсинхронізація даних: індекси оновлюються з різною частотою, і у видачі спливає документ, який у системі-джерелі вже змінено або видалено.
Третє — непорівнювані оцінки релевантності. Кожна система вважає важливість за своєю шкалою, тому під час злиття сильний результат одного джерела програє слабкому з іншого.
Дедуплікація руйнується слідом: одна сутність надходить із трьох місць з різними ідентифікаторами й тричі займає верх видачі.
Лікується це не «однією великою базою», а шаром федерації: бюджет часу на кожне джерело, часткова відповідь із явною позначкою про системи, що не відповіли, кеш гарячих запитів, розрив ланцюга до нестабільного вузла.
Поверх — нормалізація оцінок і єдине ранжування (Elasticsearch як пошукове ядро), щоб порядок результатів не залежав від того, хто встиг відповісти першим.
Підсумок: єдина видача перестає залежати від найслабшого учасника, а користувач бачить, що саме він отримав і чого не вистачає. Розбираємо, як це влаштовано і як закривається на практиці.
Що змінюється після впровадження єдиного шару доступу
Єдиний шар доступу стає між сценаріями користувача й розрізненими системами: базою документів, сховищем завдань, каталогом, зовнішніми довідниками. Запит вирушає в усі джерела паралельно, результати приводяться до спільної схеми й об’єднуються в одну ранжовану видачу.
Єдина точка входу замість ручного обходу систем
Раніше співробітник відкривав три-чотири системи й зводив результати вручну, а частина даних губилася через різні правила пошуку. Тепер запит іде в одну точку, а шар сам вирішує, які джерела опитати й як зіставити сутності.
Такі схеми ми збираємо на Elasticsearch з федеративним опитуванням і спільним словником синонімів — ранжування не залежить від місця зберігання документа.
Навантаження на джерела падає: повторювані обходи замінюються кешем гарячих запитів і точковими зверненнями за індексом. Пікові години більше не перетворюються на чергу.
Як вимірюється ефект: час відповіді та частка повних видач
Ефект рахуємо до впровадження й після, на одному наборі тестових запитів. Ключові метрики — час відповіді на 95-му процентилі та частка повних видач: запитів, де знайшлися всі релевантні документи з контрольного списку. Порівнюємо ручний обхід, пряме опитування джерел і роботу через шар.
На практиці час відповіді скорочується з кількох секунд до часток секунди, повнота видачі — з часткової до близької до повної, звернення до джерел падають у рази.
Окремо фіксуємо усунені класи відмов: розходження результатів між системами й відмова одного джерела, яка раніше ламала всю видачу.
Способи об’єднання джерел: таблиця порівняння
Об’єднати кілька джерел можна трьома способами: опитувати їх у момент запиту через пошуковий посередник, заздалегідь збирати вміст в єдиний індекс або кешувати результати й періодично підмішувати свіжі дані.
Вибір визначається не зручністю, а тим, скільки джерел, як часто змінюються дані й який час відповіді вважається прийнятним.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Об’єднання на льоту через пошуковий посередник | Джерела змінюються щодня, їх небагато, важлива свіжість видачі | Підсумковий час відповіді дорівнює найповільнішому джерелу, частина запитів не встигає у відведений час |
| Попереднє завантаження в спільний індекс | Масив стабільний, потрібне наскрізне ранжування й фільтри одразу за всіма джерелами | Переіндексація відстає від правок, зростає обсяг сховища, дорожчий повний перезбір |
| Кеш результатів | Багато повторюваних запитів, джерела погано тримають навантаження | Дані застарівають між оновленнями, потрібна логіка скидання за фактом зміни |
| Гібрид: індекс плюс дозапит на льоту | Великі стабільні масиви й невеликі швидкозмінні джерела | Дві гілки обробки: складніше налагодження, моніторинг і розбір причин порожньої видачі |
Коли об’єднання на льоту виправдане
Якщо правка в джерелі має з’являтися у видачі протягом хвилин, а джерело віддає структуровану відповідь, посередник запитує його напряму й не зберігає копію.
Розплата — затримка визначається найповільнішим учасником, тому заздалегідь задають граничний час очікування й правило часткової відповіді: якщо одне джерело не встигло, видача збирається з решти замість помилки. Кеш результатів тут працює з коротким строком життя й скидається за ознакою зміни даних.
Коли потрібне попереднє завантаження
Для великих масивів, де потрібні наскрізне ранжування й спільні фільтри, вміст переносять в єдиний індекс за розкладом. Час відповіді стає передбачуваним і не залежить від доступності джерел, але з’являється розрив між правкою та її видимістю.
Його скорочують частотою оновлення й точковою переіндексацією змінених документів замість повного перезбору корпусу.
Етапи впровадження федеративного пошуку
Федеративний пошук починається не з коду, а з інвентаризації джерел. Поки неясно, які системи закривають основну частку запитів і як влаштовані права, будь-яка схема залишається гіпотезою. Нижче — порядок робіт, який ми проходимо на кожному проєкті.
- Аудит джерел. Інвентаризація систем: обсяг, частота оновлення, формати полів, моделі доступу. На виході — матриця: що кожне джерело віддає, з якою затримкою і за якими ключами зіставляється з рештою.
- Схема контуру. Вирішуємо, де живе об’єднаний індекс, що оновлюється потоком, а що опитується на льоту, як розділяються спільні й закриті дані. Схему узгоджуємо з власниками систем заздалегідь.
- Маршрутизація запитів і права. Правила вирішують, у яку підмножину джерел вирушає запит; фільтри доступу застосовуються під час звернення до кожного джерела, а не після склейки видачі — так зникає витік через агрегований результат.
- Перевірка якості видачі. Еталонний набір запитів, розмітка очікуваних відповідей, замір повноти й точності за кожним джерелом — детальніше нижче.
- Передача в експлуатацію. Регламенти оновлення, моніторинг недоступності джерел, інструкції для підтримки й точки підключення нових систем без перезбирання контуру.
Як виглядає перевірка якості видачі
Ми фіксуємо еталонні запити — типові, рідкісні й навмисно спірні — і розмічаємо, що вважається правильною відповіддю. Прогін дає три числа: частка запитів із повною відповіддю, частка випадків з коректним відсіканням за правами й час відгуку на важкому зрізі.
Розходження розбираємо до причини — правило маршрутизації, поле метаданих або затримка оновлення. Інакше якість видачі деградує тихо.
Конфігурації, схеми й регламенти, які ви отримуєте
Після здачі контуру у вашої команди залишаються не презентації, а робочі артефакти: конфігурації, схеми й регламенти, за якими систему можна розвивати й підтримувати без нас.
Кожен документ прив’язаний до конкретного вузла контуру — за ним видно, що змінювати при підключенні нового джерела або зміні правил доступу.
Схеми потоків даних і карта джерел
- Карта джерел: тип підключення, власник даних, частота оновлення, обмеження на вивантаження.
- Схема проходження запиту — від точки входу до злиття результатів, із місцем відкидання дублів.
- Схема індексації: що потрапляє в індекс, як часто перезбирається, де зберігається стан.
- Конфігурація контуру: профілі пошуку, ваги полів, пороги збігу, тайм-аути на джерело.
- Схема деградації: яке джерело відключається першим і що бачить користувач за недоступності.
Політики доступу, ролі й журнали
- Рольова модель: хто бачить які джерела й поля, як успадковуються права.
- Правила маскування чутливих полів на видачі та у вивантаженнях.
- Журнали запитів і дій адміністраторів: склад записів, строк зберігання, хто їх читає.
- Регламент експлуатації: перезбирання індексів, підключення нового джерела, планові роботи, реакція на збій.
- Порядок надання й перегляду доступів, включно зі зміною ролі або звільненням співробітника.
Комплект лежить у вашому репозиторії та оновлюється разом з контуром — за наступного релізу логіку не доводиться відновлювати з пам’яті.
Кейс: об’єднання шести розрізнених систем
До впровадження шість джерел — облікова система, сховище документів, поштовий архів, база заявок, портал регламентів і галузевий довідник — жили зі своїм пошуком кожне.
Співробітник повторював запит чотири-шість разів і вручну звіряв видачу: час відгуку на такий складений пошук вимірювався хвилинами, а частка успішних запитів з першої спроби трималася близько 40% — частина документів у вибірку просто не потрапляла.
Ми зібрали федеративний шар поверх індексів Elasticsearch: єдина точка входу, розбір запиту на сутності, паралельне опитування джерел з обмеженням часу й об’єднання видачі за релевантністю.
Права не обходимо — кожен результат фільтрується за доступами користувача з вихідної системи, тому в спільній видачі немає документів, які йому не належать.
Що змінилося на боці самих джерел
Федерація не спрацювала б, якби джерела залишилися як є. В обліковій системі й базі заявок з’явилися журнали змін, і індекс оновлюється інкрементально, а не нічним перезбиранням — розходження між системою й видачею скоротилося з доби до хвилин.
У сховищі документів запровадили єдині атрибути: тип, підрозділ, строк дії. У довідник — словник синонімів і галузевих скорочень, щоб «договір поставки» і «поставка» вели до одного набору.
Підсумок: час відгуку 1–2 секунди замість хвилин, частка успішних запитів — 89% проти 40%, у 84% випадків достатньо одного формулювання. Потік питань «де це лежить» перестав бути окремим напрямом роботи підтримки.
«Раніше кожна спроба звести бази впиралася в права доступу. Тут шар працює поверх систем, нічого не ламаючи, і відкат до попередньої схеми пошуку залишається можливим», — відповідальний за напрямок.
Що робити, якщо джерела не можна зупиняти?
Працюючу систему ніхто не виводить з експлуатації заради нового пошуку, тому підключення будується поверх наявних сервісів у режимі лише читання. Наш контур звертається до джерел так само, як це робить будь-який їхній штатний споживач, і не претендує на запис куди-небудь.
Права доступу надаються на читання: окремий обліковий запис, репліка або регулярне вивантаження — на вибір власника джерела. Навіть у разі помилки в конфігурації ми фізично не можемо змінити дані в системі-джерелі, тому ризик для неї зводиться до читання, а не до псування вмісту.
Контур розширюється поетапно. Спочатку підключається одне джерело — на ньому перевіряються повнота видачі, якість нормалізації й поведінка під навантаженням.
Наступний додається лише після того, як попередній дає передбачуваний результат, і кожен крок відкочується окремо, не зачіпаючи вже працюючі підключення.
Сумісність вирішується шаром нормалізації: різні схеми даних, формати полів і довідники приводяться до спільного вигляду, а власником вмісту залишається джерело. Будь-яке джерело можна будь-якої миті виключити з контуру — решта підключень продовжать працювати як раніше.
Читання розподіляється так, щоб не конкурувати з робочими запитами: обхід іде порціями, у вікна низького навантаження, з обмеженням паралелізму.
Простою не виникає ні на старті, ні під час додавання нових джерел — пошук розширюється у міру готовності, а сервіси продовжують працювати у звичайному режимі.
Технічні сумніви щодо об’єднання джерел
П’ять питань, які найчастіше звучать на етапі оцінки. Ми відповідаємо на них до старту: від цих рішень залежить поведінка системи в експлуатації, а не лише під час демонстрації.
Як розмежовуються права, якщо моделі ролей різні?
Права перевіряє саме джерело: запит вирушає з делегуванням, а не фільтрацією готової видачі. У спільну модель зводимо лише однакові ролі, решта — локальна політика.
Що станеться, якщо одне джерело недоступне?
Видача деградує частково: решта відповідають, а у відповіді видно, які дані не потрапили. Запит повторюється з наростаючою паузою, за стійкої відмови джерело тимчасово виводиться з опитування.
Скільки роботи додасть нове джерело?
Підключення — це конектор і опис схеми: поля пошуку, сутності, застосовні права. Ядро не змінюється, але потрібен зворотний мапінг до першоджерела, щоб користувач потрапляв на оригінал.
Як об’єднуються різні формати даних?
Приводимо до єдиного контракту: текст, метадані, права, посилання. Пошук іде за нормалізованим виглядом, а точкою істини залишається оригінал у джерелі — у разі розходження виграє він.
Чи не ляже пошук навантаженням на джерела?
Звернення йдуть лише на читання, з лімітом паралельних запитів і чергою за пріоритетами. Інтерактивні запити обганяють фонові обходи, повторювані знімає кеш.
Обговоримо ваше завдання об’єднання джерел
На першій розмові нам важливіше зрозуміти, як влаштовані ваші джерела, ніж показати готове рішення. Достатньо 30–40 хвилин з інженером, який відповідає за дані, — цього вистачає, щоб окреслити межі контуру й повернутися з оцінкою строків і планом робіт.
- Які системи вже є — каталоги, бази, файлові сховища, зовнішні сервіси — і що з цього обов’язково має потрапляти в спільну видачу.
- Як влаштовані доступи: чиї права успадковуються в пошуку, де потрібне маскування полів, чи є вимоги до журналу запитів.
- За якою ознакою зіставляються документи з різних джерел: єдиний ідентифікатор, регламент оновлення, правила злиття дублів.
- Що вважаємо якістю результату — частку релевантних влучань у топі, повноту видачі, припустимий час відповіді на запит.
- Пілотний контур: які два-три джерела підключаємо першими, на якому зрізі даних перевіряємо і за якою метрикою приймаємо результат.
- План впровадження: черговість підключення, точки розширення під нові джерела, хто з вашого боку приймає етапи.
- Супровід після запуску — моніторинг доступності джерел, оновлення схем, відкат у разі просідання якості.
Після розмови надсилаємо склад пілотного контуру, план впровадження й оцінку строків за етапами. Опишіть завдання у двох-трьох абзацах — повернемося з оцінкою й пропозицією щодо архітектури.
