Доклады конференции PgConf.Russia 2016

Postgres шагает по планете

Многогранность развития Postgres

Bruce Momjian
EnterpriseDB

Брюс Момжан (Bruce Momjian) - сооснователь глобальной команды разработчиков PostgreSQL и член PostgreSQL core team. Разрабатывает PostgreSQL с 1996. В настоящее время - сотрудник EnterpriseDB. Ранее работал в SRA Japan и других компаниях, поддерживших PostgreSQL. Постоянный докладчик международных конференций по open-source, автор книги PostgreSQL: Introduction and Concepts, опубликованной издательством Addison-Wesley. До начала работы с PostgreSQL Брюс работал консультантом, разработчиком приложений БД для одной из крупнейших мировых юридических фирм. Брюс имеет магистерскую степень по педагогике, преподавал Computer Science, и в настоящее время является профессором университета Drexel.

В Postgres 9.5 добавилось много нового: UPSERT, CUBE, ROLLAP, функции для работы JSONB, улучшения PostGIS. Для администраторов - Row Level Securlty, новый тип индекса, и улучшения производительности на больших серверах.

В этом докладе будет рассказано о 10 наиболее значимых возможностях версии 9.5, а также о некоторых фичах следующих релизов.

Миграция на PostgreSQL : причины... и последствия

Jean-Paul Argudo
Dalibo

Будут рассмотрены традиционные аргументы на тему "почему следует выбрать PostgreSQL среди других баз данных"... Помимо этого, и что достаточно ново для сообщества, будут рассмотрены последствия такого выбора. Переход на PostgreSQL влечет за собой переход не только к таким вещам, как например Linux, но и переход к мышлению в стиле свободного ПО. Быстрый темп развития PostgreSQL диктует новые методы проверки, к которым компании должны адаптироваться.

Растущее признание PostgreSQL в Китае (Huawei и X2)

Galy Lee

Последние новости о продвижении PostgreSQL в Китае. Postgres проходит этап бурного развития в Китае, в частности в 2015 г. Postgres внедрила одна из крупнейших компаний, Alibaba начала предоставлять сервисы Postgres в своём открытом облаке, и в целом наблюдается значительный прогресс в признании Postgres. На этом докладе будет представлен обзор успехов Postgres в Китае в 2015 г.

Высокий уровень параллелизма в Postgres: Банк Бразилии в реальной жизни

Fabio Telles Rodriguez
Timbira

Postgres and Oracle DBA since 2002. Great experience with critical and large environments, development, security and performance in databases. Made dozens of lectures in Brazil and publish hundreds of articles about databases on his blog http://savepoint.blog.br (only portuguese) in the last 10 years. Participated in the regional PSL (Free Software Projects organization), brazilian Debian comunity, and brazilian postgres comunity. Loves good beers and cycling in every city he could.

Проблемы и решения в системе электронного документооборота и процессинга банковских чеков в Банке Бразилии.

Год Профессионального Постгреса в России

Иван Евгеньевич Панченко
Postgres Professional

Исполнилось год с момента создания российского вендора постгреса - компании Postgres Professional. Что полезного для сообщества было сделано компанией, над чем она работает сейчас - о разработках, о сертификации, о русской документации и об образовательной программе.

О структуре и эволюции сообщества PostgreSQL

Магнус Хагандер
PostgreSQL Global Development Group

Магнус является членом PostgreSQL Core Team, разработчиком и коммиттером PostgreSQL Global Development Group, президентом совета PostgreSQL Europe. Был одним из первоначальных разработчиков Windows-порта PostgreSQL. Сейчас работа Магнуса сосредоточена на функциональных возможностях движка PostgreSQL, с особым упором на вопросы безопасности, средства для мониторинга и контроля, инструментарий и программные интерфейсы для решения задач резервирования и репликации данных. Помимо этого, Магнус является одной из ключевых фигур инфраструктурной команды postgresql.org, которая отвечает за сервера, обслуживающие проект. Также, Магнус поддерживает актуальность Web-сайта postgresql.org и вносит свой вклад в иные проекты, такие как pgAdmin.

В отличие от большинства других баз данных, PostgreSQL разрабатывается сообществом, не компанией и даже не фондом. Те, кто участвуют в этом сообществе уже долгое время, обычно считают это преимуществом, но для людей со стороны, привыкших иметь дело с традиционными организациями, это часто бывает непонятно. Для тех, кто ещё не внутри, вместе с нами, в этом докладе будет рассказано, как работает сообщество PostgreSQL, как взаимодействуют различные группы, а также, как всё это изменилось за последние годы.

PostgreSQL в Корее

Hyungjoo Lee
Bitnine

Работает в корейской компании Bitnine, разрабатывающей Agens SQL, являющуюся форком PostgreSQL. Претендует на лидерство в корейском сообществе PostgreSQL.

Корейская группа пользователей PostgreSQL была относительно мала и неактивна многие годы. Однако недавно, в Корее стали происходить изменения. Компании начали искать альтернативы применяемым дорогостоящим проприетарным РСУБД в целях сокращения TCO. Эту тенденцию также поддержали правительственные организации. Мы, компания Bitnine, руководим этим процессом в Корее. В 2015 г. мы запустили первую версию нашего решения на базе PostgreSQL, Agens SQL. Мы переводим документацию PostgreSQL на корейский и ведём группу пользователей PostgreSQL, а также пытаемся участвовать в работе глобальной группы разработчиков PostgreSQL. Кроме того, в этом году планируется проведение первой корейской конференции PostgreSQL и руководить её организацией будем мы. На этом выступлении мы сообщим о текущем состоянии корейской группы пользователей PostgreSQL и рынка СУБД PostgreSQL в Корее. Мы также расскажем о нашей деятельности в Корее и об историях успешного перехода с проприетарных РСУБД на PostgreSQL.

Ядро PostgreSQL

Улучшая Buffer Manager

Andres Freund
Citus Data

Менеджер буферов Postgresql разработан достаточно давно и его возраст даёт о себе знать в некоторых аспектах. Мы обсудим, как он работает сейчас, каковы его недостатки, и что делается сейчас, чтобы их исправить.

  • Поиск в кеше обходится дорого
  • Таблица сопоставлений буфера организована в виде хеш-таблицы, что затрудняет эффективную реализацию предвыборки, совмещение операция записи и очистки содержимого кеша
  • Расширение отношений плохо масштабируется
  • Вытеснение из кеша неэффективно
  • При вытеснении из кеша замещаются неправильные буферы

