title

text

Kevin  Grittner
Kevin Grittner EnterpriseDB
15:00 05 февраля

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

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

Слайды

6_Кевин Гриттнер kevin.ppt

Видео

Другие доклады

  • Дмитрий Воронин
    Дмитрий Воронин ОАО "НПО РусБИТех" Инженер-программист
    22 мин

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

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

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

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

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

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

    - создания и уничтожения объектов баз данных;
    
    - изменения правил разграничения доступа;
    
    - как отказов, так и успешных попыток доступа к объектам баз данных;
    
    - изменений полномочий субъектов доступа и статуса объектов доступа.
    

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

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

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

  • Ronan Dunklau
    Ronan Dunklau Dalibo DBA
    45 мин

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

    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.

  • Борис Верюгин
    Борис Верюгин ООО "Диасофт Платформа" Руководитель управления развития
    45 мин

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

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

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

  • Александр Коротков
    Александр Коротков Postgres Professional Руководитель разработки
    45 мин

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

    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 ...", как один из механизмов расширяемости.

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