Представьте знакомую ситуацию: утро понедельника, задачи сыпятся одна за другой. Перед вами задача срочно развернуть новый сервис на базе Postgres Pro. Или, возможно, в эти выходные вы обновили железо своего сервера базы данных, увеличили количество CPU и объём RAM. Расскажем, как быстро привести СУБД в состояние, оптимально подходящее новому оборудованию и текущим нагрузкам.
Привет, Хабр! Меня зовут Николай Литковец, я инженер-разработчик в СберТехе, развиваю СУБД Pangolin — это реляционная СУБД, целевая в Сбере и не только. До недавнего времени у нас было два типа обновлений СУБД — минорное и мажорное. Минорное обновление — быстро и сравнительно просто, мажорное — долго, муторно, со значительными затратами ресурсов сервера. Мы стали думать, можем ли мы где-то обойтись без перехода на мажорные версии? Нашли сценарий, где это было возможным и через время у нас появилось минорно-мажорное обновление, которое теперь экономит нам силы и время. В этой статье расскажу про создание инструмента, который позволил нам устроить эту реформу, как мы его делали и обходили риски и что нам это дало.
Всем привет! Недавно закончился PGConf, где большая часть докладов была посвящена новым фичам PostgreSQL Pro, и лишь немногие касались ванильной версии. В прометей Лаб я влился с октября 2024 года и начал развивать сервис администрирования баз данных. Сегодня я хочу поделиться нашим подходом к мониторингу, который не требует лицензий, при этом экономит время и нервы.
Если вы DBA, то вы наверняка сталкивались с задачей мониторинга разных инстансов баз данных — PostgreSQL, MSSQL, MariaDB, Oracle или что-то из NoSQL — на разных ОС, от bare metal до PaaS. Настройка мониторинга в таких условиях может занять недели, а ошибки в алертинге приводят к простоям.
Зачастую, в больших компаниях есть типовой мониториг который, мягко говоря, сложно кастомизировать, а попытки его доработать, в лучшем случае, вылились в пару месяцев переписки и доп. согласования с безами.. В худшем — вы разочаровались в жизни, смирились и продолжаете кушать кактус заводить заявки.
Я тоже через это проходил, поэтому в Prometey Lab мы сфокусировались на переносимом, масштабируемом, k8s ready решении, на типовых компонентах которое можно оперативно развернуть и с минимальной болью занести в разрешенный техстек. На последней демо, при наличии тех учеток в бд, весь процесс подключения нового клиента к мониторингу занимает 40 минут и поддерживает кастомизацию под любые нужды.
В этой статье я расскажу, как мы этого добились, поделюсь нашим стеком, примерами конфигураций и планами на будущее. Если вы сталкивались с подобными задачами, возможно эта статья натолкнет вас на мысли как «расшить» направление мониторинга и сократить время реакции на инциденты.
В этой статье я подготовил для вас прототип CRUD-приложения, которое использует файберы и неблокирующие(асинхронные) возможности драйвера PostreSQL. Вместе они дают любопытные результаты по производительности и потреблению памяти.
Значения восьми параметров конфигурации мастера (primary, ведущего сервера PostgreSQL) сохраняются в управляющих файлах и изменения их значений передаются через журнал (WAL) на реплики. Если реплика открыта для запросов (hot_standby=on), то значения пяти числовых параметров на реплике должны быть не меньше, чем на мастере, иначе процесс startup прекратит накат (replay) журнальных записей. А после рестарта экземпляры реплик не запустятся. В статье рассматриваются эти параметры особенности изменения их значений.
Значения пяти числовых параметров конфигурации, сохраненных в управляющем файле кластера, можно посмотреть утилитой pg_controldata:
Привет, Хабр!
Каждая компания стремится к тому, чтобы данные были не только доступны в нужный момент, но и надежно защищены (спасибо, КЭП!). Более того, необходимость обеспечения безопасности ЗОКИИ и требований по импортозамещению ставит новые задачи в области интеграции систем и миграции данных. Один из способов разобраться с этими вызовами — репликация данных. Она помогает компаниям справляться с растущими нагрузками, обеспечивает защиту данных и облегчает миграцию между различными платформами. Однако ее успешное внедрение требует тщательной подготовки, внимательного выбора стратегии и регулярного мониторинга. Хватит слов – за дело! В этой статье мы покажем сразу несколько технических решений.
Привет, Хабр!
Сегодня поговорим про одну из тех тем, что вроде бы тривиальна, но до последней капли грязи тащит за собой внушительный пласт вопросов. Речь пойдёт про COUNT(*) и COUNT(col) в PostgreSQL.
Медленная работа базы данных высасывает ресурсы и нервы? Вы не одиноки. Но есть эксперты, способные выжать максимум из вашей инфраструктуры. Расскажем, как перфоманс инжиниринг помогает превратить «тормоза» в «ракету».
В статье рассматривается использование теста TPC-H с PostgreSQL и проблемы, связанные с запросами Q17-Q20 теста.
Введение
Вместе с PostgreSQL поставляется утилит pg_bench с "TPC-B like" тестом. Кроме этого теста были созданы тесты TPC-R для отчётов, TPC-D для OLAP, TPC-W для заказов в веб-магазине, которые не получили распространения. На основе TPC-D был создан более удачный тест TPC-H для хранилищ данных и аналитических запросов ("OLAP нагрузка"). В тесте используется 8 таблиц и 17 ограничений целостности. В TPC-H выделены номинации по размерам обрабатываемых данных от "до 100Гб" до 30-100Тб. Тест TPC-H предназначен для хранилищ данных, включает в себя 22 запроса, которые называют Q1 ... Q22.
Запросы теста TPC-H не меняют данные в таблицах, а значит, для повторных тестирований не нужно пересоздавать или вакуумировать таблицы. В тестах TPC-B, TPC-C, TPC-E запросы довольно простые. В реальных приложениях запросы более сложные, чем в этих тестах. Поэтому для тестирования того, как СУБД выполняет запросы, которые могут встретиться в реальных приложениях, можно использовать все или отдельные запросы из теста TPC-H. Для быстрого аудита производительности различных СУБД используют вариант с 1Гб данных. В этом варианте запросы выполняются быстро, не нужно много памяти под экземпляр СУБД и много места на диске. Можно найти программы или скрипты для большинства СУБД, например, для PostgreSQL, Oracle Database, MySQL. После теста TPC-H появился тест TPC-DS с 99 запросами, но он менее популярен.
Цель заключалась в создании мобильного приложения, которое бы сделало путешествие еще комфортнее для пассажиров. Приложение должно было стать связующим звеном между компанией и ее клиентами, предлагая им удобные сервисы прямо на борту теплохода. Среди ключевых функций были такие возможности, как — заказ еды и напитков, бронирование экскурсий и покупка сувениров. Также важно было обеспечить удобство для самой компании, автоматизировав процессы и снизив нагрузку на персонал.
Я уже не раз поднимал в статьях тему [не]эффективной работы с json[b] в PostgreSQL — и как его лучше превращать в выборку, и как можно «транспонировать». Сегодня же рассмотрим некоторые возможности по его генерации на стороне базы.
Привет, Хабр! Меня зовут Александр Цай, я ведущий аналитик в МТС Web Services, но на деле занимаюсь всеми вопросами, касающимися DA/DE/BI: выявлением потребностей и сбором требований, проектированием дашбордов и витрин для них, построением и развитием внутреннего хранилища, поиском источников данных, созданием сложных ETL-пайплайнов по их доставке, DQ, проведением аналитики и много чем еще.
В этом материале я расскажу про разворачивание пайплайна по стримингу данных из MongoDB в PostgreSQL с помощью Apache Flink (стримить из Kafka банально, а так заодно пощупаем документоориентированную БД). Делать это мы будем в minikube (kubernetes), а языком программирования для заданий выступит Python. Все описанное в посте выполняется на MacBook с процессором i7.
В интернете, тем более русскоязычном, нет информации о стриминге из MongoDB в Postgres с помощью Flink. Почти все материалы по Flink, которые мне попадались, сводятся к пережевыванию примера WordCount из flink-kubernetes-operator, где на запущенном поде из папки с примерами читается файл и в консоль выводится количество слов в нем. Если спускаться до использования PyFlink, то мы натыкаемся на кастомные образы с Harness SDK и Apache Beam и другие страшные слова. Знакомо?
Так вот, это не наш путь! Данное руководство будет полезно тем, кто такой же извращенец хочет пощупать Flink на родном Python и кто не планирует брать примеры, оторванные от реальности.
Давно не было обстоятельных интервью, тем более с таким корифеем отечественной СУБД‑разработки. В 2022 году в Postgres Professional перешла команда специалистов по Oracle, включая Марка Ривкина, который занял позицию руководителя отдела технического консалтинга. Вместе с командой он занялся адаптацией продуктов под требования крупных корпоративных заказчиков и доработкой функциональности Postgres Pro — в первую очередь для тех, кто планирует миграцию с проприетарных СУБД.
В интервью для Хабра Марк рассказал, с какими задачами столкнулись на старте, какие функции пришлось внедрять в первую очередь, как выстроена работа с разработкой и сообществом, и в чём сегодня Postgres Pro реально может заменить Oracle, а в чём — пока нет. Поговорили и про ИИ в администрировании, и про перспективы российских форков PostgreSQL, и даже о том, что бы он заложил в архитектуру, если бы проектировал СУБД с нуля. Приятного чтения!
Привет, Хабр!
Сегодня рассмотрим про то, что такое Partial Index в PostgreSQL и как он может ускорить редкие выборки, сэкономить дисковое пространство и облегчить жизнь планировщику запросов.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Сегодняшней статьей с простым использованием агрегирующих функций завершаем цикл. В итоге, PostgreSQL показал себя как очень удобное средство для решения разных алгоритмических задач, лишь несколько раз заставив нас изобретать совсем уж нетипичные подходы к написанию SQL-запросов.
Создаем две базы данных Firebird и PostgreSQL в кодировке UTF8.
Для сравнения выберем следующие типы данных:
В статье визуализируется структура индекса и показывается, как меняется структура индекса типа btree в PostgreSQL. Это полезно для понимания, как выглядят индексы btree. Также рассматривается FILLFACTOR и пример исследования структуры индекса в целях определения, как перераспределяются индексные записи при включении в структуру индекса новых блоков (страниц). Создадим простую таблицу, индекс, вставим три строки:
Предлагаю вашему вниманию немного дополненный доклад, который я делал на конференции PGConf.СПб 2024. В нем я рассказываю о том, как появились первые реляционные системы, как возник и всех победил язык SQL.
Хочу поделиться с сообществом свой наработкой по мониторингу бэкапов PostgreSQL.
Для того чтобы делать сами бэкапы, используется сторонний open source инструмент pg_probackup (разработка компании Postgres Professional).
Этот инструмент умеет делать инкрементные бэкапы, а также автоматизирует сопутствующие процессы, такие как, сжатие данных, merge, удаление старых бэкапов и wal-файлов.
Остается проблема мониторинга. Предположим, мы настроили pg_probackup и он трудится упорно, вызываемый регулярно через cron.
Как мы узнаем, о том, что что-то сломалось?
Для решения этой проблемы был написан небольшой экспортер метрик pg_probackup для Prometheus.
Для тех, кто устал от «зоопарка» решений по созданию отказоустойчивых кластеров, расскажем, как добиться нужной функциональности одним решением. BiHA позволяет данным «выжить», даже если один из ЦОДов был физически уничтожен. Как же мы этого добились?