Расширяемость PostgreSQL: Истоки и новые горизонты

Александр Евгеньевич Коротков
Postgres Professional

Postgres изначально был спроектирован таким образом, чтобы индексные методы доступа были расширяемыми. Известная цитата гласит: "Совершенно необходимо, чтобы пользователь мог создавать новые методы доступа, обеспечивающие эффективный доступ к значениям нетрадиционных типов данных" Michael Stonebraker, Jeff Anton, Michael Hirohama. Extendability in POSTGRES, IEEE Data Eng. Bull. 10 (2) pp.16-23, 1987

Изначально, heap был просто одним из методов доступа. Таким образом, подключаемые методы доступа означали также и подключаемые хранилища, если говорить современным языком. Сейчас в таблице pg_am системного каталога хранятся индексные методы доступа, интерфейс которых хорошо задокументирован. Таким образом, для того, чтобы современный PostgreSQL отвечал первоначальному замыслу необходимо реализовать две фичи:

  • Подключаемые индексные методы доступа, т.е. возможность реализовывать новые типы индексов путём добавления строк в таблицу pg_am;
  • Подключаемые хранилища, т.е. возможность реализовывать совершенно другие движки для хранения данных, не использующие традиционный heap.

Помимо чисто механической работы, такой как реализация команды "CREATE ACCESS METHOD", подключаемые индексные методы доступа должны был защищены WAL'ом. Сейчас, сообщество не хочет, чтобы расширения могли определять свой собственный формат WAL-записей, потому что возникает риск поломать одновременно recovery и репликацию, что неприемлемо. Другим подходом к этой проблеме является обобщённый формат WAL-записей, который задаёт разницу между версиями страницы в общем виде.

Очень немногие СУБД поддерживают сейчас подключаемые хранилища. Самая распространённая из них – MySQL. Но обращение к различным хранилищам в MySQL подобно обращению к различным СУБД. Поэтому, с нашей точки зрения, PostgreSQL не должен идти таким путём.

Однако, сейчас пользователи PostgreSQL всё больше понимают преимущества, которые они бы получили от использования альтернативных хранилищ. Идея колоночного и in-memeory хранилищ для PostgreSQL очень популярна. Одновременно с этим, возрастают наши технические возможности их реализовать. PostgreSQL приобрёл механизмы FDW и custom nodes. Обобщённый WAL и расширяемые индексные методы доступа ожидают включения в 9.6. Очень много работы на пути к подключаемым хранилищам уже сделано, даже если эта работа преследовала совсем другие цели.

Наступило время, когда разработчикам ядра PostgreSQL нужно всерьёз задуматься о нативной поддержке подключаемых хранилищ без костылей. В конце концов, мы должны получить команду "CREATE STORAGE ENGINE name ...", как один из механизмов расширяемости.

В докладе будут продемонстрированы текущие результаты в области подключаемых индексных методов доступа, а также концепция подключаемых хранилищ.

Новые возможности B-tree в PostgreSQL

Анастасия Витальевна Лубенникова
Postgres Professional

Самый часто используемый тип индексов в PostgresSQL - B-tree. Эта структура данных и связанные с ней алгоритмы развиваются уже больше 40 лет. Но, как мы знаем, нет предела совершенству. В этом докладе пойдет речь об особенностях структуры B-tree и его реализации в PostgreSQL, важных для оптимального использования индексов. Кроме того, мы представим улучшения функциональности B-tree в PostgreSQL, которые войдут в релиз 9.6. Это компрессия дубликатов и новые возможности использования покрывающих (covering) индексов.

Всё об изоляции транзакций в PostgreSQL для разработчиков приложений

Kevin Grittner
EnterpriseDB

Когда множество пользователей, процессов или потоков выполнения одновременно модифицируют их общие данные, это может вызывать проблемы, если каким-то образом не урегулировать условия гонки. Эти проблемы особенно остро проявляются в базах данных, реализующих семантику ACID. Набор изменений, объединённых в транзакцию базы данных, должен проявляться атомарно, и для параллельных транзакций, и для процесса восстановления после сбоя. Каждая транзакция должна переводить базу данных из одного согласованного состояния (с точки зрения бизнес-правил) в другое. Для эффективной разработки необходимо иметь возможность запрограммировать каждую транзакцию независимо от других транзакций, которые по стечению обстоятельств могут выполняться в то же самое время. В случае сбоя все изменения, внесённые транзакциями, об успешном завершении которых были уведомлены приложения, а также все изменения, ставшие видимыми для других транзакций, должны оставаться в базе после восстановления. За многие годы были выработаны различные стратегии обеспечения этих гарантий, а иногда гарантии корректировались тем или иным способом. В данном докладе будет рассказано, каким образом обеспечиваются эти гарантии или их компромиссные варианты, с упором на методику сериализуемой изоляции снимков (SSI, Serializable Snapshot Isolation), применяемую в PostgreSQL (и ни в какой другой производственной СУБД на данный момент). Хотя SSI уже работает быстрее и с большей степенью параллельности, чем любая другая методика управления условиями гонки с наиболее типичной нагрузкой, есть много путей для дальнейшего увеличения производительности, некоторые из которых требуют помощи эксперта по различным методам доступа индексов; эти вопросы и будут обсуждены в данном докладе. Кроме того, на докладе будут представлены некоторые общие идеи о том, как можно использовать методики SSI с XTM в распределённой системе. В конце мы оставили время для группового обсуждения оптимизации и возможных применений в распределённой среде.

Внутреннее устройство индексов

Heikki Linnakangas
Pivotal

Heikki is a long-time PostgreSQL developer and committer. He has worked on many parts of PostgreSQL backend, authoring features such as Two-Phase Commit and the new Free Space Map implementation in PostgreSQL 8.4.

PostgreSQL поддерживает несколько типов индексов: GiST, SP-GiST, GIN и, конечно, обычное B-дерево. Администраторы БД знают, когда применять каждый из них: GIN для полнотекстового поиска, GiST для геометрических данных и т. д., но как они устроены внутри? Благодаря чему они хорошо работают в сценариях использования, для которых предназначены? В этой презентации я познакомлю вас с внутренней структурой каждого из этих типов индексов и расскажу, каковы их сильные и слабые стороны.

Сортировка - прошлое, настроящее и будущее

Gregory Stark

