Расширяемость 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 ...", как один из механизмов расширяемости.
В докладе будут продемонстрированы текущие результаты в области подключаемых индексных методов доступа, а также концепция подключаемых хранилищ.
Слайды
Видео
Другие доклады
-
Heikki Linnakangas Pivotal PostgreSQL hackerВнутреннее устройство индексов
PostgreSQL поддерживает несколько типов индексов: GiST, SP-GiST, GIN и, конечно, обычное B-дерево. Администраторы БД знают, когда применять каждый из них: GIN для полнотекстового поиска, GiST для геометрических данных и т. д., но как они устроены внутри? Благодаря чему они хорошо работают в сценариях использования, для которых предназначены? В этой презентации я познакомлю вас с внутренней структурой каждого из этих типов индексов и расскажу, каковы их сильные и слабые стороны.
-
Юрий Соболев ООО "МедиаТех" Генеральный ДиректорPostgreSQL как ядро биржи интернет-рекламы Adsterra.com
Общая информация об 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 таблицы. Но с умом.
Текущие разработки и нерешенные проблемы
- Реализация колоночной аналитики штатными средствами.
- Проблемы странных планов запросов.
- Логическая репликация мечты
- Мультимастер...
-
180 мин
Алексей Лесовский PostgreSQL Consulting LLC Администратор баз данныхПотоковая репликация на практике.
Потоковая репликация это одна из тех прорывных технологий которая вывела PostgreSQL на совершенно новый уровень. Сочетая в себе легкость настройки, высокую производительность и почти неограниченную масштабируемость потоковая репликация является эффективным инструментом, а ее наличие становится неотъемлемым компонентом любого постгресового "сетапа". Более того, в процессе дальнейшего развития PostgreSQL, потоковая репликация продолжает развиваться и обзаводиться новыми функциями (каскадные конфигурации, слоты репликации) вплоть до того, что на данном этапе своего развития, потоковая репликация позволяет выстраивать bi-directional replication конфигурации.
Из доклада вы узнаете о том, как устроена потоковая репликация снаружи и внутри, и о практических аспектах эксплуатации потоковой репликации включая такие вещи как настройка, сопровождение, мониторинг, поиск и устранение проблем.
Участникам мастер-класса следует скачать себе образ виртуальной машины для KVM, Virtual box или VMWare, распаковать его (gzip2) и запустить виртуальную машину.
Если у Вас нет ни одной из перечисленных программ для виртуализации, то нужно запустить виртуальную машину с CentOS 7 и установленным postgresql из оф.репозитория yum.postgresql.org.
Ссылка на образы для скачивания: https://goo.gl/Yy4UzH
-
45 мин
Анастасия Лубенникова Postgres Professional РазработчикНовые возможности B-tree в PostgreSQL
Самый часто используемый тип индексов в PostgresSQL - B-tree. Эта структура данных и связанные с ней алгоритмы развиваются уже больше 40 лет. Но, как мы знаем, нет предела совершенству. В этом докладе пойдет речь об особенностях структуры B-tree и его реализации в PostgreSQL, важных для оптимального использования индексов. Кроме того, мы представим улучшения функциональности B-tree в PostgreSQL, которые войдут в релиз 9.6. Это компрессия дубликатов и новые возможности использования покрывающих (covering) индексов.