Жаль, что создатели Gleam по пути к статической типизации выкинули действительно интересные фишки Erlang:
паттерн матчинг в аргументах функции (перезагрузка функций)
send/! и receive
Последнее особенно обидно, так как возможности Beam как раз заточены на интеркоммуникацию легковесных функций. Конечно, решается, но ценой перехода на программирование на эрланге.
Вопрос дилетанта, возможно, что даже подобное реализовали или пытались.
А почему бы не разделить Postgresql на две нормальные СУБД - потоковую (которая WAL) и реляционную (которая кеш к потоковой)?
Выделить в отдельный инстанс pg_wal (слушатель валов), слушающий сеть, сокет, да хоть чёрта лысого. Который можно запустить как вместе с кешем, так и на отдельном сервере. И отдать ему всю работу по управлению сегментами валов.
Преимущества такого подхода:
гибкий подход. Один сервер - много слушателей валов, много серверов - один слушатель валов,
разнесение профиля дисковой нагрузки уже не на диски, а на серверы. Слушатель валов можно вынести на отдельный дисковый массив с низким латенси, и к нему подключить с десяток медленных бакендов, и все будут в выигрыше.
синхронная/асинхронная репликация между слушателями валов, резервное копирование, логическая репликация, фильтрация сегментов с разными правами для разных слушателей, как сетевых, так и ресурс-менеджеров, вплоть до того, что проигрываются только записи, тех ресурс-менеджеров которые есть в данной инсталляции при восстановлении или репликации.
ускорение восстановления - нет необходимости читать файлы мелкие, можно сразу запросить у слушателя валов пачку валов, размером с буфер в памяти, а их уже распаковать и проигрывать,
нет ограничения на размер сегмента в 16Мб. Нужен пайлоад в гиг - вот тебе одна запись в вале,
независимость ресурс-менеджеров и относительно лёгкое их создание/изменение. Например, как насчёт добавление паркетного движка хранения, :) вал тут перестаёт быть ограничением.
синхронная/асинхронное подтверждение записи валов. Вплоть до отправки слушателем подтверждения последнего записанного сегмента раз в секунду, к примеру. Своего рода обратный heartbeat серверу: "я записал все сегменты до вот этого LSN".
возможность использования слушателем валов ФС с последовательной записью, минуя page cache.
асинхронный приём валов от разных ресурс-менеджеров с последующей сортировкой и упорядочиванием перед записью.
хранение единого контекста для сжатия, его сохранение между перезагрузками.
привязка отправки валов к выделенному для этого сетевому устройству, что бы разделить трафик клиентов, приходящими за данными и служебного трафика для слушателя валов.
Ну, в случае сетевой недоступности слушателя валов, сам бакенд переходит в РО, с отдачей инфы из текущего замороженного снапшота, отвергая запросы на изменение и фоновые системные процессы.
В целом AWX интересный продукт, но сильной потребности в моей среде в нём нет, и имеется достаточный опыт работы с голым Ansible, плюс в скором времени первый ждут определённые реворки в силу монолитности проекта, поэтому может быть в будущем получится раскрыть эту тему и с ним.
Предлагаю глянуть SemaphoreUI Дениса Гукова. Настраивается на порядок проще AWX (так как всего один бинарник), всё необходимое там присутствует.
Не хватает f-клавиш в основном слое. Дополнительный модификатор только усложняет жизнь. В этом плане Кайнезис имеет преимущество. Ну и монстры типа дактила 6 на 7, емнип.
Доклад интересный. Ратвин Константин постарался быть объективным, по мере сил в существующей ситуации. Думаю, что на этот доклад можно положиться при выборе управлялки.
Странно, что в статье не упоминается PosgresPro Enterprize Manager, как одно из решений доступных на российском рынке. Которое к тому же бесплатно, для владельцев лицензии БД PostgresPro.
Детский лепет какой-то... Пять дней искать ежечасную задачу в основной бд, хотя аналитическая система имеет отдельную бд. Логи только на второй день начал смотреть...
В случае задачи сбора flow в БД, postgresql работает хорошо только на небольших масштабах. postgresql больше заточен под OLTP и слабо подходит для аналитики, особенно, если данные в таблицу пишутся довольно интенсивно. Можно применять разные трюки, например, семплирование данных, партиционирование таблиц. Можно использовать расширение TimescaleDB, в том числе с шардированием на удалённые серверы БД. Но всё равно самая простая стратегия увеличения производительности - это вертикальное масштабирование.
В отличии от postgresql, clickhouse - это самое оно для аналитики: хранение данных в колоночном формате позволяет очень сильно сжимать данные. Крайне радикально. Миллионы монотонно увеличивающихся значений может уместиться в несколько килобайт. А когда оптимизация не помогает, парты сжимаются архиватором, что ускоряет чтение с диска. Агрегация по полю не требует вычитывания всей записи, а только нужного поля. Отдельно можно сказать про функционал вьюшек - материализованных представлений, которые обновляются в момент поступления данных в таблицу. Например, таким образом можно сделать семплирование в несколько диапазонов (5 минут, час) и дешево хранить их годами. Предагрегацию и т.п. Также легко реализуется TTL жизни записи (а дальше либо удаление, либо вынос на холод). При этом всё происходит самим движком БД, без участия приложения. Ещё можно упомянуть про кластеризацию CH - за счёт хранения данных в партах весьма элегантно реализуется мультимастер.
Если мне не изменяет память, то у меня с одного устройства за месяц набегало порядка пары миллиардов flow, которые занимали от силы пару гигабайт.
Ну да, на raspberripi связку не запустишь, и для небольшой сети штука явно избыточная: из-за ограничений CH, для неё требуется буферизация данных - например kafka. А это тоже требует ресурсов. Но зато, в случае сотен подсетей позволяет гибко масштабироваться - добавлять коллекторы, очереди в брокере, экземпляры СУБД...
Спасибо за интересную находку. Собственно, в моём случае, я искал область применения для изучения ClickHouse. Сбор flow стал хорошей возможностью пощупать эту СУБД в деле.
Костылил сборщик и анализатор на связке goflow+kafka+clickhouse+grafana ради любопытства. Трафик конторы на 300 пользователей переваривает не напрягаясь. Плюсы такого решения в том, что данные не нужно агрегировать, все флоу сохраняются в БД, также легко горизонтально масштабируется.
Перед base backup мы создаем репликационный слот и при каждом инкрементном бэкапе считываем все накопившиеся в слоте WAL‑файлы.
Это не инкрементальный бэкап, это бэкап журналов транзакций, по аналогии с BACKUP LOG MS SQL Server.
Сам инкрементный бэкап выполняется очень быстро и минимально нагружает систему — его можно делать хоть каждые 10–15 мин.
В этом-то и кроется проблема. На средненагруженном сервере поток WAL генерируется со скоростью 3-5 Гб/мин. То есть за 10-15 минут можно получить от 30 до 75 Гб при нормальной работе СУБД. В случае пропуска нескольких инкрементальных бэкапов возникает угроза остановки сервера СУБД из-за переполнения тома, на котором расположен pg_wal.
Решая эту проблему, настроив параметр max_slot_wal_keep_size, попадаем в другую: КБ при потери слота вместо инкрементального бэкапа инициирует полный бэкап в момент пиковой нагрузки на сервер. Каждые 10-15 минут. )
На ненагруженных, но толстых БД также достаточно просто попасть в такую же ситуацию: Массовая операция (copy/pg_restore/vacuum_lo/update) вызовет генерацию WAL файлов, переполнение тома или инвалидацию слота с выполнением полного бэкапа.
Поэтому, для прода такая история мало подходит. Ну либо обходиться без PITR.
Жаль, что создатели Gleam по пути к статической типизации выкинули действительно интересные фишки Erlang:
паттерн матчинг в аргументах функции (перезагрузка функций)
send/! и receive
Последнее особенно обидно, так как возможности Beam как раз заточены на интеркоммуникацию легковесных функций. Конечно, решается, но ценой перехода на программирование на эрланге.
Можно ещё сравнить с https://github.com/pulp
Вопрос дилетанта, возможно, что даже подобное реализовали или пытались.
А почему бы не разделить Postgresql на две нормальные СУБД - потоковую (которая WAL) и реляционную (которая кеш к потоковой)?
Выделить в отдельный инстанс pg_wal (слушатель валов), слушающий сеть, сокет, да хоть чёрта лысого.
Который можно запустить как вместе с кешем, так и на отдельном сервере.
И отдать ему всю работу по управлению сегментами валов.
Преимущества такого подхода:
гибкий подход. Один сервер - много слушателей валов, много серверов - один слушатель валов,
разнесение профиля дисковой нагрузки уже не на диски, а на серверы. Слушатель валов можно вынести на отдельный дисковый массив с низким латенси, и к нему подключить с десяток медленных бакендов, и все будут в выигрыше.
синхронная/асинхронная репликация между слушателями валов, резервное копирование, логическая репликация, фильтрация сегментов с разными правами для разных слушателей, как сетевых, так и ресурс-менеджеров, вплоть до того, что проигрываются только записи, тех ресурс-менеджеров которые есть в данной инсталляции при восстановлении или репликации.
ускорение восстановления - нет необходимости читать файлы мелкие, можно сразу запросить у слушателя валов пачку валов, размером с буфер в памяти, а их уже распаковать и проигрывать,
нет ограничения на размер сегмента в 16Мб. Нужен пайлоад в гиг - вот тебе одна запись в вале,
независимость ресурс-менеджеров и относительно лёгкое их создание/изменение. Например, как насчёт добавление паркетного движка хранения, :) вал тут перестаёт быть ограничением.
синхронная/асинхронное подтверждение записи валов. Вплоть до отправки слушателем подтверждения последнего записанного сегмента раз в секунду, к примеру. Своего рода обратный heartbeat серверу: "я записал все сегменты до вот этого LSN".
возможность использования слушателем валов ФС с последовательной записью, минуя page cache.
асинхронный приём валов от разных ресурс-менеджеров с последующей сортировкой и упорядочиванием перед записью.
хранение единого контекста для сжатия, его сохранение между перезагрузками.
привязка отправки валов к выделенному для этого сетевому устройству, что бы разделить трафик клиентов, приходящими за данными и служебного трафика для слушателя валов.
Ну, в случае сетевой недоступности слушателя валов, сам бакенд переходит в РО, с отдачей инфы из текущего замороженного снапшота, отвергая запросы на изменение и фоновые системные процессы.
Предлагаю глянуть SemaphoreUI Дениса Гукова.
Настраивается на порядок проще AWX (так как всего один бинарник), всё необходимое там присутствует.
DeltaChat.
Только текст, без аудио и видео звонков. Но заблокировать можно только парализовав работу электронной почты.
Не хватает f-клавиш в основном слое.
Дополнительный модификатор только усложняет жизнь.
В этом плане Кайнезис имеет преимущество. Ну и монстры типа дактила 6 на 7, емнип.
Спасибо
Судя по всему, ответов на вопросы тут не будет, как и в других статьях.
Например в https://habr.com/ru/companies/cyberprotect/articles/847810/
Вот статья про увлажнение под давлением. Выглядит компактнее и возможно, дешевле.
И слизи нет.
https://habr.com/ru/articles/706460/
Спасибо, Вадим!
Доклад интересный. Ратвин Константин постарался быть объективным, по мере сил в существующей ситуации.
Думаю, что на этот доклад можно положиться при выборе управлялки.
Могу, конечно ошибиться, но PPEM имеет большее количество установок в России, нежели Платформа, просто за счёт большего распространения PostgresPro.
Вот как раз тут то и интересно сравнить два российских конкурирующих продукта со сходным функционалом и областью применения.
Странно, что в статье не упоминается PosgresPro Enterprize Manager, как одно из решений доступных на российском рынке. Которое к тому же бесплатно, для владельцев лицензии БД PostgresPro.
Детский лепет какой-то...
Пять дней искать ежечасную задачу в основной бд, хотя аналитическая система имеет отдельную бд.
Логи только на второй день начал смотреть...
Да, верно. Но и задачи бывают разными.
В случае задачи сбора flow в БД, postgresql работает хорошо только на небольших масштабах. postgresql больше заточен под OLTP и слабо подходит для аналитики, особенно, если данные в таблицу пишутся довольно интенсивно.
Можно применять разные трюки, например, семплирование данных, партиционирование таблиц. Можно использовать расширение TimescaleDB, в том числе с шардированием на удалённые серверы БД. Но всё равно самая простая стратегия увеличения производительности - это вертикальное масштабирование.
В отличии от postgresql, clickhouse - это самое оно для аналитики: хранение данных в колоночном формате позволяет очень сильно сжимать данные. Крайне радикально. Миллионы монотонно увеличивающихся значений может уместиться в несколько килобайт. А когда оптимизация не помогает, парты сжимаются архиватором, что ускоряет чтение с диска.
Агрегация по полю не требует вычитывания всей записи, а только нужного поля.
Отдельно можно сказать про функционал вьюшек - материализованных представлений, которые обновляются в момент поступления данных в таблицу. Например, таким образом можно сделать семплирование в несколько диапазонов (5 минут, час) и дешево хранить их годами.
Предагрегацию и т.п.
Также легко реализуется TTL жизни записи (а дальше либо удаление, либо вынос на холод).
При этом всё происходит самим движком БД, без участия приложения.
Ещё можно упомянуть про кластеризацию CH - за счёт хранения данных в партах весьма элегантно реализуется мультимастер.
Если мне не изменяет память, то у меня с одного устройства за месяц набегало порядка пары миллиардов flow, которые занимали от силы пару гигабайт.
Ну да, на raspberripi связку не запустишь, и для небольшой сети штука явно избыточная: из-за ограничений CH, для неё требуется буферизация данных - например kafka. А это тоже требует ресурсов.
Но зато, в случае сотен подсетей позволяет гибко масштабироваться - добавлять коллекторы, очереди в брокере, экземпляры СУБД...
Спасибо за интересную находку.
Собственно, в моём случае, я искал область применения для изучения ClickHouse. Сбор flow стал хорошей возможностью пощупать эту СУБД в деле.
Костылил сборщик и анализатор на связке goflow+kafka+clickhouse+grafana ради любопытства.
Трафик конторы на 300 пользователей переваривает не напрягаясь.
Плюсы такого решения в том, что данные не нужно агрегировать, все флоу сохраняются в БД, также легко горизонтально масштабируется.
Хорошие новости, спасибо.
Но есть один момент:
Это не инкрементальный бэкап, это бэкап журналов транзакций, по аналогии с BACKUP LOG MS SQL Server.
В этом-то и кроется проблема. На средненагруженном сервере поток WAL генерируется со скоростью 3-5 Гб/мин. То есть за 10-15 минут можно получить от 30 до 75 Гб при нормальной работе СУБД.
В случае пропуска нескольких инкрементальных бэкапов возникает угроза остановки сервера СУБД из-за переполнения тома, на котором расположен pg_wal.
Решая эту проблему, настроив параметр max_slot_wal_keep_size, попадаем в другую: КБ при потери слота вместо инкрементального бэкапа инициирует полный бэкап в момент пиковой нагрузки на сервер.
Каждые 10-15 минут. )
На ненагруженных, но толстых БД также достаточно просто попасть в такую же ситуацию: Массовая операция (copy/pg_restore/vacuum_lo/update) вызовет генерацию WAL файлов, переполнение тома или инвалидацию слота с выполнением полного бэкапа.
Поэтому, для прода такая история мало подходит.
Ну либо обходиться без PITR.
Не знаю. Я - не они, и могу только строить предположения.
Например то, что востребованность это функции ниже плинтуса.
Никак
Ключик -proxy при запуске чем не угодил?
Работает во всех деривиативах хрома.