Gregory Stark has been hacking on Postgres since 2006 when he submitted CREATE INDEX CONCURRENTLY. Subsequent contributions included denser data storage, MergeAppend support for partitioned tables, and

When new versions of Postgres are released most of the attention is focused on new features. Inevitably a release note claiming speed improvements seems relatively mundane and doesn't provide the compelling argument for upgrading. However the reality is that these speed improvements represent pain points that have been identified and solved.

Reviewing the changes to the sort code in Postgres over the last 10 years clearly shows the kinds of problems users have run into. As usage patterns changed over years, databases scaled up, and hardware changed new problems arose and drove further development to solve them.

Upcoming changes in 9.5 and 9.6 will dramatically change the experience further. Making sorting UTF8 and other encodings less of a problem and handling scaling to larger machines with many processors and memory cache more effectively.

Кластеры и репликация

Менеджер распределённых транзакций для кластера PostgreSQL

Константин Александрович Книжник
Postgres Professional

Автор нескольких свободных ООСУБД, сейчас работаю в кластерной команде в Postgres Professional

В корпоративных информационных системах от СУБД требуется поддержка кластеров, для обеспечения требуемого уровня масштабирования и надёжности. К сожалению, многочисленные попытки реализовать кластеры для Постгреса, такие как Postgres-XL/XC, так и не были доведены до коммерческого уровня и не были приняты сообществом. Другие существующие решения, например, pg_shard, plproxy не поддерживают глобальных ACID транзакций. Наша команда разработала менеджер распределённых транзакций (DTM) как расширение Постгреса, позволяющее достичь глобальной целостности для нескольких экземпляров Постгреса, объединённых в один кластер. DTM - это конструктор, позволяющий реализовать различные решения на его основе. В качестве демонстрации возможностей DTM мы интегрировали его в pg_shard и postgres_fdw. Мы надеемся, что наш подход с расширяемым менеджером транзакций будет включён в версию 9.6 Постгреса и позволит разрабатывать различные кластерные решения на его основе.

Как мы сделали Greenplum Open Source

Andreas Scherbaum
Pivotal

Andreas Scherbaum is working with PostgreSQL since 1997. He is involved in several PostgreSQL related community projects, member of the Board of Directors of the European PostgreSQL User Group and also wrote a PostgreSQL book (in German). Since 2011 he is working for EMC/Greenplum/Pivotal and tackles very big databases.

Greenplum — это форк PostgreSQL, оптимизированный для использования в аналитике и хранилищах данных. Компания Pivotal в начале 2015 г. анонсировала, что часть её продуктов станут продуктами Open Source, в том числе и Greenplum Database. На этом выступлении будет представлен обзор истории Greenplum, всего процесса перевода продукта в мир Open Source и препятствий, с которыми мы столкнулись. Мы также расскажем, как можно принять участие в нашем проекте.

О построении кластеров на основе потоковой репликации и PgPool II

Tatsuo Ishii

Речь пойдет о кластерных решениях для PostgreSQL на основе потоковой репликации и pgpool-II, которые очень популярны в Японии. Также рассматриваются новые возможности следующей версии pgpool-II, которая будет выпущена этой зимой.

CitusDB: расширение для масштабирования PostgreSQL

Marco Slot
Citus Data

CitusDB — расширение PostgreSQL, позволяющее распределять таблицы в кластере серверов PostgreSQL. Данные разделяются по секциям (шардам) по добавлению (оптимально для массовой загрузки данных временных рядов) или по хешу (для введения данных в реальном времени). Запросы SELECT к распределённым таким образом таблицам прозрачно распараллеливаются в кластере, при этом задействуются все доступные ядра. Также параллельно возможно соединять распределённые таблицы, даже если они разделены не по значению одной колонки. CitusDB исключительно подходит для сценариев использования с анализом в реальном времени, например, для информационных панелей, где нужны быстрые аналитические запросы к динамическим данных и в то же время востребована масштабируемая оперативная база данных. На этом докладе будет освещено внутреннее устройство CitusDB и представлена живая демонстрация крупномасштабного кластера CitusDB.

Производительность и масштабирование

Масштабируемость PostgreSQL

Дмитрий Васильев
Postgres Professional

Инженер СУБД. Начинал карьеру с разработчика, последнее время работал эксплуататором по методологии devops. Принимал участие в создании платформы для работы и вещания: Веб-выборы, ПМЭФ 2013-2015, ЕГЭ 2015. Сейчас работаю в компании Postgres Professional

В докладе рассказывается о результатах тестирования производительности PostgreSQL на современных Hi-End серверах. Основное внимание было уделено блокировкам для доступа к разделяемым данным и связанными с этим узкими местами. Целью тестирования было проверить пределы линейного read scalability при увеличении количества ядер выделяемых для PostgreSQL. Тестирование проводилось для различных версий БД (9.4, 9.5, 9.6), чтобы проверить нововведения, призванные повысить производительность на многопроцессорных архитектурах.

Почему IBM Power8 - оптимальная платформа для PostgreSQL

Иван Гончаров
IBM

Что такое платформа IBM POWER8? Благодаря каким особенностям архитектуры, получается достигать большей производительности и масштабируемости PG по сравнению с x86_64? Производительность ядра, подсистемы памяти, процессорного интерконнекта и ввода/вывода. Уникальные и доступные только на POWER8 "фишки". Опыт тестирования как pgbench, так и реальных приложений.

Секционирование без границ

Ильдар Мусин
Postgres Professional

Механизм секционирования в Postgres имеет ряд ограничений, которые не позволяют использовать концепцию секционирования в полной мере. Среди таких ограничений можно выделить неэффективность планирования запросов для секционированных таблиц (линейный рост времени планирования при увеличении количества секций), отсутствие HASH-секционирования, необходимость ручного управления секциями. Однако, средства расширяемости Postgres предоставляют разработчику широкие возможности, позволяющие обойти некоторые ограничения. В докладе будет рассказано, как внедрившись в код планировщика удалось оптимизировать время планирования запросов. Так метод бинарного поиска позволяет добиться логарифмического роста времени планирования для RANGE-секционированных таблиц. Поэтому использование даже тысяч секций не будет приводить к существенным накладным расходам. Также удалось реализовать HASH-секционирование с близким к константному времени планирования.

Ускорение исполнения запросов в PostgreSQL с использованием JIT-компилятора LLVM

Дмитрий Михайлович Мельник
ИСП РАН

