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

Question

[Илья Лопуга]

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

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.

Answer 1

[Сергей Горностаев]

Можно в Logstash.

Comments

[hydra_13]

соглашусь, ELK Вам в помощь.

[Илья Лопуга]

Спасибо, юзаем его для логов с приложения. Но разве он сможет отдавать быстро нужный мне лог? потому как выводить его надо в нашей системе, а не в кибане

[Сергей Горностаев]

Илья Лопуга, лежащий в основе elasticsearch очень быстрый.

Answer 2

[awesomer]

Текстовые файлы обычные.
Если вы собираетесь что то там реально искать регулярно - то какой нибудь ElasticSearch (если затачиваться на многосерверность - на кластер) или SphinxSearch (если затачиваться на скорость)

Comments

[Илья Лопуга]

в самих логах никакого поиска. лишь достать все записи по payment_id и отсартированые по date

[awesomer]

Илья Лопуга, это и есть поиск

Answer 3

[Сергей]

Жаль, что у вас не postgresql, а так как вам надо редко и нечасто обращаться к этим данным, то можно было бы сделать партицирование этой таблички и перенести хранилище таблицы на другой диск (медленный и недорогой).

Comments

[Илья Лопуга]

я от себя эту фразу слышу частенько. В планах переезд на другую БД есть, но сейчас пока не до него.