"Структура данных"

Введение — зачем нужна правильная структура данных

Структура данных — это каркас, на котором держится вся бизнес-логика сервиса по прогону и индексации сайтов. Для раздела Услуги в руководстве commercial-services она отвечает за хранение заказов, управление кампаниями, очередями индексации, отчетами и интеграциями с провайдерами. Правильно спроектированная модель позволяет:

• уменьшить время отклика API на 30–70%;
• сократить расходы на хранение логов на 20–50% за счет агрегации и архивирования;
• повысить точность отчетности (SLA) до уровня 98–99% при корректной валидации входящих данных.

Далее — конкретика: ключевые сущности, примеры схем, числовые рекомендации и лучшие практики с прицелом на commercial-services и раздел Услуги по заказу прогонов и индексации PWA & SEO агенство.

Ключевые сущности в сервисе прогонов и индексации

Ниже — набор основных сущностей и минимальный набор полей, необходимых для работоспособной платформы:

1. Campaign (кампания)

• campaign_id (UUID)
• name (string)
• client_id (UUID)
• created_at (timestamp)
• status (enum: draft, running, paused, completed)
• budget (decimal)

2. Run / Job (прогон)

• run_id (UUID)
• campaign_id (UUID)
• provider_id (UUID)
• run_type (enum: crawl, push, rss, social)
• urls_count (int)
• started_at, finished_at (timestamps)
• status (enum: queued, processing, success, failed)
• cost_cents (int)

3. URL (задача)

• url_id (UUID)
• run_id (UUID)
• url (string)
• anchor_text (string)
• anchor_type (enum: sitewide, contextual, footer)
• priority (int, 1..10)
• geo (ISO2)
• language (ISO639)
• status (enum: pending, sent, indexed, failed)
• response_code (int)
• last_checked_at (timestamp)

4. Provider / Vendor

• provider_id (UUID)
• name (string)
• api_endpoint (string)
• rate_limit_per_min (int)
• success_rate_percent (float)

5. Audit / Log

• log_id (UUID)
• entity (string)
• entity_id (UUID)
• event_type (string)
• payload (JSON)
• created_at (timestamp)

Эта модель покрывает 90% потребностей платформы в разделе Услуги commercial-services: заказ -> разбиение на прогон -> отправка URL -> получение статуса.

Реляционная vs документная модели: рекомендации

• Реляционная БД (Postgres, MySQL): оптимальна для транзакционных данных (заказы, счета, статусы). Преимущество: ACID, сложные JOIN'ы для отчетности. Рекомендация: хранить Campaign, Run, URL (как reference) в реляционной БД.
• Документная БД (MongoDB, Elasticsearch): полезна для логов, сырых webhook'ов и быстрого поиска по тексту/анкорам. Для аналитики по текстовым полям (anchor_text, content snippets) лучше индексировать в Elasticsearch.

Объёмные ориентиры:

• если платформа обрабатывает 10 000–100 000 URL в сутки — комбинированный подход (Postgres + ES) оправдан;
• при 1–5 млн URL/сутки потребуется шардирование и очередь сообщений (Kafka/RabbitMQ).

Примеры схем и JSON-образец

Минимальный JSON для создания прогона (run):

```json { "campaign_id": "b4c2f8a6-1d3b-4e8a-9a2f-3d7b2f6a9c12", "provider_id": "9a7d5b2c-3f11-4c7a-8b2f-1d9e6a2c8b33", "run_type": "crawl", "urls": [ {"url": "https://example.com/page1", "anchor_text": "купить обувь", "priority": 8, "geo": "RU"}, {"url": "https://example.com/page2", "anchor_text": "заказать прогон", "priority": 5, "geo": "UA"} ], "scheduled_at": "2026-08-01T09:00:00Z" } ```

SQL-таблица runs (пример столбцов):

• id UUID PRIMARY KEY
• campaign_id UUID REFERENCES campaigns(id)
• provider_id UUID
• run_type VARCHAR(20)
• urls_count INT
• status VARCHAR(20)
• cost_cents INT
• created_at TIMESTAMP
• updated_at TIMESTAMP

Идентификация, idempotency и вебхуки

Важные практики:

• Используйте UUIDv4 для глобальной уникальности. Для human-readable — добавляйте инкрементный order_number.
• idempotency_key при отправке батчей к провайдеру: повторная отправка с тем же ключом не должна создавать дубликаты. Стандарт: TTL idempotency = 72 часа.
• Вебхуки: payload должен содержать run_id, url_id, status, timestamp. Обязательна проверка подписи HMAC; retry — 3 попытки с экспоненциальной задержкой (например, 1m, 5m, 30m).

Очереди, батчи и ограничения провайдеров