В настоящее время в PostgreSQL для исполнения SQL-запросов используется интерпретатор. Это приводит к накладным расходам, связанным с неявными вызовами функций-обработчиков и проверок, которых можно было бы избежать при создании исполняемого кода "на лету" (JIT-компиляции) под конкретный SQL-запрос: в этом случае во время выполнения уже известна структура используемых таблиц и типы данных. Особенно это актуально для сложных запросов, где производительность процессора является основным ограничением. В настоящий момент существует два известных проекта, реализующих JIT-компиляцию в PostgreSQL: коммерческое решение Vitesse DB и open-source проект PGStorm. В первом проекте за счет использования LLVM JIT авторам удается получить ускорение до 8 раз на тестах из набора TPC-H. Второй проект реализует JIT-компиляцию запроса с использованием CUDA для исполнения его на GPU, что позволяет ускорить выполнение некоторых типов запросов на порядок.

Наша работа посвящена добавлению поддержки JIT-компиляции SQL-запросов в PostgreSQL с использованием компиляторной инфраструктуры LLVM. В докладе будет подробно рассмотрено, как JIT-компиляция может быть использована для ускорения различных этапов исполнения SQL-запросов, а также особенности трансляции SQL-запросов в LLVM-биткод для получения эффективного исполняемого кода. Также будут представлены предварительные результаты тестирования JIT-компилятора на наборе тестов TPC-H.

Применение методов машинного обучения для улучшения планировщика

Олег Юрьевич Иванов
Postgres Professional

Студент кафедры машинного обучения факультета ВМК МГУ, победитель различных олимпиад по информатике. В настоящее время работаю в компании Постгрес Профессиональный, где занимаюсь применением методов машинного обучения для построения более быстрых планов выполнения запросов.

В докладе будет рассказано о существующем планировщике PostgreSQL, о возможностях его улучшения с помощью методов машинного обучения и о полученных в этой области результатах.

Слон из нержавеющей стали: продолжаем тестирование производительности PostgreSQL

Александр Чистяков
ООО "Жить в небе"

Александр Чистяков - главный инженер в компании Git in Sky, предоставляющей услуги системного администрирования для веб-проектов, автоматизации IT-процессов и ускорения работы приложений. Он работал в таких компаниях как Motorola, Mail.Ru, DataArt и Borland. По ночам читает планы запросов.

Замечательная компания servers.com предоставила нам один из своих серверов для тестов, что позволило нам протестировать производительность PostgreSQL на реальном железе под разными операционными системами, включая SmartOS, DragonFly и Windows. Полученные результаты мы хотим представить сообществу.

Linux VMM для разрабочиков СУБД

Александр Викторович Крижановский
ООО "Лаборатория НатСис"

Александр - генеральный директор Tempesta Technologies и ведущий разработчик Tempesta FW. В 2008 году он основал компанию NatSys Lab, предоставляющую консалтинг в области высокопроизводительных вычислений в Linux/x86-64. Александр имеет более 10 лет опыта в Linux kernel и 5 лет в разработке MySQL, InnoDB и Galera Cluster.

В докладе будет рассказано о том, как Linux работает с виртуальной памятью. Будут освещены следующие вопросы:

  • устройство таблицы страниц в x86-64, переключение контекста, page fault;
  • устройство системы управления виртуальной памятью (VMM) в Linux;
  • методы вытеснение странц в Linux, page cache и анонимные страницы;
  • huge и gigantic pages, transparent huge pages;
  • как работает mmap(2) и что дают madvise(2), msync(2) и пр.;
  • почему большие СУБД не используют mmap(2), а реализуют свой пул страниц;
  • и, конечно, как потюнить VMM в Linux с помощью sysctl.

Прикладная разработка

Jsonb в PostgreSQL и NoSQL тренд: сравнение функциональности и производительности

Дмитрий Андреевич Долгов

Web developer, аспирант, автор расширения jsonbx и соавтор нового функционала для jsonb в PostgreSQL 9.5.

Использование слабоструктурированных данных определенно является трендом современности, и это верно не только для NoSQL, но и для традиционных RDBMS. Многие реляционные базы данные (например, PostgreSQL, Oracle, db2, Mysql) позволяют хранить данные в json формате, и, очевидно, реализуют это по-разному.

Доклад содержит две части:

  • Сравнение поддержки json в PostgreSQL и других реляционных базах данных, а именно Mysql, Oracle, db2, MSSql в контексте реализованных возможностей, функций и т.д.
  • Сравнение производительности для баз с наиболее полной поддержкой json (PostgreSQL и Mysql) а также MongoDB на различных видах нагрузок и конфигураций.

Хранимые процедуры в PostgreSQL, язык PL/pgSQL

Pavel Stehule

  • Архитектура
  • Дизайн и релизация языка PL/pgSQL
  • Разница между PL/SQL и PL/pgSQL
  • Преимущества и проблемы PL/pgSQL

Декларативное программирование клиентов Postgres в Haskell с помощью Hasql

Никита Юрьевич Волков
Sannsyn AS

