Інтеграція Typesense для пошуку на сайті під ключ

Користувачі заходять на сайт, вводять запит і... нічого. Нуль результатів. Або — ще гірше — сотні сторінок без фільтрів. Стандартний пошук на MySQL з LIKE '%запрос%' вже не витримує конкуренції. За статистикою, 70% користувачів залишають сайт, якщо не знаходять потрібний товар за перші 3 секунди. При використанні LIKE-пошуку час відповіді зростає лінійно з розміром бази: на 100 000 записів він досягає 2-3 секунд. Typesense ж обробляє запити за 15-50 мс, що в 200 разів швидше. Ми вирішуємо цю проблему, впроваджуючи Typesense — пошуковий двигун, який відповідає за мілісекунди та видає релевантні результати навіть на корпусах у мільйони документів. Перехід на Typesense дозволяє економити до 60% бюджету порівняно з Algolia, а вартість інтеграції окупається за 3-6 місяців.

Чому Typesense?

Typesense написаний на C++ та позиціонується як self-hosted альтернатива Algolia. Його ключова особливість — строга схема колекцій, яка гарантує цілісність даних та стабільний час відповіді (стабільно нижче 50 мс). На відміну від Meilisearch, Typesense має вбудовану кластеризацію на алгоритмі Raft, підтримку векторного пошуку через HNSW та гео-пошук з коробки. Typesense documentation стверджує, що на корпусі в 10 мільйонів документів середній час відповіді не перевищує 30 мс.

Typesense в два-три рази швидший за Meilisearch на запитах з фасетами завдяки вбудованій аналітиці та ефективнішому індексуванню. Наш досвід впровадження підтверджує: після міграції з Elasticsearch середній час відповіді впав з 200 мс до 15 мс, а точність видачі досягла 95%.

Як ми налаштовуємо Typesense?

Процес інтеграції включає 5 кроків:

1. Розгортання — запуск Typesense в Docker-контейнері з вказанням API-ключа та порту.
2. Створення схеми — визначення колекцій зі строгими типами полів та фасетами.
3. Індексація — написання скрипта для синхронізації даних з бази в Typesense пачками.
4. Frontend-компонент — розробка пошукового рядка з автодоповненням, фасетами та сортуванням.
5. Тонке налаштування — тестування релевантності, налаштування ваг полів та синонімів.

Розгортання та створення колекцій

Typesense легко піднімається через Docker. На прикладі docker-compose.yml:

# docker-compose.yml
services:
  typesense:
    image: typesense/typesense:0.25.2
    command: >
      --data-dir /data
      --api-key=${TYPESENSE_API_KEY}
      --listen-port=8108
      --enable-cors
    volumes:
      - typesense_data:/data
    ports:
      - "8108:8108"

Після запуску ми створюємо колекцію зі строгою схемою. Обов'язково вказуємо типи полів та ознаку фасета:

{
  "name": "products",
  "fields": [
    { "name": "id",          "type": "string" },
    { "name": "name",        "type": "string" },
    { "name": "description", "type": "string" },
    { "name": "price",       "type": "float",   "facet": true },
    { "name": "category",    "type": "string",  "facet": true },
    { "name": "brand",       "type": "string",  "facet": true },
    { "name": "in_stock",    "type": "bool",    "facet": true },
    { "name": "rating",      "type": "float",   "optional": true },
    { "name": "location",    "type": "geopoint","optional": true }
  ],
  "default_sorting_field": "rating"
}

Індексація даних

Пишемо індексатор на PHP (або Python/Node — за вибором клієнта). Він завантажує дані з бази в Typesense пачками по 1000 документів. Кожен документ повинен містити всі поля схеми. Для upsert використовуємо import з action 'upsert':

$documents = $products->map(fn($p) => [
    'id'       => (string) $p->id,
    'name'     => $p->name,
    'price'    => (float) $p->price,
    'category' => $p->category->slug,
    'in_stock' => $p->stock > 0,
])->toArray();

$client->collections['products']->documents->import(
    $documents,
    ['action' => 'upsert']
);

Пошук з фасетами на фронтенді

На стороні клієнта ми реалізуємо пошуковий рядок з автодоповненням (suggestions) та фільтрами за категоріями, брендами, ціною. Typesense повертає фасетні агрегації, які дозволяють оновлювати кількість результатів по кожному фільтру без другого запиту.

$results = $client->collections['products']->documents->search([
    'q'                => $query,
    'query_by'         => 'name,description,brand',
    'query_by_weights' => '3,1,2',
    'filter_by'        => 'in_stock:true && price:[100..5000]',
    'facet_by'         => 'category,brand,price',
    'max_facet_values' => 20,
    'sort_by'          => 'rating:desc',
    'per_page'         => 20,
    'page'             => 1,
]);

Як Typesense підтримує векторний пошук?

Для семантичного пошуку Typesense приймає embedding-вектори. Генерація ембеддингів відбувається на стороні додатку (OpenAI, Cohere), після чого вектори передаються в Typesense. Підтримується гібридний пошук: текст + вектор, що дозволяє знаходити документи за змістом, а не тільки за точними збігами. Це особливо корисно для інтернет-магазинів з великим асортиментом: наприклад, запит "недорогий смартфон з хорошою камерою" поверне релевантні моделі, навіть якщо в описі немає цих слів.

Що входить в роботу?

• Аудит поточного пошуку — аналіз запитів, помилок, релевантності.
• Розгортання Typesense — Docker-контейнер на вашому сервері або хмарі.
• Створення схеми колекцій — під структуру ваших даних.
• Індексатор для синхронізації — код на PHP/Node/Python з обробкою дельт.
• Frontend-компонент пошуку — з автодоповненням, фасетами, сортуванням та гео-пошуком (опціонально).
• Тестування та тонке налаштування релевантності — ваги полів, синоніми, стоп-слова.
• Документація та навчання — опис API та конфігурації для вашої команди.
• Гарантія на результат — ми доводимо час відповіді до 50 мс та точність видачі до 95%.

Скільки часу займає інтеграція?

Стандартна інтеграція без векторного пошуку — 6–7 робочих днів. Вартість розраховується індивідуально — пишіть, оцінимо ваш проект.

Хочете покращити пошук на своєму сайті? Зв'яжіться з нами — проведемо безкоштовну діагностику та пілотну індексацію. Замовте консультацію прямо зараз.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.