ClickHouse масштабируется более чем на 100 петабайт журналов ( clickhouse.com )
Всякий раз, когда я читаю что-то подобное, я думаю: вы делаете это неправильно. Я полагаю, что это удивительный инженерный подвиг для Clickhouse, но я думаю, что мы (как в ИТ, так и все люди) должны действительно сократить объем создаваемых нами данных. Это расточительно.
Общие заявления, подобные этому, упускают суть. Не все данные — отходы. Особенно высокомощные, невыборочные трассировки. На 4-ядерном узле ClickHouse мы обрабатывали миллионы интервалов в минуту. Даже короткие окна хранения обеспечивали критическую видимость для отладки и анализа.
Конечно, нам следует сократить отходы, но сжатие существует не просто так. Отбрасывание ценных данных о наблюдаемости ради экономии места обычно недальновидно.
И хранилище больше не является узким местом, как раньше. Многоуровневое хранилище с S3 или аналогичными бэкэндами стоит дешево и позволяет хранить данные полной точности, не выходя за рамки бюджета.
Проблема в том, что у вас есть журналы за много лет, но нет возможности получить прямую трансляцию журналов, которые ведутся сейчас.
(одно из моих самых больших разочарований в Kubernetes — ни одна из команд для просмотра журналов, похоже, не принимает логические агрегаты, такие как «покажи мне все из этого развертывания»).
Возможно, не через kubectl напрямую, но это довольно просто сделать, просто объединив все потоки журналов из модулей развертывания (или чего-то еще).
k9s (k9scli.io) поддерживает это напрямую.
Звучит довольно просто, можно написать это с помощью десятков строк кода на Python.
И какой смысл хранить годы журналов? Я, наверное, мог бы понять очень чувствительные отрасли, но в целом я вижу чистую трату ресурсов. Максимум, что вам нужно, это 60-90 дней журналов.
Короче говоря, теперь они делают нулевую (?) копию необработанных байтов вместо маршалинга и демаршалинга json.
Source: news.ycombinator.com