Программист с пятнадцатилетним стажем, в последние годы специализируется на функциональном программировании на таких языках, как Haskell, Scala, Clojure. Автор множества open-source проектов для Haskell, в числе которых Stm-containers (http://nikita-volkov.github.io/stm-containers/), Record (http://nikita-volkov.github.io/record/) и Hasql (http://nikita-volkov.github.io/hasql-benchmarks/). Создатель проекта SORM (http://sorm-framework.org), ORM-фреймворка для Scala. Ведёт блог о функциональном программировании http://nikita-volkov.github.io/. В настоящий момент — старший разработчик в норвежской компании Sannsyn AS (http://sannsyn.com/).

Речь пойдёт о "hasql", высокоэффективной библиотеке для интеграции Haskell с PostgreSQL. Вы познакомитесь с удивительным языком программирования Haskell, преимуществами декларативного программирования и техническими решениями библиотеки, среди которых имплементация бинарного протокола для общения с Postgres. Эта библиотека используется проектом PostgREST, популярным универсальным REST API для баз данных Postgres.

PL/v8 в медицине

Николай Рыжиков
Health Samurai

Действующий программист, люблю open source, postgresql и функциональное программирование

Мы разрабатываем медицинскую базу данных - fhirbase, основанную на PostgreSQL и современном стандарте обмена медицинской информацией FHIR. Первая версия была написана с использованием SQL и PL/PgSQL, однако она достигла предела своей сложности и была полностью переписанна на PLv8/javascript. В докладе я расскажу про архитектуру fhirbase и то, почему мы выбрали PLv8. Про комфортную среду разработки, которая позволяет разрабатывать код и тесты в Node.JS и потом деплоить этот код в PostgreSQL. Поделюсь проблемами, с которыми мы столкнулись. Порассуждаем о переиспользовании библиотек и эко-системы javascript для разработки бизнес-логики внутри PostgreSQL. Расскажу про идеи PostgREST и no-backend приложений на PostgreSQL.

Lua в Postgres(из alpha в beta)

Евгений Михайлович Сергеев

Около 10 лет занимаюсь разработкой софта под различные СУБД(Oracle, Firebird, MSSQL, PostgreSQL), постгрес около 2-х лет. В данный момент в НИПК Электрон СПб разрабатываю медицинские информационные системы с использованием plpgsql и plv8, дорабытываю pllua как интересный мне проект.

В докладе хотел бы рассказать про возможности использования языка луа в постгресе, способы расширения функциональности при помощи готовых модулей, возможности удаленной отладки, про проделанные изменения с версии 1.0, отличия в стиле написания кода plpgsql и pllua при использовании функций как аргументов. Так же можно рассказать про некоторые спорные моменты, такие как расширение поддерживаемых типов данных в этом языке. Если интересна другая сторона, то могу поделиться опытом доработки фунциональности скриптового языка в постгресе.

PostgreSQL и Java: прошлое, настоящее и будущее

Alvaro Hernandez
8Kdata

Álvaro is a 36 year-old IT entrepreneur, based in Madrid, Spain. Founder and CTO at 8Kdata (www.8kdata.com), a database R&D company, he spends most of his time working on the ToroDB (www.torodb.com) project, the first NoSQL-on-SQL database, a MongoDB-compatible database that runs on top of PostgreSQL. He is a passionate software developer and open source advocate. Álvaro is a Java software developer, member of JavaSpecialists.eu, but also a DBA, trainer and frequent lecturer at international conferences. He also founded the PostgreSQL Spanish User Group (www.postgrespaña.es), one of the largest PUGs in the world, with more than 500 members.

Java - наиболее часто используемый язык программирования в мире. Как же он поддерживается в PostgreSQL? Какие в нем есть подводные камни и каковы лучшие практики? Java продолжает развиваться, как это сказывается на ее использовании в PostgreSQL?

Несмотря на солидный возраст языка Java, он силен как никогда. Фактически, это язык программирования мира enterprise. И с выхода Java 8, он вернулся в мир стартапов и open source. И сейчас Java становится наиболее распространенным языком для обращения к PostgreSQL.

В этом докладе будет разобрано, как была в прошлом, и, что важнее, как в настоящем, организована работа с PostgreSQL из Java: JDBC, PL/Java и другие, реже используемые средства.

Затем мы заглянем в будущее, чтобы понять, что сейчас ещё разрабатывается, как например новый реактивный драйвер Phoebe для доступа из Java в PostgreSQL, ориентированный на кластеры, конвейерные запросы и полностью асинхронный не JDBC интерфейс. Рассмотрим также, что должно быть сделано на серверной стороне, чтобы Java могла стать основным языком серверного программирования для PostgreSQL.

PostgreSQL и JDBC: выжимаем все соки

Владимир Валентинович Ситников
ООО НетКрэкер

Девять лет работает над производительностью и масштабируемостью NetCracker OSS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. Автор более десятка улучшений производительности в официальном PostgreSQL JDBC драйвере.

Все говорят, что для максимальной производительности работы из Java с базой данных нужно использовать PreparedStatements и Batch DML. Практика показывает, что нельзя слепо идти на поводу у прописных истин. Нужно понимать особенности конкретной базы и характера передаваемых данных. В докладе мы рассмотрим то, как эффективное использование протокола PostgreSQL позволяет добиться высокой производительности при выборке и сохранении данных. На примерах увидим как простые изменения в коде приложения и JDBC драйвера на порядок ускоряют запросы. Мы увидим как задействовать механизм server prepared statements из клиенсткого кода и узнаем его узкие места. Обсудим средства эффективной передачи данных в базу. Многие обсуждаемые доработки недавно вошли в состав официального JDBC драйвера. Доклад будет полезен не только Java программистам, т.к. многие подводные грабли вытекают из самого протокола общения PostgreSQL с внешним миром.

Multicorn: разработка Foreign Data Wrapper'ов на языке Python

Ronan Dunklau
Dalibo

Multicorn - это обобщенный Foreign Data Wrapper (FDW, интерфейс для подключения внешних источников данных, устоявшегося русского названия пока нет), предоставляющий возможность разработки конкретных FDW на языке Python, что упрощает их разработку.

Мы узнаем:

  • Что такое FDW, как работает Multicorn, и какие готовые FDW поставляются вместе с ним.
  • Как написать свой FDW на python, включая новый интерфейс IMPORT FOREIGN SCHEMA, появившийся в версии 9.5.
  • Внутренности Multicorn: что он делает и что не делает внутри.

После общего рассмотрения FDW и Multicorn, мы детальнее рассмотрим некоторые FDW, поставляемые с ним.

Затем проведем полный тур по API Multicorn, чтобы научить вас создавать FDW на Python, включая следующие детали:

  • испольование определений таблиц
  • пробрасывание WHERE
  • ограничения колонок
  • как влиять на планировщик
  • как писать во внешнюю таблицу
  • как работать с импортом внешней схемы
  • пробрасывание ORDER BY
  • управление транзакциями

Все это будет объяснено наглядно, с примерами кода, позволяющими слушателям с нуля создать свой FDW на Python.

Об опыте применения JSONB в реальных проектах

Евгений Александрович Тюменцев
ООО "Здравствуй мир! Технологии"

Опыт работы в ИТ-отрасли 10 лет. Специализируюсь на разработке многопоточных и распределенных серверных приложений.

Будут рассмотрены преимущества и недостатки решений на основе JSONB по сравнению с традиционным реляционным подходом на примере реальных проектов, в том числе: 1. Производительность 2. Версионность данных 3. Масштабируемость 4. Надежность 5. Построение отчетов

Администрирование, миграция и безопасность

PostgreSQL и резервное копирование

Michael Paquier

Michael Paquier is a hacker and blogger of PostgreSQL community, currently working at VMware on PostgreSQL related technologies. He has many areas of focus and a large panel of activity in community, be they implementation of new features, bug fixes, or patch reviews.

Резервное копирование это то, без чего не должна обходится эксплуатация PostgreSQL, поскольку позволяет восстановить систему в случае сбоя.

Мы обсудим, почему резервное копирование необходимо при грамотной эксплуатации PostgreSQL (хотя это и кажется очевидным), а также рассмотрим различные опции, доступные для формирования хорошей стратегии резервирования. На этой основе, поговорим о будущем резервного копирования, особенно в свете различных инструментов резервирания, набирающих популярность у пользователей с большими объемами данных.

Портирование облачного решения с Oracle на PostgreSQL: опыт компании "БАРС Груп"

Марат Мисбахетдинович Фаттахов
АО "БАРС Груп"

Дмитрий Владимирович Бойков
АО "БАРС Груп"

Изначально компания «БАРС Груп» была ориентирована на задействование в своих проектах СУБД Oracle, но появление PostgreSQL игнорировать не могла. На конференции мы расскажем, как пришли к использованию PostgreSQL и поделимся опытом перевода на эту СУБД большой медицинской информационной системы.

  1. Опыт использования СУБД PostgreSQL и Oracle в проектах компании. Предпосылки и мотивация использования СУБД PostgreSQL.
  2. Ход и результаты эксперимента миграции медицинской информационной системы:

    • разработка утилиты конвертации кода PL/SQL в PgSQL;
    • проблемы переноса сложных пакетов;
    • патчи к PostgreSQL как варианты решения этих проблем.

Автоматизированная миграция приложений с проприетарных СУБД на PostgreSQL

Борис Викторович Верюгин
ООО "Диасофт Платформа"

Руководитель управления развития в ООО "Диасофт Платформа" (http://www.diasoft-platform.ru/). Главный системный архитектор основных продуктов компании. В настоящее время участвую в проектах миграции информационных систем на свободные или российские СУБД.

В докладе будут представлены технические решения компании "Диасофт Платформа" по миграции приложений с проприетарных СУБД (на примерах Oracle и Microsoft SQL Server) на PostgreSQL. Эти решения реализует программный продукт "Diasoft Database Adapter".

Разработанные нами технические решения позволяют автоматизировать: 1) миграцию схемы БД (включая трансляцию кода хранимых процудур и функций); 2) миграцию данных; 3) миграцию приложений-клиентов СУБД без какого-либо изменения их кода.

