Переход с SQLite на PostgreSQL

Зачем

Текущая серверная база на SQLite удобна для простого односерверного режима, но она хуже подходит для большого числа параллельных записей, роста нагрузки и дальнейшего масштабирования сервера.

PostgreSQL нужен как следующий уровень серверной БД для более надёжной конкурентной записи, более предсказуемой работы под нагрузкой и дальнейшего роста проекта.

Что сделать

Подготовить план переноса серверной БД с SQLite на PostgreSQL.
Найти все места, где код завязан на особенности SQLite.
Проверить все DAO и SQL-запросы на совместимость с PostgreSQL.
Продумать схему миграции существующей production/test базы без потери данных.
Отдельно проверить транзакции, UPSERT, индексы, case-insensitive сравнения и миграции схемы.
После этого подготовить отдельный этап внедрения и переключения сервера.

Что уже есть в коде

Доступ к БД в основном проходит через DAO-слой, а не полностью размазан по проекту.
Основная серверная логика уже разделена по модулям.
Но SQL и миграции сейчас написаны под SQLite и потребуют отдельного прохода.

Откуда продолжать

Начать с инвентаризации всех DAO и схемы БД.
После этого сделать отдельный документ с оценкой объёма работ по переносу.
Затем решить, будет ли это:
- полный перевод сервера на PostgreSQL;
- или поддержка двух драйверов на переходный период.

Что потом обновить

Серверную документацию по БД и миграциям.
Инструкции по локальному запуску сервера.
Скрипты деплоя и настройки окружения.

Что временно отключено и что вернуть потом

В серверном runtime временно снята проверка channelName must not contain only digits в SHiNE-server/shine-server-db/src/main/java/shine/db/channels/ChannelNameRules.java.
Причина: на боевой истории уже есть блоки с числовыми именами каналов, и сервер должен уметь с нуля восстановить blockchain_state и .bch, подтягивая старые блоки от других sync-серверов.
Что осталось как текущее поведение:
- UI по-прежнему не даёт создать новый канал только из цифр;
- сервер принимает такие имена, чтобы не ломать replay старых блоков.
Что нужно сделать отдельным следующим шагом:
- вернуть серверное продуктовое правило для новых каналов;
- сделать это совместимо со старой историей, чтобы импорт/реплей существующих блоков не падал на старых числовых channel name.
Какие документы обновить при возврате:
- docs/libs/shine-server-bd/POSTGRES_RUNTIME_SCHEMA_V1.md;
- UI/серверные документы по правилам имён каналов, если появится отдельная спецификация.
С какого сценария продолжать:
- повторить cold start тест на t2: пустая PostgreSQL schema, удалённые .bch, новый запуск, ожидание полной синхронизации от t1/t3.
Последняя полная рабочая точка с этим временным компромиссом:
- ветка migration-postgres, коммит будет создан после этой записи.

4.7 KiB Raw Blame History Unescape Escape