Dice Chess Wiki

10 000 игр

2 min read

10 000 игр — это приличный объем. При текущей средней задержке в 250 мс (чтобы не злить сервер Dice Chess), полная синхронизация займет около 42 минут ( сек).

Обычный HTTP-запрос от браузера к серверу столько не проживет — он отвалится по тайм-ауту (обычно это 30–60 секунд).

Вот какие варианты я вижу, от простых к «профессиональным»:

Вариант 1: «Автокликер» на фронтенде (Самый быстрый в реализации)

Мы можем изменить логику в AdminView.svelte так, чтобы после завершения одного батча (например, 100 игр) фронтенд автоматически запускал следующий, пока счетчик missingMovesCount не станет равным нулю.

  • Плюсы: Виден прогресс-бар, легко остановить (закрыв вкладку), не нужно менять архитектуру бэкенда.
  • Минусы: Нужно держать вкладку браузера открытой. Если интернет моргнет, процесс остановится.

Вариант 2: Использование существующего CLI-скрипта (Самый надежный)

У нас уже есть backend-api/scripts/experiments/fetch_games.py. Мы можем его немного доработать, чтобы он умел просто «докачивать всё, чего не хватает».

  • Плюсы: Можно запустить в терминале (через screen или nohup) и забыть. Никаких тайм-аутов HTTP. Самый стабильный вариант для разовой «прокачки» большой базы.
  • Минусы: Нужно заходить на сервер через SSH.

Вариант 3: Фоновая задача через FastAPI BackgroundTasks

Когда вы нажимаете кнопку в админке, сервер отвечает «Ок, я начал», и продолжает качать игры в отдельном потоке.

  • Плюсы: Нажал кнопку и закрыл браузер.
  • Минусы: Трудно отслеживать прогресс из UI (нужны либо уведомления, либо отдельный эндпоинт статуса). Если сервер перезагрузится, задача умрет и её нужно будет запускать снова.

Вариант 4: Масштабируемый ETL (Cron / Периодическая задача)

Настроить скрипт так, чтобы он просыпался каждые 5 минут и докачивал по 50 игр.

  • Плюсы: Минимальная нагрузка на сеть, выглядит для Dice Chess как «естественная» активность.
  • Минусы: 10 000 игр будут качаться долго (около 16 часов при таком темпе).

Моя рекомендация:

Для разовой заливки 10 000 игр я бы выбрал Вариант 2 (CLI). Это даст нам максимальный контроль и стабильность. Мы можем запустить его с параметром --max 10000, и он спокойно всё выкачает.

А для будущего поддержания базы в актуальном состоянии я бы реализовал Вариант 1 (Авто-степпер в UI), чтобы вы могли зайти раз в неделю, нажать «Sync All» и видеть, как бежит полоска прогресса.

Что думаешь? С чего начнем: оживим CLI-скрипт или добавим «авто-цикл» в админку?

Graph View