Расширенные возможности аудита в СУБД PostgreSQL в дистрибутиве ОС "Astra Linux Special Edition"

Дмитрий Леонидович Воронин
ОАО "НПО РусБИТех"

Закончил НИЯУ МИФИ в 2014г по специальности "математик, системный программист". Опыт работы с PostgreSQL около 4 лет. Сейчас занимаюсь разработкой защищенной версии СУБД PostgreSQL.

Базовая версия СУБД PostgreSQL предоставляет возможность регистрации событий:

- входа и выхода пользователей;
- отказа в доступе к защищаемому ресурсу;с указанием даты, времени и имени пользователя.

Требования руководящих документов к подсистеме регистрации событий намного шире возможностей базовой версии СУБД PostgreSQL.

ОАО «НПО РусБИТех» проводит необходимые доработки СУБД PostgreSQL для расширения ее функциональных возможностей.

В результате доработок подсистема регистрации событий СУБД PostgreSQL в составе ОС «AstraLinux Special Edition» дополнительно обеспечивает возможность регистрации:

- создания и уничтожения объектов баз данных;

- изменения правил разграничения доступа;

- как отказов, так и успешных попыток доступа к объектам баз данных;

- изменений полномочий субъектов доступа и статуса объектов доступа.

Для всех событий указываются:

- дата и время; 

- пользователь, осуществляющий регистрируемое действие;

- объект, над которым проводится действие;

- тип события;

- результат операции.

Подсистема регистрации событий доработанного PostgreSQL интегрирована в централизованную систему аудита ОС «Astra Linux Special Edition». Обеспечена настройка правил регистрации событий без останова (перезапуска) СУБД.

Администрирование PostgreSQL в Avito

Сергей Анатольевич Бурладян
Avito

Мой доклад будет посвящён особенностям использования и администрирования PostgreSQL в Debian GNU/Linux в Avito. В частности, таким проблемам как:

- bash скрипты
- утилиты pg_* debian
- отладка postgres: perf, gdb
- COPY без разрывов: psql, pipe
- pgbouncer: один, два, ... больше?
- cron
- мониторинг
- очередь на advisory lock
- файловый кеш
- DDL на нагруженной базе
- и т.д.

Информационная безопасность в PostgreSQL

Валерий Викторович Попов
Postgres Professional

В докладе рассмотрим требования информационной безопасности, которые предъявляются к СУБД, используемым для государственных нужд. Разбираются требования регуляторов, проводится сравнение имеющихся сертифицированных версий СУБД, принципы организации дискреционного и мандатного методов доступа к данным. Подробно рассмотрено, как обеспечить невозможность доступа к конфиденциальным данным после их использования (очистка памяти), в каких местах и каким способом реализована очистка данных в СУБД Postgres Pro. В докладе будет рассказано о новой возможности обеспечения безопасности на уровне строк (RLS), которая появилась в PostgreSQL 9.5. Также рассмотрим, как работает группа Security Information в международной группе разработчиков PostgreSQL, каким образом устраняются уязвимости.

1C на PostgreSQL

"1С:Предприятие": самая популярная в России/СНГ платформа разработки с поддержкой PostgreSQL

Петр Грибанов

16 лет в разработке ERP: iScala, Epicor, MS Dynamics AX, теперь - 1С. Специализация - платформы ERP и инструменты разработчика

Более 300.000 разработчиков используют в качестве основного средства разработки технологическую платформу "1С:Предприятие". Я расскажу об особенностях идеологии и архитектуры платформы "1С:Предприятия", которые позволили ей стать одним из самых массовых средств разработки в России и СНГ, и о том, почему СУБД PostrgreSQL становится все популярнее среди пользователей технологий 1С.

Опыт использования больших баз 1С на PostgreSQL

Дмитрий Мирчевич Юхтимовский
Gilev.ru

Компания gilev.ru - ведущая российская компания по оптимизации производительности информационных систем 1С:Предприятие 8.

