Юзай tokudb или rocksdb Lz4//zstd/snappy

Или напрямую в кликхаус через хттп апи

я прогер, а не  сисадмин,моя работа чтобы на стандартных настройках базы данных запускался
это потом уже сисадмины  должны тюнить....

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

а вот это кстати интересно бы было на досуге поковырять
https://scr.vodolaz095.life/s/dXxU8475k.png

в админере уже запилили поддержку кликхауса

В любом случае innodb под логи такое себе решение

ладно, вот тогда вопрос. Что в таком случае лучше всего гонять?

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

https://scr.vodolaz095.life/s/TcYY1isbb.png


индексы сделаны по всем запросам, которые часто делаются к базе

данные храняться 3 месяца, потом просто старые удаляются, и делается VACCUUM

данные хранятся так
https://scr.vodolaz095.life/s/FyFOHssZp.png

что для такого случая, описанного выше, лучше чем таблица в штатной базе данных postgresql?

Форк постгри

на 30к/день пофиг что гонять, на 300к я бы уже взял кликхаус

т.е. гдет 9м записей, судя по всему запись ну 4кб в среднем, т.е. примерно 36гб. Поток записи оч небольшой, меньше мегабайта в минуту. Это в чём угодно можно хранить, пока на индексы и горячие данные хватает памяти.

Документное хранилище с компрессией будет удобнее: не надо будет дублировать поля из метаданных и по этим полям можно строить индексы.

> гдет 9м записей
это идёт номер записи, это 9 миллион с момента запуска стейджинг сервера этой весной. на самом деле там гдето 200-300 тысяч записей в таблице.

старые трём.

а какое документальное хранилище?
Монго? Elastic Search? RethinkDB? CouchDB?

я за монгу

но я её варю с первых дней её существования

например в монге ещё можно будет выкинуть два индекса: timestamp и timestamp, level, потому что они префиксы других индексов

в 4.2 тож завезли zstd, оно вероятно будет очень хорошо такое жать

впрочем тексты и снаппи неплохо хавает

за ~600 баксов в месяц это можно будет засунуть в atlas вообще и не тратить бабки на оперейшенс

да. возможно имеет смысл оставить только INDEX  timestamp, level, user

а потом переписать запросы, где level NOT NULL, USER NOT NULL,  чтобы только один индекс гонялся для извлечения данных...
на монго это врятли одобрят, потому что и так там целый зоопарк баз данных, а с постгрессом - у нас хотяюы есть человек, который админил базу данных в 250 миллионов записей, знает как репликацию с patroni или ещё чем то делать и т.д.