Доклад интересный. Ратвин Константин постарался быть объективным, по мере сил в существующей ситуации. Думаю, что на этот доклад можно положиться при выборе управлялки.
Странно, что в статье не упоминается 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.
И запрос select * from t1 начинает возвращать столбцы в другом порядке - так, как select c, a, b from t1. Обратная совместимость потеряна, приложение сломано.
Ни одна нормальная РСУБД не гарантирует порядок полей и порядок строк при возвращении. Если программист надеется на это - то он сам себе злобный буратино, не знающий ничего про реляционную алгебру.
Что бы удалить миллиард строк, надо записать миллиард строк в индекс, а потом удалить этот же миллиард строк из индекса. А кроме того, ещё и индексы к таблице есть. И, по-хорошему, там тоже надо отдельную сущность инспектора на каждый индекс.
И, если я не ошибаюсь, в СУБД, которые работают на основе блокировок, всё это так и выглядит - есть структура в памяти, в которой учитываются блокировки строк, страниц, экстентов, таблиц, индексов, объектов и базы данных.
И что если стоит, но поступила такая информация - затирать ли предыдущую? Не записывать? Что ж вы меня спрашиваете? Спросите лучше архитектора вашей модели данных.
Собственно, якорное моделирование данных - это 6NF, судя по статье в википедии. Поэтому нет никакого противоречия между РСУБД и якорными БД. Данные якорной модели хранятся в нескольких таблицах в РСУБД по факту.
Вот статья про увлажнение под давлением. Выглядит компактнее и возможно, дешевле.
И слизи нет.
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 при запуске чем не угодил?
Работает во всех деривиативах хрома.
В свое время понравился Rammbock.
Малобюджетный, да. Но довольно оригинальный.
https://github.com/postgrespro/pg_pathman
удобнее и функциональнее pg_partman, но устанавливается без танцев с бубном только на семейство СУБД PGPro.
Ни одна нормальная РСУБД не гарантирует порядок полей и порядок строк при возвращении. Если программист надеется на это - то он сам себе злобный буратино, не знающий ничего про реляционную алгебру.
Уже было.
Питер Уоттс «Ложная слепота»
Что бы удалить миллиард строк, надо записать миллиард строк в индекс, а потом удалить этот же миллиард строк из индекса.
А кроме того, ещё и индексы к таблице есть. И, по-хорошему, там тоже надо отдельную сущность инспектора на каждый индекс.
И, если я не ошибаюсь, в СУБД, которые работают на основе блокировок, всё это так и выглядит - есть структура в памяти, в которой учитываются блокировки строк, страниц, экстентов, таблиц, индексов, объектов и базы данных.
Технически, если в вашем хранилище нет ничего чувствительного, можно ограничиться github/gitlab etc.
Всё становится ещё проще.
Вроде Another World тоже
Собственно, якорное моделирование данных - это 6NF, судя по статье в википедии. Поэтому нет никакого противоречия между РСУБД и якорными БД. Данные якорной модели хранятся в нескольких таблицах в РСУБД по факту.