Сергей Соловьев

Решение простое - создаешь мок БД для тестов.
1. Тест начинается - запускаешь БД и заполняешь данными необходимыми (как сказал Василий Банников можно сделать дамп с удаленными чувствительными данными)
2. После каждого теста необходимо выполнить откат - если какие-то данные были добавлены/удалены/изменены
3. При завершении тестирования удаляешь БД

На мой взгляд, здесь просто много инфраструктурной работы. Полезные инструменты:

1. Testcontainers - запускаешь БД в контейнере. Сам ей пользовался, есть много шаблонов для разных БД, чтобы с нуля не писать все. Можно также скрипт инициализации (схема, дамп) добавить - вот тебе и настройка
   
2. В зависимости от фреймворка есть разные механизмы запуска кода после каждого тест-кейса. Если про xUnit, то:
   1. Тестовый класс реализует IDisposable - выполняется после каждого тест-кейса. Можно тут реализовать логику отката БД
      
   2. Для инициализации самого контейнера (чтобы каждый раз не запускать заново) - IClassFixture
   
   

Также никто не отменял внешний инстанс БД использовать - просишь дба создать отдельную БД специально для тестов, просто запускать теперь параллельно не получится

Алгоритм, вкратце, следующий:
1. Создаешь документ "О персональных данных"/"О политике конфиденциальности". В нем говорится что ты о пользователе собираешь (имя, пол, предпочтения в еде (???)) и ДЛЯ ЧЕГО. Последнее важно, т.к. любая собираемая информация должна использоваться для чего-то существенного, нельзя собирать просто так.
Как создать его - это лучше консультироваться с юристами, т.к. по большей части это бюрократия
2. Подаешь заявление РКН на становление оператором персональных данных - это статья 22 152 ФЗ
Отправлять можно разными способами - https://pd.rkn.gov.ru/operators-registry/notificat... .
Есть варианты:
- Бумажный - распечатываешь, заполняешь и отправляешь в территориальный орган местный
- Электронная почта - заполняешь форму и подписываешь усиленной подписью
- Гос. услуги - то же самое как и 2, но подпись усилиями гос. услуг

Он делается за месяц (срок - 30 дней) и после этого либо возвращают (ошибки или просто нет условий становлением), либо вносят в список.

Что касается самого хранения, то главное, чтобы хранились эти данные на территории России. Простое решение - аренда VPS в России и запуск БД там (хотя слышал и про обходные пути) - РКН может прийти и проверить

Можно, даже несколькими способами:
1. Отдельные таблицы с характеристиками по каждому аккаунту. Например, для стима типа

create table product_steam_info(product_id int, level int, balance double)

и для телеги соответственно.
Чтобы получить результат полный - SELECT с JOIN'ом (left join нужен будет)
2. Все в одной таблице хранишь

create table products(product_id int, steam_level int, telegram_is_premium boolean)

Если у кого-то нет телеги или стима, то эти поля просто будут null

Предлагаю использовать последний вариант, т.к. его проще реализовать и будет быстрее (т.к. локальность данных больше и нет join'ов), но таблица может стать большой слишком когда много типов аккаунтов будет

Ответ: Для экстремально быстрой online-аналитики нужны экстремально быстрые инструменты

Если серьезно, то когда речь заходит о хайлоаде, то нет готовых решений. Все приходится писать самим и тюнить весь софт под свои нужды.
Чтобы помочь надо знать контекст, а "чем быстрее, тем лучше" - у всех так.

Все что могу предложить:
- Горизонтально масштабировать софт, который эти данные от источников читает
- Использовать ClickHouse для хранения данных

Почему ClickHouse:
- Создан для OLAP задач
- Имеет поддержку шардирования причем шарды независимы - не нужно тратиться на синхронизацию

P.S. если это задача по трейдингу, то советую копать в сторону HFT

liquibase может помочь.
Вроде как у него есть поддержка SQlite