Пост-релиз
Доклады
Архив докладов
-
Николай Шаплов Postgres Professional Fuzzing EngeenerЗнание внутреннего устройства СУБД на уровне хранения данных позволяет ускорить её работу и уложить данные более компактно. На данном мастер-классе будет представлен инструмент pageinspect, одним из разработчиков которого недавно стал московский программист Николай Шаплов. На практике этот инструмент будет использован для изучения того, как в БД лежат данные и как их можно разложить оптимально. Будут и задачи для самостоятельного исследования.
-
Валентин Гогичашвили Zalando Head of Data EngineeringСтремительно стартовав в 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 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 ...", как один из механизмов расширяемости.
В докладе будут продемонстрированы текущие результаты в области подключаемых индексных методов доступа, а также концепция подключаемых хранилищ.
-
Дмитрий Долгов Zalando SE Senior Software EngineerИспользование слабоструктурированных данных определенно является трендом современности, и это верно не только для NoSQL, но и для традиционных RDBMS. Многие реляционные базы данные (например, PostgreSQL, Oracle, db2, Mysql) позволяют хранить данные в json формате, и, очевидно, реализуют это по-разному.
Доклад содержит две части:
- Сравнение поддержки json в PostgreSQL и других реляционных базах данных, а именно Mysql, Oracle, db2, MSSql в контексте реализованных возможностей, функций и т.д.
- Сравнение производительности для баз с наиболее полной поддержкой json (PostgreSQL и Mysql) а также MongoDB на различных видах нагрузок и конфигураций.
Фотографии
Архив фотографий