У мускуля для этих целей есть движок merge (вместо innodb).

Озвученная нагрузка - детская.

Скорость обработки запроса будет 1 миллисек при правильно настроенном всём как надо.

append-only тип нагрузки - самый простой в природе.

Посмотри на СУБД yandex clickhouse - она вообще рождена для того, что ты хочешь. В кликхаусе данные займут минимвльно возможное число байт на диске, ибо она колоночная, а жать поколоночно сам бог велел. Ну и еще кликхаус - он merge по природе своея.

Непонятно что за запросы на чтение будут, если всякие аггркюегации - то в кликхаусе они летают. И он для этого не хранит ничего, кроме самих данных.

mysql - ок. Добавлять что-то постоянно в конец - примитивная и для мускуля таска. Ну если не 100500 индексов и прочей куеты.

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

Ни одна из фич могни тут использована не будет.
Монга заточена под произвольный набор полей в документе и индексацию по ним, а вопрос логирования - оеа с ним никак не связана (монга). Если схема у афтара фиксированная, зачем ему монга, на диске мускуль меньше займёт.

Я как-то в 2014 пейсал на C++ штуку, которая херачила сотни нефти в MySQL. В конфиге стояло число 1024 и оно пейсало в 1024 таблицы с именами wwww_%d скажем.

С чем именно мы таким макаром бились - это уже конь проссыт. Предположительно:
- имея 1024 независимых индексов, мы уменьшаем вероятность сидения в локе.
- индекс условного размера 1/1024 быстрее апдейтить, чем размера 1. То есть цена инсерта снижена.

Но да, больше срем на диск, ведь индекс (b+tree) всегда имеет в страницах пустоту.

Штука была многопоточная, это её и сгубировало.

Зато как: пришло тело, кладет обьект 50. Пошло в таблицу zzz_50. Класть обьект, допустим, долго из-за трех индексов, мать их. В другом потоке новое тельце пришло читать обьект 66 и пошло в таблицу zzz_66. Тот факт, что щас индексы в таблице zzz_50 модифицируются и она залочена, не волнует клиента 66 - он куяк и прочитал без блокировок своё. Ясно, что в нормальных движках, (видимо в InnoDB) читатели не ждут пейсателей, а видят свой снепшот мира в изоляции от других транзакций. То есть 66 бы прочитался из таблицы, куда шас пишут 50, без базара. А транзакции нам нах не нужны больше ни для чего. Держать сложный движок только ради этого? Фтопку! Проще пошардить на 1024 и взять движок MyISAM, который попроще и побыстрее за счет своей относительной тупости. Профит.

Рекомендую осуществить наглый зазыр доступных в MySQL движков. Там че только нет. Есть даже движок CSV - то есть он в каталоге данных прямо CSV кладет. Ему туда подсовываешь csv филе и куяк таблица уже создана. То есть ты селектишь прямо из CSV файла. Индексов нет. Жесть конечно, зато конизм. Хош поселектить ЦСВ-шечку, карл? И там есть еще merge движок какой-то: он условно пишет гиг, потом куй на него кладет и пишет новый гиг. Незнаю что потом. Читает как-то хитро. ClickHouse так делает, но CH в фоне эти куски гиговые агрегирует ещё и т.п.