Dice Chess Wiki

Sql Pobezhdaet

3 min read

Отличное завершение теоретической части! Выбор между реляционными базами (SQL) и NoSQL (MongoDB, Cassandra и т.д.) — это всегда вопрос того, как именно мы собираемся читать данные.

Да, я рассматривал NoSQL (в частности, документо-ориентированные базы вроде MongoDB), так как текущие данные у тебя уже лежат в формате JSON. Но для шахматной аналитики NoSQL проигрывает PostgreSQL по нескольким ключевым причинам.

Давай разберем, почему PostgreSQL в нашем случае — абсолютный победитель.

1. Суть NoSQL — денормализация, а нам нужна дедупликация

В NoSQL (например, MongoDB) идеальная структура — это положить всё в один большой “документ” (JSON), чтобы прочитать его за одно обращение к диску. В такой структуре в каждый ход (turn) нам пришлось бы вписывать строку позиции (rnbqkbnr/...). Это означает, что одна и та же начальная позиция будет сохранена в базе 10 миллионов раз. Если же мы в NoSQL попытаемся вынести позиции в отдельную “коллекцию” (сделать аналог таблицы positions), нам придется делать соединения (Joins) на уровне кода приложения. NoSQL базы очень плохо и медленно умеют делать Joins.

Преимущество Postgres: Он изначально создан для нормализации. Мы храним позицию один раз, а миллионы ходов просто ссылаются на неё по короткому числовому ID, и база соединяет их за миллисекунды.

2. Сложная аналитика и Агрегации (SQL побеждает)

Твоя главная цель — выработка стратегий и аналитика. Представь запрос: “Найти процент побед белых из позиции X, при условии, что рейтинг игроков был больше 2000, и выкинутые кубики включали коня”.

В PostgreSQL это пишется естественным языком:

SELECT COUNT(*) FILTER (WHERE result = 1) / COUNT(*)
FROM turns JOIN games ON turns.game_id = games.id
WHERE position_id = 123 AND dice_sorted LIKE '%N%' AND games.white_rating > 2000;

В MongoDB написать подобный Aggregation Pipeline — это мучение на десятки строк кода. Реляционная алгебра SQL до сих пор является непревзойденным стандартом для сложной аналитики (OLAP).

3. PostgreSQL имеет встроенный NoSQL (JSONB)

Современный Postgres часто называют “лучшей NoSQL базой данных”. У нас есть колонка metadata JSONB. Если у партии появляются какие-то уникальные атрибуты (например, количество заработанного золота, ID турнира, аватарка оппонента), нам не нужно менять схему таблиц (как в старом SQL). Мы просто кидаем это в JSONB. И более того, Postgres умеет строить сверхбыстрые индексы прямо по ключам внутри JSON! Это дает нам лучшее из двух миров.

4. Типы данных и Индексы

В NoSQL базах часто ограничен выбор индексов. В PostgreSQL мы используем:

  • Hash индексы (идеально для поиска FEN-строки).
  • Массивы VARCHAR[] с GIN-индексами (можно искать, содержится ли ход ‘e2e4’ в массиве сыгранных ходов за долю секунды).

Итог:

NoSQL отлично подходит для корзин интернет-магазинов, логов или профилей пользователей, где структура плавает, а данные читаются целиком. Но шахматная партия — это строго реляционная структура: игроки играют партии, партии состоят из ходов, ходы меняют позиции. И PostgreSQL создан именно для того, чтобы связывать эти сущности максимально эффективно.

Если эти аргументы закрывают все твои сомнения, то у нас на руках есть полностью проработанная, современная и масштабируемая архитектура базы данных!

Какой будет наш следующий шаг? Хочешь ли ты, чтобы я на основе этого плана сгенерировал SQL-скрипты для создания этих таблиц (миграции для SQLAlchemy/Alembic), или перейдем к написанию скрипта-импортера JSON?

Graph View