Наверное потому, что бинарники на компьютере злоумышленника, однако ссылки на код модулей в статье присутствуют. А на микротике просто скрипты исполняются.
Посмотрел статистику. У нас используется 7% одного ядра CPU (Xeon E-2274G), 300мб оперативки и еще 2.8Гб cache памяти. На диске база занимает 36Гб. Статистика базы — порядка 40 точек в секунду, на чтение — иногда заходят коллеги за статистикой, можно считать — один запрос на чтение в секунду. У нас всего 30 рядов, собираем раз в 5 минут. Количество точек во всех метриках разное, суммарно — около миллиарда.
В остальном сложно подсчитать — при вставке ведь мы добавляем 8 байт на число (double или int64), а labels у нас неизменные и мы просто к ним привязываемся. Этот момент требует уточнения.
у нас несколько геораспределённых реплик, которые мы мониторим и, в случае чего, мы на них переключаемся. С другой стороны, если мастер баз не доступен, то запись не происходит и данные копятся на источнике. Как только появится возможность произвести запись — данные доедут в базу. В дальнейшем мы хотим уйти от ручного failover на автоматику, решение пока что готовим.
Выглядит классно. Однозначно в закладки. Жаль, что заббикс еще очень долго догонять по удобству okmeter. А еще огорчает список поддерживаемых версий Postgresql. Но есть и киллерфичи — я про раздувшиеся таблицы из коробки.
Про объемы — сложно сравнить сколько бы такое весило в других базах, но в clickhouse данные занимают обычно от десятка терабайт. Есть инстансы поменьше — но там обычно просто репликация настроена, не кластер c шардами.
Дык Continuous Aggregates TimesacleDB и она как раз Materialized View. В тч real-time
Похоже стоит ответить развёрнетее. Вы частично правы — это было «не знаю», но сугубо по одному из пунктов.
Итак, мы используем все инструменты — Postgresql, Clickhouse и TimescaleDB. Да, я знаю, что это плагин к Postgresql, но он настолько не вписывается в ванильный postgresql, что даже процедура дампа и загрузки дампа у него своя.
Так вот если у вас в проекте есть postgresql и вам нужны временные ряды — то timescaledb отличное решение — все будет в одной базе, связка Postgresql + Clickhouse проиграет timescaledb просто потому, что там будет сетевое взаимодействие. Плюс удобство и сила PL/pgSQL. Однако кому интересны такие сетапы?
Когда мы готовимся у себя в команде к внедрению Clickhouse — то подразумеваем сразу кластер с шардирование и репликацией, с множеством узлов. Ну и соответствующие объемы данных. И вот тут мы как раз подходим к тому, что пока у нас не было возможности опробовать Distributed Hypertables, так как появились они позднее. Это как раз и есть моё «не знаю».
Ну и опять хочется отметить, всё зависит от проекта. Например, в Clickhouse есть интересные вещи, за которые я его люблю — это Kafka Engine, когда Clickhouse выступает как консьюмер. Соответственно в проекте, где уже есть Kafka как шина данных — я предложу использовать Clickhouse. Так же нельзя забывать и про Materialized View в Clickhouse, которые асинхонно преобразует сырые данные в готовые преагрегаты. Мне очень нравится такой подход.
Каждый найдёт своё. Очень многое зависит от вашего сетапа, экспертизы, используемых решений, хранимых данных.
Продукты очень похожие, однако distributed timescaledb появился позже и я его пока не трогал. Пока из видимых плюсов — clickhouse проще обновлять, его можно подцепить к kafka. Но это, опять же, исключительно исходя из нашего опыта испольования, когда в вашем стеке есть kafka.
UPD Если раскроете чуть больше данных по проекту — то можно будет уже что-то посоветоват.
Так говорили и про Ryzen инстансы, но что-то на них быстрее некоторые виды приложений работают, нежели на Xeon. Плюс, тут рассматриваются m-инстансы, а не t.
Учитывая количество плюсов к комментарию, хабру очень интересно что там с кошкой. Будет ли расширенная версия эксперимента с несколькими типами колбасы?
>… блокировки.
Какие блокировки? Там уровень блокировки такой же, как и у SELECT. Как раз говорится о том, что блокировок нет и результат может быть не точен. Однако он всё равно будет точнее, чем селект через pg_statistic, ибо статистика может запаздывать, так как автовакуум может задержать на другой таблице/быть отключен/не успевать.
Более чем согласен — диски Zookeeper использует для хранения итогов выборов, ключей и значений базы, своих снапшотов и бинарных логов. Причём до недавнего времени для удаления снапшотов требовался отдельный внешний скрипт.
Полностью согласен. Все городят то, что им удобно. Но ведь это и хорошо — мы видим разные подходы и совершенствуем свой. Битнами вообще красавцы, хотя и у них есть спорные моменты, в основном в образах.
Давайте разбираться. Какие бинарники вы хотите увидеть? Которые Микротики взламывают или которые на микротиках запускаются?
По поводу ссылок да, я ошибся, в статье по ссылке нет исходников, а только разбор алгоритмов.
ФБР - силовое ведомство, в то время как RT Solar таковым не является. Вы сравниваете несравнимое.
Наверное потому, что бинарники на компьютере злоумышленника, однако ссылки на код модулей в статье присутствуют. А на микротике просто скрипты исполняются.
В остальном сложно подсчитать — при вставке ведь мы добавляем 8 байт на число (double или int64), а labels у нас неизменные и мы просто к ним привязываемся. Этот момент требует уточнения.
Я поэтому и сказал, что продукты похожи.
Итак, мы используем все инструменты — Postgresql, Clickhouse и TimescaleDB. Да, я знаю, что это плагин к Postgresql, но он настолько не вписывается в ванильный postgresql, что даже процедура дампа и загрузки дампа у него своя.
Так вот если у вас в проекте есть postgresql и вам нужны временные ряды — то timescaledb отличное решение — все будет в одной базе, связка Postgresql + Clickhouse проиграет timescaledb просто потому, что там будет сетевое взаимодействие. Плюс удобство и сила PL/pgSQL. Однако кому интересны такие сетапы?
Когда мы готовимся у себя в команде к внедрению Clickhouse — то подразумеваем сразу кластер с шардирование и репликацией, с множеством узлов. Ну и соответствующие объемы данных. И вот тут мы как раз подходим к тому, что пока у нас не было возможности опробовать Distributed Hypertables, так как появились они позднее. Это как раз и есть моё «не знаю».
Ну и опять хочется отметить, всё зависит от проекта. Например, в Clickhouse есть интересные вещи, за которые я его люблю — это Kafka Engine, когда Clickhouse выступает как консьюмер. Соответственно в проекте, где уже есть Kafka как шина данных — я предложу использовать Clickhouse. Так же нельзя забывать и про Materialized View в Clickhouse, которые асинхонно преобразует сырые данные в готовые преагрегаты. Мне очень нравится такой подход.
Продукты очень похожие, однако distributed timescaledb появился позже и я его пока не трогал. Пока из видимых плюсов — clickhouse проще обновлять, его можно подцепить к kafka. Но это, опять же, исключительно исходя из нашего опыта испольования, когда в вашем стеке есть kafka.
UPD Если раскроете чуть больше данных по проекту — то можно будет уже что-то посоветоват.
Какие блокировки? Там уровень блокировки такой же, как и у SELECT. Как раз говорится о том, что блокировок нет и результат может быть не точен. Однако он всё равно будет точнее, чем селект через pg_statistic, ибо статистика может запаздывать, так как автовакуум может задержать на другой таблице/быть отключен/не успевать.
Я бы сыграл с instagib