Хранение логов платежей — что выбрать, 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.
Спасибо, юзаем его для логов с приложения. Но разве он сможет отдавать быстро нужный мне лог? потому как выводить его надо в нашей системе, а не в кибане
Текстовые файлы обычные.
Если вы собираетесь что то там реально искать регулярно - то какой нибудь ElasticSearch (если затачиваться на многосерверность - на кластер) или SphinxSearch (если затачиваться на скорость)
Жаль, что у вас не postgresql, а так как вам надо редко и нечасто обращаться к этим данным, то можно было бы сделать партицирование этой таблички и перенести хранилище таблицы на другой диск (медленный и недорогой).
Простой