Доклад для тех, кто уже использует постгрес для 1С, а также для тех, кто только раздумывает - использовать ли. Расскажем о том, почему в компании Gilev.ru выбрали PostgreSQL для своих больших баз онлайн-сервисов, как его используют. Как с использованием этих сервисов помогают решать проблемы производительности баз на 1С, с которыми сталкиваются или могут столкнуться клиенты.

Опыт использования PostgreSQL в качестве СУБД для платформы 1С:Предприятие от 8.1 до 8.3

Лев Ласкин
Электрон

Занимаюсь вопросами внедрения решений на платформе 1С:Предприятие с 2005 года, решениями с использованием PostgreSQL с 2008 года. Имею большой практический опыт запуска проектов внедрения 1С в среде linux

В конце 2006 компанией 1С была реализована работа платформы 1С:Предприятие с СУБД PostgreSQL, которая может функционировать под управлением операционных систем Windows или Linux. В докладе будет предпринята попытка обобщить опыт совместного использования платформы 1С:Предприятие с СУБД PostgreSQL начиная с 2008 года. Будут рассмотрены несколько историй успеха, технические особенности работы, приведены примеры решения конкретных задач, даны рекомендации по выбору за и против. Доклад может быть интересен сотрудникам компаний рассматривающих вариант использования PostgreSQL для платформы 1С:Предприятие, DBA, специалистам интересующимся возможностями расширяемости PostgreSQL.

Опыт практиков

PostgreSQL как ядро биржи интернет-рекламы Adsterra.com

Юрий Сергеевич Соболев
ООО "МедиаТех"

Технический директор проекта. Архитектор БД. Создал всю структуру и логику проекта, используя Postgresql.

Общая информация об adsterra.com

  • adsterra.com - биржа интернет рекламы
  • В данный момент имеет порядка 150 млн показов баннеров в сутки.120 положение в alexa.com на 30.11.2015. Записывает в postgresql до 10000(и больше) событий в секунду. Читает до 5000
  • 20 отдельных серверов под БД с различными ролями
  • Активно использует логику внутри БД. Много PL/pgsql и SQL функций.

Причины выбора Postgresql

  • История создания adsterra.com.
  • Сжатые сроки отведенные на разработку определили выбор в пользу готовых систем хранения данных.
  • Postgresql привлек своей бесплатностью и рядом фишек, которых не было у конкурентов. Некоторые в итоге оказались полезными, некоторые не очень.

Описание архитектуры проекта

  • Общая схема взаимодействия
  • Роли групп серверов
  • Использование различных методов для взаимодействия серверов: Потоковая репликация, Londiste, postgres_fdw. Плюсы и минусы каждого.
  • Шардинг
  • Использование SQL под OLTP

Проблемы возникшие в ходе разработки/использования и варианты решения:

  • Материализованные представления. Проблемы с обновлением и поддержкой. Что сделали в итоге.
  • Londiste. Какие проблемы были решены в ходе разработки, а какие так и не были.
  • Проблемы потоковой репликации.
  • Автовакум и вакум.
  • Странности планировщика.
  • Конкурентный доступ.

Крутые штуки Postgresql, которые сильно помогли

  • Массивы, intarray и GIN индексы. Но не все гладко.
  • Партиционирование. Но не все есть, что хочется.
  • PL/pgsql. Но не всегда следует его использовать.
  • unlogged таблицы. Но с умом.

Текущие разработки и нерешенные проблемы

  • Реализация колоночной аналитики штатными средствами.
  • Проблемы странных планов запросов.
  • Логическая репликация мечты
  • Мультимастер...

Интеграция данных в мире микросервисов

Валентин Гогичашвили
Zalando

Стремительно стартовав в 2008 году, Zalando продолжает развиваться, не снижая скорости. На пути от скромного стартапа к многонациональной корпорации возникает множество сложнейших задач, особенно для Zalando Technology. Команда из 900 человек, распределенных в Берлине, Дортмунде, Дублине и Хельсинки, продолжает расти, планируя еще до конца 2016 года увеличиться в два раза.

Столь динамичный рост научил нас оперативно менять процессы и перестраивать организационную структуру в зависимости от актуальных задач. С марта 2015 года мы применяем Radical Agility — новейшую стратегию, провозглашающую Автономность, Целеустремленность и Мастерство (Autonomy, Purpose and Mastery) ключевыми принципами — для сплоченной работы команд программистов и менеджеров продукта.

Реализуя автономность, команды теперь могут самостоятельно выбирать стеки технологий для разработки своих продуктов. Микросервисы, использующие для коммуникации RESTful API, предполагают снижение стоимости интегрирования между такими командами. Изолированные AWS аккаунты, при поддержке разработанной в Zalando open-source PaaS платформы (STUPS.io), дают возможность каждой автономной команде использовать нужное ей количество вычислительных ресурсов для проведения экспериментов и выкатывания новых функций.

Возникает другая проблема с микросервисами, изолированными в собственных AWS аккаунтах: команды хранят данные локально, недоступно для централизованных процессов сбора данных. В такой среде довольно сложно автоматизировать ETL процессы для дальнейшего анализа данных или интегрировать данные, принадлежащие различным сервисам.

Новые возможности логической репликации PostgreSQL обеспечивают потоковую пересылку информации об изменениях в базах данных в интеграционные системы, представляя ее там в удобном для обработки и анализа виде.

В моем докладе я расскажу об open-source прототипе, разработанном в Zalando для сбора информации из изолированных PostgreSQL баз данных, применяющем возможности потоковой логической репликации в PostgreSQL с преобразованием данных для использования в разных системах их обработки (Data Lake, Operational Data Store, системы вычисления КПЭ или автоматического мониторинга за процессами). Слушатели узнают, как именно можно использовать логическую потоковую репликацию в мире микросервисов.

Пять слайдов о Postgres

Михаил Александрович Тюрин
Avito

Более 10 лет опыта использования СУБД в web разработке. Один из создателей Авито.

За годы моей работы с PostgreSQL возникло ясное представление, о том, каковы его основные достоинства ("Киллер-фичи", "вкусняшки"), из-за которых мы выбираем и рекомендуем выбирать эту СУБД.
1. Начало
2. Документация
3. Комьюнити
4.1 Транзакционный DDL
4.2 WAL и настоящая физическая репликация
4.3 Транзакционный снепшот и настоящая логическая репликация и PGQ
4.4 Потрясающая расширяемость
5. Успех

Поток данных в Авито

Константин Сергеевич Евтеев
Авито

