https://opennet.ru/openforum/vsluhforumID3/115726.html Представлен (https://blog.timescale.com/1-0-enterprise-production-ready-time-series-database-open-source-d32395a10cbf) первый стабильный выпуск СУБД TimescaleDB (https://ww.timescale.com), пригодный для широкого использования. СУБД TimescaleDB ориентирована на хранение и обработку данных в форме временного ряда (срезы значений параметров через заданные промежутки времени, запись образует время и набор соответствующих этому времени значений), свойственные для таких применений как системы мониторинга, торговые платформы, опросы состояния датчиков, сбор метрик. Проект TimescaleDB реализован в виде расширения к PostgreSQL и распространяется (https://github.com/timescale/timescaledb) под лицензией Apache 2.0.<br><br><br><br>СУБД позволяет применять полноценные SQL-запросы для анализа накопленных данных, сочетая удобство работы, свойственное реляционным СУБД, с масштабированием и возможностями, присущими специализированным NoSQL-системам. Ключевой особенностью TimescaleDB является поддержка автоматического секционирования https://opennet.ru/openforum/vsluhforumID3/115726.html#27 Fri, 09 Nov 2018 15:26:57 GMT ФС со сжатием поможет.<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#26 Tue, 06 Nov 2018 17:30:15 GMT Это убивает SSD.<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#25 Tue, 06 Nov 2018 11:45:22 GMT Вряд ли... Тут даже с clickhouse может быть конкуренция только по доступной сложности запросов.<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#24 Tue, 06 Nov 2018 11:29:39 GMT Не, там всё ж есть особенности, которые помешают сделать запрос вида: "какой пиковый LA был у сервера frontend1 месяца три назад?". Ну то есть, можно при создании rrd это поправить, но всё же геморрой там бОльший, чем взять соответсвующие средства.<br>Впрочем, для случая, когда число метрик*серверов меньше пары тысяч - вполне сойдёт.<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#23 Tue, 06 Nov 2018 09:54:04 GMT Нет - наоборот размер БД будет меньше<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#22 Tue, 06 Nov 2018 07:27:41 GMT Правильно ли я понимаю, что это выльется только в бОльший объем данных хранимых на диске?<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#21 Mon, 05 Nov 2018 18:09:38 GMT Надо понимать, что это postgresql, и оптимизации хранения нет.<br>Что это значит? Значит 24 байта оверхеда на каждую метрику + полная стоимость имени метрики (длинна имени метрики), таймстампа (8 байт), значения метрики (8байт), и прочее, и без какой либо компрессии.<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#20 Mon, 05 Nov 2018 13:13:13 GMT убийца InfluxDB<br> https://opennet.ru/openforum/vsluhforumID3/115726.html#19 Mon, 05 Nov 2018 11:19:34 GMT Это признак современности и, вообще, крутизны.<br>