PgConf.Russia 2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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