Константин Евтеев, Avito.ru • Разработчик баз данных • С Postgres c 2009 года: миграции с MS SQL, администрирование обеих СУБД • В Авито с 2014 года: разработка распределенных систем обработки данных

В рамках доклада речь пойдет о подсистеме транзакционного сбора изменений состояний объектов и сигналов о событиях; доставке этих данных получателям, обработке на различных этапах процесса.

1 Обзор data stream и задач, решаемых с его помощью. 2 Подготовка данных: - работа с триггерами - блокировки - сигналы 3 Доставка событий 4 Прием данных 5 Особенности согласования данных

Эволюция использования PostgreSQL в справочном API 2GIS

Денис Витальевич Иванов
2ГИС

В программировании более 10 лет. Успел поработать ведущим разработчиком, архитектором, руководителем IT-отдела и заместителем технического директора. Разработчик-полиглот. Люблю «быстрый» и «красивый» код.

  • Первое появление постгреса в команде
  • Борьба с репликацией
  • Партицирование и миграции
  • Кросс-датацентровое использование
  • v8, json, jsonb, jsquery
  • Апгрейд версии postgresql

На данный момент на продакшене бекенда справочного API 2GIS мы имеем с десяток различных баз в postgresql, около 120 шардов, миллионы записей в таблицах. При этом практически все данные хранятся в структурах jsonb

Я расскажу об эволюции продукта с точки зрения взаимодействия с СУБД.

Оптимизация обработки данных аналитических отчётов

Камиль Фаритович Исламов
Троник

Разработчик СУБД Postgres, Oracle. Опыт разработки, внедрения, миграции, оптимизации биллинговых систем на базе Oracle. Разработка архитектуры систем мониторинга беспроводных устройств, мобильных сервисов на базе Postgres

Приводится методика, с помощью которой можно автоматизировать обновление результатов предварительной обработки аналитических данных. Предварительная обработка и кэширование отчётов позволяет моментально получать результаты отчётов по большим объёмам данных. В докладе описывается способ обновления кэшированных отчётов с минимальной нагрузкой на сервер и с управляемой степенью актуальности.

Как построить высокоэффективную (гео)распределённую ИТ-систему при любых каналах связи?

Владимир Игоревич Сердюк
SOFTPOINT

Образование: МГУ им. Ломоносова (физический факультет), Выпуск 1994 года. С 2005 г. основатель и Ген. директор группы компаний Softpoint. С тех пор все силы направил на создание инновационных решений по проблемам производительности и масштабируемости информационных систем. Таких решений уже более 10 и большая часть запатентована.

У вас есть распределенная ИТ-система, в ней много узлов, НО:

  • Недостаточная оперативность обмена. Задержка синхронизации – часы или дни?
  • Помехи пользователям: блокировки во время выполнения обмена?
  • Слабая управляемость - статус обмена всех узлов не ясен;
  • Низкая стабильность обмена, необходимость ручного управления?

DBReplicaton - технология высокоскоростного обмена данными между базами PostgreSQL. В данном докладе представлено решение, работающее уже в десятках средних и крупных компании России (>2500 активных пользователей, >20 узлов обмена), которое обладает: - Собственной транспортной подсистемой; - Централизованным единым интерфейсом управления и контроля за обменом; - Двусторонним обменом: возможностью работать с данными на изменение во всех узлах, участвующих в обмене; - Высокой скоростью обмена (от 2 секунд).

Дополнительно будет рассказано о необычном применении репликации в различных бизнес-системах.

Обработка статистических данных в режиме реального времени посредством триггеров

Григорий Игоревич Хромов
MyAsterisk

В нашей телефонной платформе исторически использовалась СУБД MySQL и стандартная система статистики CDR. Постоянные оптимизации позволили сократить время ожидания загрузки информации, но оно было все еще велико. Ко всему прочему CDR не отличалась детальностью и высокой точностью. Было принято решение миграции на PostgreSQL и создание собственной системы сбора статистики на основе подсистемы CEL. CEL генерирует по одной записи на каждое внутреннее событие происходящее во время звонка и число таких записей может достигать несколько сотен. Применив триггеры PostgreSQL мы смогли сформировать подробную статистику всего в одной записи на каждый звонок. При этом общая производительность по сравнению со старой системой ощутимо выросла – время загрузки сократилось с минуты и более до нескольких секунд.

Постгрес в облаках

Мега-масштабирование PostgreSQL: Советы от работающих с 10^6 баз данных

Peter van Hardenberg
Heroku

Peter van Hardenberg was a founding member of the Heroku Postgres database product, and has spoken around the world about PostgreSQL. He's answered untold numbers of user questions and spent time working with users at all stages of development and expertise.

Heroku Postgres is a cloud database service and the largest provider of PostgreSQL as a service anywhere. We operate more than 1,000,000 PostgreSQL databases with a team of about 10 people. We may be the most efficient DBAs in history, with approximately 100,000 databases per person on our team! This talk will introduce the opportunity and challenges of building and operating a cloud database service, as well as discussing the strategies we use to build, operate, and scale this product and team for the last six years now. We will include details about

  • a brief introduction to the service to provide context
  • strategies to design and build such a data service
  • operational war stories like how to recover from losing thousands of servers at once,
  • common challenges users have with Postgres
  • and a basic overview of the technical architecture

This is a complementary talk to Will Leinweber's talk, which will go into much more depth on the architecture of the software we have written.

Heroku Postgres: архитектура облачного сервиса баз данных

Will Leinweber
Heroku

Will has helped to build Heroku Postgres for nearly 5 years.

Помимо предоставления универсальной веб-платформы, Heroku предлагает крупномасштабные и поддерживаемые сервисы Postgres. За годы мы многое узнали о том, как использовать Postgres в большом масштабе.
На этом докладе мы расскажем:

  • почему Postgres привлекателен для запуска в облачном сервисе
  • как подготовить, управлять и контролировать инфраструктуру Postgres
  • чем придётся пожертвовать, чтобы Postgres работал в такой среде
  • об автоматическом восстановлении после сбоя
  • и о многом другом

Алибаба и PostgreSQL

Guangzhou Zhang
AliBaba

Наш облачный сервис по использованию реляционных баз данных предоставляет доступ к Постгресу (aliyun.com, в настоящий момент крупнейшее частное облако в Китае). Мы также используем Постгрес для наших внутренних приложений и готовы поделиться своим опытом.