title

text

Alvaro Hernandez
Alvaro Hernandez 8Kdata CTO
16:00 05 февраля
45 мин

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

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

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

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

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

Слайды

Видео

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

  • Pavel  Stehule
    Pavel Stehule

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

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

  • Kevin  Grittner
    Kevin Grittner EnterpriseDB

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

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

  • Ильдар Мусин
    Ильдар Мусин Postgres Professional Разработчик
    22 мин

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

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

  • Marco Slot
    Marco Slot Citus Data Главный инженер-программист

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

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