PgConf.Russia 2020

Patroni и Stolon - два наиболее известных и продвинутых решения для оркестрации PostgreSQL и обеспечения выскокой доступности (автофейловера) кластеров Leader-Followers конфигурации. Однако инженеры, переходящие со старых проверенных решений (Corosync&Pacemaker) и встроенных из других СУБД, сталкиваются со сложностями в инсталляции этих инструментов и непониманием ролей каждого из компонентов. В данном мастер-классе будет рассмотрен типичный процесс инсталляции кластеров Patroni и Stolon на виртуальных машинах (не в контейнерах), а также разобрано поведение этих кластеров при различных фейлах в инфраструктуре. Весь процесс будет демонстрироваться на трёх виртальных машинах под управлением vagrant с использованием предварительно подготовленных образов. При желании слушатель может следовать за процессом, предварительно подготовив своё окружение.

Недавно мне пришлось поработать над проектом, где для запросов к бэкенду на .NET Core использовали GraphQl, о чём потом пожалели. Дело в том, что GraphQl-запрос представляет собой объект с динамическим набором полей и иерархией любой вложенности. Обрабатывать такие объекты на языке со статической и сильной типизацией, да ещё и через ORM, как это предлагают библиотечные решения – очень неудобно. И тогда мне пришла идея использовать plv8 и разбирать запросы в формате GraphQl прямо на стороне БД. За пару часов я написал работающий прототип, реализующий функционал, который разрабатывали более месяца! Затем было сделано несколько усовершенствований, всё это я собираюсь показать. Тем, кто собирается в своих проектах использовать GraphQl, а не REST, информация из данного доклада может особенно пригодиться и возможно поможет сэкономить уйму времени.

Мы хотим поделиться структурой и результатами теста (производительности и не только), в котором участвовали PostgreSQL/Citus и MongoDB для данных нашей компании. Это был весьма увлекательный процесс с неожиданными поворотами и неоднозначным результатом.

Postgres has always had strong support for relational storage. However, there are many cases where relational storage is either inefficient or overly restrictive. This talk shows the many ways that Postgres has expanded to support non-relational storage, specifically the ability to store and index multiple values, even unrelated ones, in a single database field. Such storage allows for greater efficiency and access simplicity, and can also avoid the negatives of entity-attribute-value (eav) storage. The talk will cover many examples of multiple-value-per-field storage, including arrays, range types, geometry, full text search, xml, json, and records.