Посоветуйте, пожалуйста, как мне принять структурированные логи.

Ну я бы тебе советовал ELK/greylog стек или вариации, но если у тебя нет джавщиков в команде, то может и не надо. На больших объемах там нужна будет экспертиза.<br>https://habr.com/ru/company/odnoklassniki/blog/494260/

Если типов событий 40-50, но их приходит так мало, то можно может быть ClickHouse и не нужен :). Если прямо совсем не нужен реалтайм и можно событий чуть-чуть потерять при падении сервера или самого ClickHouse (что должно происходить очень очень редко), то можно сделать по таблице на тип событий и настроить буферные таблицы перед ними так, чтобы реально туда данные сбрасывались лишь раз в минуту, скажем. В общем, для ClickHouse главное — не писать туда чаще ~1 раза в секунду, если используются HDD.

Я бы сказал ELK. Вроде в последнее время там всё меньше боли с деплоем и настройкой.

aws sqs+ aws lambda + s3 + athena

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

Можно использовать в качестве транспорта Kafka, в нее просто кладешь json, у Clickhouse есть штатный механизм queue -&gt; view -&gt; table, он читает json из Kafka и раскладывает json по колонкам и переносит в таблицу, попутно можно обогатить данные или преобразовать тип.

Монга же.

А сколько времени нужно хранить данные? Какова глубина доступа к данным? <br><br>Насколько быстро нужно достать старые логи?<br><br>А с ними нужно работать? Какой профиль работы? Какие запросы будут делаться? А аналитика по логам будет?

только преобразоанием.

Если хочется переживать пики, то нужен буфер, например kafka.<br>Куда класть? Ну если типов реально 40-50, то вполне реально предзаготовить таблицы в ClickHouse и класть в него. Точнее он сам умеет забирать из kafka.

Можно хранить «не общие» поля в кликхаусе в json - он довольно эффективно по нему ходит и достаёт.<br><br>Главное среди «общих полей» иметь те, на которые можно повесить индексы, чтобы выборку в запросах существенно сужать.<br><br>Мы так наливаем ~300к сообщений из логов в секунду в кликхаус на hdd и нормально селектим. Эластик с такой нагрузкой хочет на порядок больше железа и все равно работает херово.

Можно в монгу.

В этом задании есть неописанные нефункциональные требования. Если "Всё это очень хорошо шардится по владельцам серверов и по времени" - почему бы не уйти в multi tenancy, и не сделать множество независимых хранилищ? Зачем здесь централизация и героическая борьба? Вероятно, кроме мапинга на логи есть еще требования.<br>100k/sec - не rocket science, это даже кролик может вертеть, только непонятно зачем именно так, если задача решается самыми разными способами. Смотрели ли на вариант по монге на инстанс? А sqs/lambda/s3/athena?

А надо коррелировать логи между клиентами?

Cassandra?

Под логами что понимается? Если там реально логи с текстами, то clickhouse будет не так хорош, ellastic предпочтительней.

Kafka-&gt;Clickhouse(kafka engine + json per line)<br>Просто идеально для вашего случая. Сверху, взяв пилу и напильник, накрутить loghouse (он для дугого, но морду просмотра логов можно выдрать)

AWS CloudWatch Logs. Дешево, бесконечно, гибкий язык запросов для разбора полетов, алерты, конвертация в метрики и т.п. JSON парсит на лету.

А читать их будет один чел, несколько? Какой режим обращений к базе? Эт я просто вслух рассуждаю.

Абаждите!<br>1000 серверов по 100 событий в секунду по 1кб - это ~10Тб в сутки. <br>Как бы и фиг с ним, но тут уже надо понять, какой у вас будет селект, с чем джойн и на какую глубину отбор: сутки? Неделя? Месяц? Год? <br>По потоку: можно лить через кафку, складывать туда, где вы сможете это заселектить и сджойнить. При просмотре хотя бы на сутки-неделю это будет hadoop и spark, например. Если вы готовы урезать окно просмотра до минуты, то хоть в памяти словарем держите, хоть mysql, хоть что угодно.<br>По схеме данных - зависит от того, как будет селект.<br>Если я правильно угадал, что значит связывать, то одна таблица - список всех событий для джойна и к ней нужное количество таблиц с детальными атрибутами в зависисости от типа.<br>Второй вариант при колоночном хранении сделать сверхширокую схему, как объединение всех имеющихся

попробуй timescaldb - потом расскажешь ;)

ребята на конфе про сотни терабайт рассказывали в pg. Шардить ручками

Мы схожую задачу про поток событий решили для нескольких хранилищ. Типов событий - несколько сотен. Все типы событий и атрибуты соответствующие этим типам объявлены заранее в реестре (конфиге). И вот этот централизованный реестр дал нам широкий простор для адаптации под разные хранилища. Не везде мы затачивались под наиболее оптимальное хранение, потому просто покажу разнообразие. У событий есть глобально общие поля - тип, время, идентификатор, версия приложения и т.д. Их там штук 20 и они организованы в структуры. У каждого события есть свои специфичные поля в зависимости от типа события. В ClickHouse общие поля вынесены в столбцы. Специфичные для типа поля вынесены в два параллельных массива строк - с ключами и значениями. В Hadoop (Hive/Presto) для обобщающей таблицы общие поля вынесены в соответствующие структурные столбцы, а специфичные в map&lt;string, string&gt;. Также есть и по таблице на эвент, где все специфичные поля раскрыты в отдельные столбцы. В Exasol - кажому эвенту своя таблица, каждому полю - свой столбец соответствующего типа. Сделать генератор DDL и скрипты миграции на новый конфиг - простая задача. Самым главным тут является центральный реестр событий: хранится и развивается в отдельной репе, расширяется централизованно, позволяет генерировать SDK под разные языки и поддерживать актуальную структуру БД. А, и документация к событиям тоже получается актуальной. Хоть я и не ответил на твой вопрос, но показал, что когда у тебя есть реестр, то выбор хранилища можно делать каким хочешь и уже по месту оптимизировать под задачу. Или даже выбрать несколько хранилищ для разных задач.

В озоне сразу писали в kafka, а потом из нее выгребали, обогащали(условно когда по id пользователя находишь его регион) и после этого клали в клик

Apache Parquet хоть в хадуп, хоть на фс. Потом можно позапрашивать и в спарк позагонять.

Коллеги, большое спасибо за советы.<br><br>Я решил остановиться пока на такой схеме:<br><br>* генерируем типизированное описание тех полей, которые мы хотим слать в логах<br>* по ним строим и апдейтим структуру в кликхаусе<br>* храним всё в кликхаусе<br>* сливаем через промежуточный прокси (у меня всё равно хитрая авторизация клиентов)