Комментарии 7
Спасибо за статью! Почему не используете pg_pathman для секционирования? Как именно вы кешируете данные? У вас одна БД на кластер? Рассматриваете увеличение пропускной способности на чтение?
Почему не используете pg_pathman для секционирования?Для наших задач это несколько избыточное решение.
Гораздо проще всегда иметь предсозданные секции на завтра-послезавтра. И делать это по cron в период минимальной нагрузки, как и перепаковку «стабилизировавшейся» секции, запись в которую больше не идет.
Про это будет отдельная статья.
Как именно вы кешируете данные?В памяти коллектора хранится Set, где ведется отметка отправленного в «словари».
У вас одна БД на кластер?Да. Поскольку это логи, то их потерять жалко, но не настолько критично, чтобы задействовать еще одно хранилище такого же объема.
Пока нам одного хоста хватает и запас кратный.
Рассматриваете увеличение пропускной способности на чтение?Не понял вопроса.
про pg_pathman пишу, потому что ваше решение под заголовком PG10: второй шанс мне показалось сложноватым, у них в либе всё реализовано и можно использовать с минимальными настройками, просто попробуйте на досуге, может понравится. Про запись понятно, ускорили, да и ssd тоже позволит расти в ширь. Всё равно рано или поздно крупная нагруженная БД думает стать кластером)) я сам в кластерах ноль, но было бы приятно послушать опыт "коллег по цеху")
ваше решение под заголовком PG10: второй шанс мне показалось сложноватымПросто это тоже не финальное состояние. Потом мы отказались от записи в прокси-таблицу и начали лить прямо в целевую секцию.
Прокси осталась только для словарей, чтобы лить через COPY и туда, но все-таки реагировать на unique_violation, если через Set какой-то дубль таки просочился.
крупная нагруженная БД думает стать кластеромУ нас обычно применяется шардинг. С кластерами иногда возникают нетривиальные проблемы.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Пишем в PostgreSQL на субсветовой: 1 host, 1 day, 1TB