Ну, это все же не тоже самое. Тут у вас один большой временной ряд. Можно было бы просто хранить все в файле. В feather файле, например, так у вас было бы сжатие.
Dalmatiner работает забавно (если я правильно их понял). Они просто пишут на диск весь поток, даже без сортировки. Далее, во время чтения интервала (t1, t2) они читают (t1 — delta, t2 + delta) в надежде на то, что все нужные будут там. Сжатие за счет ZFS.
Причина в том, что пользователь хочет durability и хранить много данных. Данные хранятся и кэшируются в памяти, если она есть, никаких проблем в этом нет. Но если периодически синхронизировать in-memory store, то это сожрет пропускную способность диска очень сильно. Допустим у нас есть 1М уникальных временных рядов, пусть каждый из них имеет хотя бы одну не заполненную полностью страницу памяти (скорее всего так и будет всегда). Страница — 4КБ, мы должны будем записать на диск 4ГБ данных чтобы синхронизировать только вот эти вот незаполненные полностью страницы. Каждый раз когда страница изменилась (туда дописали несколько точек и страница стала заполнена не на 10% а на 10.1%) мы пометим ее как грязную и во время следующей синхронизации (допустим по таймеру) снова будем ее записывать.
Ну и второй аспект — нам может не хватать RAM для хранения данных. В принципе, можно хранить временные ряды в Redis, я даже на гитхабе что-то похожее видел. Но это подойдет только для случая когда у пользователя небольшой поток или им нужно хранить только оперативные данные за последний день/час.
JFYI, табличку составляли авторы DalmatinerDB. И они ничего не тестировали, а взяли свободно доступные данные из интернета (в случае Akumuli — скорость записи на моем ультрабуке).
В статье есть ссылка на benchmark. Вставку в sqlite я не тестировал, невозможно заранее сравнить со всем на свете. Просадка производительности для insert это просто educated guess, количество уровней b-tree в sqlite табличке увеличится до определенного уровня и все станет медленнее. 400 млн строк у вас в одной таблице? А какая схема?
Я еще раз повторю, что CH это не то же самое, с временными рядами он работать может (как и сотни других продуктов), на этом сходство заканчивается. Я действительно не понимаю, при чем тут CH, вы его когда-нибудь использовали для мониторинга? А kdb+?
Я использую t2.micro и EBS volume для мониторинга небольшой системы. Нужно иметь ввиду, что для обработки большого количества точек/сек нужно иметь нормальный процессор или много ядер, если у вас очень много уникальных метрик нужно много памяти (примерно 16-24КБ на метрику). Modern hardware = оптимизация под SSD/NVMe, параллельная запись/чтение и все такое.
Получилось малость пассивно-агрессивно, извиняюсь, но мой поинт был в том, что это разные продукты, ниши у них абсолютно разные, с тем же успехом можно было сравнивать Akumuli с MySQL, я просто понятия не имею что на это ответить.
ClickHouse это тоже аналитическая БД, его имеет смысл с Vertica сравнивать, это не TSDB, там есть GraphiteMergeTree для метрик, но чтобы с этим разобраться нужно изучать исходники (оно не описано в документации, по крайней мере раньше не было) и судя по всему, создавалось для внутренних нужд. Данные в CH нужно писать батчами, нельзя просто открыть сокет и начать записывать туда данные, все будет слишком медленно. Нужен какой-то сервер, который будет получать данные мониторинга от коллекторов, батчить их и вставлять. Для этого есть graphite-clickhouse и graphouse. Ни одна из этих связок не поддерживат теги.
Сравнивать Akumuli имеет смысл с другими TSDB — OpenTSDB, Graphite, InfluxDB и тд. По сравнению с ними у меня есть преимущество в производительности и простоте операций. Akumuli может работать автономно, не нуждается в администрировании. У меня есть пользователи, которые выбрали Akumuli именно благодаря этому. Им нужна была БД, которая может работать на очень слабом железе, мониторить кучу контроллеров и не нуждаться в администрировании. У меня самого есть кое какой проект, который мониторится с помощью Akumuli на t2.micro инстансе.
Вводные статьи есть в wiki проекта. Там есть описание языка запросов и формата входных данных — github.com/akumuli/Akumuli/wiki Эти статьи немного устарели, т.к. там нет описания того как работать с Docker контейнером, но в Docker Hub эта информация есть — hub.docker.com/r/akumuli/akumuli. Разница в том, что Docker контейнер сам создает конфигурацию и файлы БД (если они отсутствуют). Но даже без Docker там с точки зрения операций все очень не трудоемко.
Еще там есть описание языка запросов и форматов входных данных, но записывать данные можно через какой-нибудь коллектор (нужно только использовать протокол OpenTSDB) и читать данные с помощью плагина для графаны. Думаю это то что нужно большинству людей.
Тут был комментарий про то что chronix лучше, я его случайно отклонил пытаясь ответить. Так вот, эти ребята ни в одной статье не показали нормальных результатов тестирования производительности, так что я сомневаюсь в том, насколько там все хорошо в реальности. Ну и еще они хранят данные с потерями, поэтому в разделе evaluation у них все так хорошо (там фигурирует скорость чтения и размер на диске ЕМНИП). Естественно они всех рвут по этим параметрам, т.к. сравнивают БД, которой нужно прочитать 1МБ с БД, которой нужно прочитать 10МБ. Проблема в том, что вам может хотеться хранить данные с полной точностью.
Ну и второй аспект — нам может не хватать RAM для хранения данных. В принципе, можно хранить временные ряды в Redis, я даже на гитхабе что-то похожее видел. Но это подойдет только для случая когда у пользователя небольшой поток или им нужно хранить только оперативные данные за последний день/час.
ClickHouse это тоже аналитическая БД, его имеет смысл с Vertica сравнивать, это не TSDB, там есть GraphiteMergeTree для метрик, но чтобы с этим разобраться нужно изучать исходники (оно не описано в документации, по крайней мере раньше не было) и судя по всему, создавалось для внутренних нужд. Данные в CH нужно писать батчами, нельзя просто открыть сокет и начать записывать туда данные, все будет слишком медленно. Нужен какой-то сервер, который будет получать данные мониторинга от коллекторов, батчить их и вставлять. Для этого есть graphite-clickhouse и graphouse. Ни одна из этих связок не поддерживат теги.
Сравнивать Akumuli имеет смысл с другими TSDB — OpenTSDB, Graphite, InfluxDB и тд. По сравнению с ними у меня есть преимущество в производительности и простоте операций. Akumuli может работать автономно, не нуждается в администрировании. У меня есть пользователи, которые выбрали Akumuli именно благодаря этому. Им нужна была БД, которая может работать на очень слабом железе, мониторить кучу контроллеров и не нуждаться в администрировании. У меня самого есть кое какой проект, который мониторится с помощью Akumuli на t2.micro инстансе.
Еще там есть описание языка запросов и форматов входных данных, но записывать данные можно через какой-нибудь коллектор (нужно только использовать протокол OpenTSDB) и читать данные с помощью плагина для графаны. Думаю это то что нужно большинству людей.