В конце минувшего года состоялся очередной прямой эфир российского PostgreSQL-сообщества #RuPostgres, в рамках которого его сооснователь Николай Самохвалов поговорил с техническим директором «Фланта» Дмитрием Столяровым про эту СУБД в контексте Kubernetes.
Мы публикуем стенограмму основной части этой дискуссии, а на YouTube-канале сообщества опубликована полная видеозапись:Читать полностью »
Привет! В четверг, 23 января, пройдёт наш первый митап про Apache Kafka. Будем говорить об интеграции, source коннекторах и запуске масштабируемых приложений в Kubernetes. С докладами выступят инженеры Booking.com, Confluent и Авито.
Встречаемся в 18:00. Регистрируйтесь сами и приглашайте коллег. Под катом — анонсы выступлений, ссылка на регистрацию и видеотрансляцию митапа.
Очереди сообщений используются для выполнения: отложенных операций, взаимодействия сервисов между собой, «batch processing» и т.д. Для организации подобных очередей существуют специализированные решения, такие как: RabbitMQ, ActiveMQ, ZeroMQ и тд, но часто бывает, что в них нет большой необходимости, а их установка и поддержка причинит больше боли и страданий, чем принесет пользы. Допустим, у вас есть сервис, при регистрации в котором пользователю отправляется email для подтверждения, и, если вы используете Postgres, то вам повезло — в Postgres, почти из коробки, есть расширение PgQ, которое сделает всю грязную работу за вас.
В этой статье я расскажу об организации очередей сообщений (задач) в PostgreSQL с использованием расширения PgQ. Эта статья будет полезна, если вы еще не использовали PgQ или используете самописные очереди поверх Postgres.
Зачем вообще нужен PgQ, если можно просто создать табличку и записывать туда задачи? Казалось бы, можно, но вам придется учесть паралельный доступ к задачам, возможные ошибки (что будет, если процесс обрабатывающий задачу, упадет?), а также производительность (PgQ очень быстрый, а самописные решения, как правило, нет, особенно если транзакция в базе не закрывается во время всего выполнения задачи), но самое главное, почему на мой взгляд надо использовать PgQ, это то, что PgQ уже написан и работает, а самописное решение еще надо написать.
Но у PgQ есть один огромный минус — отсутствие документации, этот недостаток я и пытаюсь компенсировать этой статьей.
Читать полностью »
Привет!
В условиях многообразия распределенных систем, наличие выверенной информации в целевом хранилище является важным критерием непротиворечивости данных.
На этот счет существует немало подходов и методик, а мы остановимся на реконсиляции, теоретические аспекты которой были затронуты вот в этой статье. Предлагаю рассмотреть практическую реализацию данной системы, масштабируемой и адаптированной под большой объем данных.
Как реализовать этот кейс на старом-добром Python — читаем под катом! Поехали!
Немного SQL-магии под катом: математика, рекурсия, псевдографика.
Вспоминаем под Новый год формулу угла между векторами:
Читать полностью »
Довольно типичная схема при разработке системы, когда основная логика обработки сосредоточена в приложении (в нашем случае Erlang), а данные для работы этого приложения (настройки, профили пользователей и т. д.) в базе данных (PostgreSQL). Приложение Erlang кэширует настройки в ETS для ускорения обработки и снижения нагрузки на БД путём отказа от постоянных запросов. При этом изменение этих данных происходит через отдельный (возможно, внешний) сервис.
В таких ситуациях встаёт задача поддержания закэшированных данных в актуальном состоянии. Есть разные подходы для решения этой задачи. Один из них — это логическая репликация PostgreSQL. О нем и пойдёт речь ниже.
Так уж вышло, что на момент постановки задачи я не обладал достаточной степенью опытности, чтобы разработать и запустить это решение в одиночку. И тогда я начал гуглить.
Не знаю, в чем загвоздка, но уже в который раз я сталкиваюсь с тем, что даже если делать все пошагово как в туториале, подготовить такой же enviroment как у автора, то все равно никогда ничего не работает. Понятия не имею, в чем тут дело, но когда я столкнулся с этим в очередной раз, я решил — а напишу-ка я свой туториал, когда все получится. Тот, который точно будет работать.
VACUUM может «зачистить» из таблицы в PostgreSQL только то, что никто не может увидеть — то есть нет ни одного активного запроса, стартовавшего раньше, чем эти записи были изменены.
А если такой неприятный тип (продолжительная OLAP-нагрузка на OLTP-базе) все же есть? Как почистить активно меняющуюся таблицу в окружении длинных запросов и не наступить на грабли?
СУБД Postgres Pro Standard придумана для того, чтобы доставлять наши разработки пользователям быстрее, чем мы можем это сделать через PostgreSQL. Те фичи, которые еще не вошли в PostgreSQL, но находятся на твердом пути туда, мы включаем в Postgres Pro Standard. Также в Postgres Pro Standard входят некоторые расширения, которые востребованы нашими клиентами, но отсутствуют в обычной поставке PostgreSQL.
Иногда бывают исключения, когда в Postgres Pro Standard по просьбам юзеров и для их удовлетворения включаются и менее тривиальные фичи, которым по-хорошему место только в Postgres Pro Enterprise. В частности, это PTRACK, о нём ниже.
Не все, но изрядная доля дополнительных расширений и утилит, входящих в Standard, разработана в Postgres Professional. Все патчи Postgres Pro придуманы и реализованы нашими силами. Начнем с улучшений, потребовавших вмешательства в ядро СУБД.
Читать полностью »
Когда мы перестаем контролировать размер таблицы — обслуживание и обеспечение доступности данных становится нетривиальной задачей. Я с такой проблемой столкнулся уже в продакшне, данных с каждым днем становится больше, таблица не влезает в память, сервера отвечают долго, но решение было найдено.
Привет! Меня зовут Алмаз и сейчас я хочу поделиться методом, который помог мне реализовать секционирование.
Читать полностью »