Практические числа:

• Размер батча: 100–1 000 URL (зависит от провайдера). Рекомендуемая отправка по 500 URL/батч.
• Rate limit: 60–600 запросов/мин. Настройте throttling и circuit breaker.
• Очередь задач: Kafka/RabbitMQ позволят обеспечить throughput 10k+ сообщений/сек при правильном шардинге.

Дедупликация: до отправки в провайдеров выполняйте хеширование URL (normalize + SHA256). Это снижает повторную оплату за дубли URL на 5–15% в реальных проектах.

Метаданные и классификация

Полезные поля для управления качеством и аналитикой:

• anchor_text, anchor_type
• topical_category (taxonomies: ecommerce, news, blog)
• trust_score (0..100) / domain_rating
• crawl_priority (0..1 float)
• retry_count, last_error_code

Эти метаданные позволяют:

• фильтровать низкокачественные URL;
• группировать по тематике при заказе прогонов;
• рассчитывать прогнозный CTR/индексацию.

KPI и метрики для commercial-services

Ключевые метрики, их целевые значения и методы расчета:

• Success Rate (процент URL, отмеченных как indexed): целевой показатель 60–80% для массовых услуг, 80–95% для премиум-провайдеров.
• Time to Index (среднее время до первого упоминания в поиске): измеряется в днях; целевой диапазон 3–30 дней в зависимости от типа услуги.
• Throughput (URL/час): целевые уровни 10k/час для средней платформы, 100k+/час для масштабных решений.
• Cost per Indexed URL (руб./шт.): рассчитывается по фактическим расходам и payout провайдерам.

Мониторинг:

• экспортируйте метрики в Prometheus + Grafana;
• настраивайте alert при падении success_rate ниже 50% или при задержке очереди > 6 часов.

Архивирование, хранение логов и ретеншн

Рекомендации:

• Хранить raw-логи webhook/ответов 90 дней online и архивировать в холодное хранилище (S3 Glacier) на 1–3 года.
• Аггрегированные метрики — хранить 2–5 лет для отчётности клиентов.
• Сырые payload’ы (тел. номера, PII) удалять в соответствии с GDPR через configurable retention.

Безопасность и соответствие (compliance)

• API: OAuth 2.0 или API keys с ролевым доступом.
• Шифрование: TLS 1.2+ in transit, AES-256 at rest.
• Логи доступа: храните audit trails 365 дней.
• Для commercial-services — важно включать в SLA пункты по сохранению данных клиентов и по времени реакции на инциденты (например, RTO 1 час, RPO 1 час для критичных сервисов).

Архитектурные паттерны и лучшие практики

• Event-driven архитектура: использовать события (run.created, url.sent, url.indexed) и event sourcing для восстановления состояния.
• CQRS: разделите запись/чтение для уменьшения нагрузки на OLTP базу.
• Партиционирование таблиц по времени (month/year) при объёмах > 1M записей в месяц.
• Предварительная валидация данных на клиенте: уменьшает долю ошибок на 40–60%.
• Тестовые кампании: выделяйте 1–2% трафика для A/B тестирования новых провайдеров/анкор-стратегий.

Пример сценария работы (в цифрах)

Пример: клиент запустил кампанию из 12 000 URL.

• Сервис разбивает на 24 батча по 500 URL.
• Отправка проходит к 3 провайдерам по очереди (parallel=3).
• Ожидаемый Throughput: 24 батча / (время обработки батча), при времени обработки 1 мин -> 24 мин на отправку.
• При success_rate провайдера 70% ожидаем ~8 400 URL помечены как indexed в течение 14 дней; 3 600 пойдут в ретрайн/повторные прогоны.

Интеграция с руководством commercial-services

Эта статья — часть руководства commercial-services и раздела Услуги. Практические схемы и рекомендации здесь помогут выстроить единый data model для заказов прогонов и индексации. В других статьях руководства commercial-services мы детализируем интеграции с провайдерами, ценообразование и SLA для клиентов — используйте единую структуру данных, чтобы упростить интеграцию между этими частями.

Заключение — план внедрения

1. Создайте базовую реляционную схему для Campaign/Run/URL и Audit-логов. 2. Настройте очередь (Kafka/RabbitMQ) и idempotency для батчей. 3. Индексируйте текстовые поля в Elasticsearch для поиска и аналитики. 4. Введите retention-политику: raw-логи 90 дней, агрегаты 2 года. 5. Мониторьте success_rate и time_to_index; корректируйте партиционирование и шардирование при росте >100k URL/день.

Эти шаги позволят обеспечить масштабируемость, сохранность данных и удобство отчетности в рамках раздела Услуги руководства commercial-services.

Вернуться к руководству: /commercial-services/