@ilyagod
Кодю код

Хранение логов платежей — что выбрать, sql, nosql или файлы?

Есть некоторый софт, который проводит платежи и вот такие таблички:

payments (payment_id int auto_increment primary key) - более знать о ней ничего не нужно
payment_log (payment_id int, text text, date_add datetime default now());

Платежей в день несколько тысяч (10-15, по разному - на данный момент около 35млн записей), на каждый платеж разное количество логов. от пары записей, до нескольких десятков. Пишутся они не за цикл работы, а лог может добавится и спустя какое-то время. Например платеж весит в процессе из-за проблем на шлюзе и каждый опрос статуса мы логируем раз в n минут. Поэтому не получится составить что-то типа {'payment_id': 123, 'logs': [...., ...., ....]}, записать и забыть. Нужно быстрое добавление в list( или какую-то другую структуру) по ключу.

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

вариант 1. Оставить как есть, минус в том что не нравится эстетически, увлеичивается время бекапа и тд и тп. тут все очевидно.
вариант 2. Перенести логи в nosql (какое-нибудь монго или редис), особо дел не имел в таком ключе, поэтому не знаю
вариант 3. Перенести в файлы завязавшись на ид: для id 12345678 файл будет лежать где-нибудь в /mnt/payment_logs/1/2/3/4/5/1234578.txt - тоже не очень нравится эстетически

Подитожу
Вобщем прошу помощи, где лучше хранить данные вида {'payment_id': 123, 'logs': [{'date_add': '...', 'text': 'log #1'}, {'date_add': '...', 'text': 'log #2'}] и ыстрым добавылением в колекцию logs по payment_id.
  • Вопрос задан
  • 397 просмотров
Пригласить эксперта
Ответы на вопрос 3
sergey-gornostaev
@sergey-gornostaev Куратор тега SQL
Седой и строгий
@awesomer
Текстовые файлы обычные.
Если вы собираетесь что то там реально искать регулярно - то какой нибудь ElasticSearch (если затачиваться на многосерверность - на кластер) или SphinxSearch (если затачиваться на скорость)
Ответ написан
@viras777
Жаль, что у вас не postgresql, а так как вам надо редко и нечасто обращаться к этим данным, то можно было бы сделать партицирование этой таблички и перенести хранилище таблицы на другой диск (медленный и недорогой).
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы