AACsearch
Биллинг

Единицы потребления

Что считается search unit, ingest unit, AI unit, синхронизацией коннектора и единицей хранения — с примерами и правилами эмиссии.

AACsearch метерит шесть сущностей. Пять идут в квоту плана (search units, индексируемые документы, синхронизации, хранилище, места). Шестая — AI — идёт по отдельному предоплаченному кошельку. Именно их смешение чаще всего сбивает с толку; эта страница — справочник по каждой единице.

Панель биллинга и использования с текущим тарифом, потреблёнными единицами, балансом кошелька и перерасходом

Search units

Search unit — главный метер плана. Один search unit = один поисковый запрос ИЛИ одна запись документа.

ДействиеЮнитовЭмитируется как
POST /search (любые фильтры, сортировка, пагинация)1SearchUsageEvent { type: "search" }
POST /multi-search с N запросамиNПо одному SearchUsageEvent на запрос
PUT /indexes/{id}/documents (одиночный upsert)1SearchUsageEvent { type: "ingest" }
POST /indexes/{id}/documents:batch с N документамиNПо одному на каждую успешно обработанную строку
DELETE /indexes/{id}/documents/{external_id}1SearchUsageEvent { type: "ingest_delete" }
DELETE …documents:byFilter, под фильтр M документовMПо одному на каждый сматченный документ
POST /indexes/{id}/sync (полный реиндекс)MПо одному на каждый ре-эмитированный документ
Suggest / autocomplete1SearchUsageEvent { type: "suggest" }
Только-агрегатный запрос (per_page: 0)1Считается как поиск

Поиск с нулевыми хитами всё равно тратит юнит. Неудачный поиск (плохой запрос, 4xx) не тратит. 429 и 5xx — тоже не тратят.

Почему «поиск ИЛИ ингест»?

У обоих похожий профиль нагрузки на Typesense и инфраструктуру. Единая единица упрощает рассуждение о лимитах, разрешает свободно менять ingest на query и избавляет от ловушки «мы спалили квоту поиска большим реиндексом» — оба видны в одном месте.

Индексируемые документы (квота хранения)

Помимо per-action юнитов, план каплит установившееся число документов во всех индексах. Проверяется на ингесте, не per-запрос.

ПланПотолок документов
Free1 000
Starter10 000
Pro100 000
Business1 000 000
EnterpriseCustom

При достижении потолка новые upsert-ы возвращают quota_exceeded. Чтение работает. Освободить — удалить документы или обновить план.

Размер документа: счётчик считает по штучно, но очень большие документы (>1 МБ) упрутся в лимит размера в Typesense. Цельтесь в <64 КБ на документ.

AI units (кошелёк, отдельно от плана)

AI-расход не входит в search units. Он метерится по отдельному предоплаченному кошельку в wallet-ledger.ts, в микро-USD или копейках.

ДействиеПримерная стоимость (зависит от модели)Эмитируется как
Knowledge-запрос (RAG с ретривом)Embedding-токены + LLM-токеныWalletLedgerEntry { type: "knowledge" }
Генерация embeddings (/embeddings)Embedding-токены × ставка моделиWalletLedgerEntry { type: "embedding" }
AI rerank (на запросе search)Embedding-токены × ставка rerank-моделиWalletLedgerEntry { type: "rerank" }
Суммаризация документаLLM-токены × ставка суммаризацииWalletLedgerEntry { type: "summarize" }
AI-чат (история разговора)Кумулятивные LLM-токены на ходWalletLedgerEntry { type: "chat" }

Каждый AI-вызов пишет запись в реестр с точной суммой списания (BigInt микро-USD). Если кошелёк пуст или ниже порога — вызов падает с wallet_balance_insufficient, поиск/ингест не затрагиваются.

См. Кошелёк и AI-кредиты для пополнений, автозачисления и лимитов расходов.

Синхронизации коннекторов

Синхронизация коннектора — один full или delta-ран коннекторного токена (ss_connector_*). Метерится за прогон, не за документы внутри.

Тип прогонаЮнитов
Heartbeat (POST /heartbeat)0 — heartbeat-ы бесплатны
Delta-синк (инкремент)1 sync-юнит + N search units (по одному на документ)
Full-синк (реиндекс)1 sync-юнит + N search units (по одному на документ)

План капит общее число синков в месяц (300 / 3 000 / 30 000 по платным ярусам). У частых коннекторов (например, пятиминутный поллинг PrestaShop) лимит синков может стать ограничивающим раньше объёма search units.

Места

Место — участник с любой ролью (owner, admin, member, viewer). Капы плана:

ПланМеста
Free3
Starter10
Pro25
Business100
EnterpriseПо дог.

Удалённые участники освобождают место сразу. Pending-инвайты не занимают мест — только принятые.

См. Участники и роли для модели ролей и массового приглашения.

Retention аналитики

Селектор периода в Аналитике гейтится планом:

План24h7d30d90d365d
Free
Starter
Pro
Business
Enterprise

Retention — на сырых событиях. Агрегированные дашборды (топ запросов, KPI) считаются на чтении и не имеют отдельного retention.

Примеры

Малый магазин

  • 5 000 SKU в одном индексе → 5 000 документов (Starter cap 10k — помещается).
  • 30 000 посетителей/мес × 4 запроса = 120 000 search units (превышает Starter 100k — переходим на Pro).
  • Ежедневный инвентари-синк = 30 синков/мес (далеко от любого капа).
  • AI-функции не используются → кошелёк не трогается.

План: Pro. Кошелёк: ноль.

База знаний с AI Q&A

  • 2 000 статей.
  • 50 000 поисков/мес (намного ниже Pro 1M).
  • 5 000 Knowledge-запросов/мес, ~1 500 токенов на запрос → ~7,5M токенов.
  • При смешанной ставке ~$0,005 / 1k токенов → ~$37,50/мес из кошелька.

План: Pro. Кошелёк: $40/мес, автозачисление при пороге $5.

Маркетплейс

  • 8 тенантов, scoped-токены для изоляции.
  • 80 000 документов в одном общем индексе.
  • 2 000 000 поисков/мес.

План: Pro (scoped-токены тут открываются). Кошелёк: ноль, если AI rerank не нужен.

Где сырой лог событий

  • /[orgSlug]/overview — KPI-плитка с агрегатами.
  • /[orgSlug]/analytics — пер-дневной чарт событий поиска и ингеста.
  • /admin/wallet (только админ) — сырые записи реестра кошелька.
  • v1 REST GET /api/v1/usage/events — программный экспорт с пагинацией.

Связанные страницы

On this page