Дорогие коллеги, рады предложить вашему вниманию второй выпуск нашей новой рубрики «интервью с разработчиками баз данных». Мы поговорили с Иваном Фролковым, разработчиком компании Postgres Professional. Иван занимается прикладной разработкой для баз данных уже свыше 20 лет. Сегодня, Иван приокроет завесу тайны и поведает про новые интересные возможности «отечественного Посгреса», Postgres Pro: EE.
PG Day: Расскажи немного, пожалуйста, как давно ты занимаешься базами данных и вообще в профессии состоишь, в каких амплуа и так далее.
ИФ: Я начал заниматься базами данных, это был 93 год и делали мы такую страшную вещь, как реестр акционеров. Была у нас тогда, если кто помнит, ваучерная приватизация. Писали мы его на клиппере. Тогда особых вариантов, в общем-то, и не было: Fox Pro, Clipper и, по-моему, все.
По каким-то юридическим соображениям у нас компания была из нескольких ветвей, который друг друга дублировали. Приходилось с ними обмениваться информацией. У них тоже был этот реестр акционеров написан на клиппере. Там было очень много частных лиц, ваучерная приватизация, все дела. Что меня особо потрясло, первые несколько экранов состояли просто из двоичного мусора, как будто там побились файлы данных, там была всякая белиберда. После белиберды шли просто пустые поля, и дальше уже начинались имена, фамилии и отчества. Я тогда задался вопросом: а насколько мы можем доверять тому, что нам кажется нормальными, имея вот такую фигню в самом начале? Это первое у меня было здравое суждение – был год 94-й. Потом я перешел работать в компанию, которая обслуживала Министерство финансов Российской Федерации. Я отвечал за ведение реестра аудиторов Российской Федерации, тогда были реестры, аттестаты, лицензии на выполнение аудиторских операций. Был у нас SQL Server 6.0, 6.5, 7.0 и Delphi.
Дальше я несколько пофриланствовал. Потом я оказался в Mail.Ru. Делал я там открытки, рассылки, ответы. После Mail.Ru занимался стартапами. Все было связано с базами данных в той или иной форме. В конце концов, я оказался тоже в своего рода стартапе, но профессиональном. Занимаюсь базами данных PostgresSQL, преимущественно оптимизацией запросов и написанием разнообразных документов, чем меня, честно говоря, очень утомили.
PG Day: ты говоришь, что занимаешься оптимизацией запросов. Что все-таки ты подразумеваешь? За что в Postgres Pro ты там отвечаешь? Насколько я знаю, определённые патчи, версии идеологически тобой придуманы.
ИФ: Идеологически я долго ходил и ныл, что в Postgres очень скверное секционирование. Наконец секционирование сделали, и я его, естественно, с ранних версий гонял. Сейчас оно себя весьма неплохо показывает. Остались только две очень критичные вещи: в нем нет глобальных индексов и нет отдельных секционированных индексов. И он не очень хорошо работает с числом секций свыше 20-30 тысяч. Базы сейчас большие, и хотелось бы иметь сотни тысяч, до миллиона секций для сверхбольших объемов. Ребята стараются, я хожу и ною, они пишут. Надеюсь, как-то повлияю.
Второе, на что еще я повлиял – это отчуждаемые таблицы. Пожалуй, я их придумал, а реализовала Настя Лубенникова, большое ей за это спасибо. Идея заключается в том, что на одном сервере можно подготовить таблицу с данными, “провакуумить" ее, индексы построить, статистику, отключить и подключить к другому серверу уже готовенькую.
Непосредственно я занимаюсь интеграцией с приложениями. Единственное, что могу сказать, для .net я не пишу, к счастью или сожалению. Ко мне попадаются Java, PHP. И мне еще сваливается “Вот у нас есть запрос, надо было бы его как-то разогнать”. Я его разгоняю. Мне еще дали подручных ребят. Ребята толковые, мне нравятся. Вот разгоняем.
PG Day: на предстоящем PG Day ты собираешься читать очень подробный мастер-класс про Enterprise версию Postgres Pro, которую вы разрабатываете. Как так сложилось, что именно ты читаешь этот мастер-класс, который посвящен функциональным возможностям этой версии? И второй мой вопрос: действительно ли она настолько насыщена новыми возможностями, что достойна многочасового мастер-класса?
ИФ: я всегда себя считал прикладным программистом. Не тот, кто пишет СУБД, а тот, кто ее использует. Я думаю, что мастер-класс будет ориентирован, прежде всего, на людей, которые непосредственно пишут код. Не тот код, который в СУБД, а который когда приходит Марья Иванна и говорит «Я что-то нажала, и все исчезло».
Насколько версия интересна разработчику? Да, там есть очень интересные возможности. Я уже упоминал отчуждаемые таблицы. Эта задача возникла из требований одного клиента, у которого периодически сваливались данные с такой скоростью, что он их просто не успевал вставлять в базу. Отсюда вытекает требование большого количества секций в таблице, для очень больших объемов данных.
Еще, тоже с моей подачи, сделали очень маленький и очень приятный модуль pg_variables. Это сессионные переменные. Они живут во время сессии и локально для сессии. В общем-то, с одной стороны, ничего сверхъестественного нет. С другой, почему-то до сих пор этого не было сделано. Это, в частности, тоже критично для пользователей, которые переходят с Oracle, потому что там есть пакетные переменные. В Postgres с этим не все так хорошо.
Третья вещь: у нас активно ведется разработка мультимастера. Это действительно настоящий мультимастер. Я вообще говоря, довольно много считал всяких денег, не конкретно банковский “опердень” пресловутый, но биллинги и прочие штуки. Владелец или менеджмент очень хотят знать точно, что и как происходит с деньгами. Поэтому я к вопросам транзакционной целостности и консистентного представления данных отношусь с большим вниманием. В нашем мастере это действительно обеспечивается. Он реально master-master. Все нормально работает. Никакого там шарлатанства нет. Для разрешения конфликтов придется откатывать транзакцию, которая не смогла выполниться.
Сейчас его здорово подтянули, прямо на глазах улучшается. Это показала история с одним нашим клиентом, у него достаточно заковыристая логика в hibernate. Про некоторые транзакции он не может сказать, читающие они или пишущие. Его задание нормально отработало, причем отработало на мультимастере в 2.5 раза шустрее, чем на голом ванильном Postgres.
PG Day: Да, звучит очень впечатляюще. Ты упомянул проблему разрешения конфликтов между узлами, что транзакция откатывается и так далее. Мне всегда казалось, что эксплуатация мультимастера подразумевает, что будут проблемы и их нужно как-то решать: вмешиваться вручную, чтобы восстановить нормальное функционирование.
ИФ: В данном случае при выполнении операций мультимастера фактически происходит синхронная репликация и потом честный, совершенно нормальный двухфазный commit. Да, он тяжелее чем обычный commit, никто не спорит. Но, с другой стороны, это в случае большого количества чтений даёт выигрыш, потому что там получается, как минимум, три “ноды” в мультимастере и, соответственно, производительность на чтение в три раза возрастает. Да, должен отметить, что весьма актуально для таких случаев, драйвер JDBC, позволяет перечислять различные сервера в строке соединений. То есть на случай отказа, например, он автоматически может переподключать.
Он может по чистой производительности отстает от ванильного, все-таки требуется синхронизация с другими серверами. Естественно, это накладывает некоторые ограничения. Но, с другой стороны, он у нас получается реально рабочим, катастрофоустойчивым решением.
Еще из возможностей есть компрессия таблиц, которые ориентированы преимущественно на чтение. Правда, появляется очередная разновидность вакуума, называется сборщик мусора. Например, большинство огромных таблиц, которые мне попадались – это, фактически, append-only таблицы. Госструктуры, например. У них происходит событие, они их регистрируют. Событий много, но событие произошло, и оно неизменное. И в этом случае сжатие данных в основном дает заметный выигрыш на вводе-выводе. Здесь даже речь идет не о размере на диске, потому что диски сейчас большие, но зато мы очень сильно выигрываем на чтении, на вводе-выводе.
PG Day: Есть ли у тебя какая-то фича enterprise версии, которая является твоим личным фаворитом?
ИФ: Как ни странно, мне больше всего нравится, с точки зрения, что надо сесть и писать код для чего-то, простенький pg_variables. Он без претензий, но удобный. Наиболее серьезной возможностью я, конечно, считаю мультимастер.
PG Day: Насколько я помню, в плане мастер-класса, который ты заявлял, был пункт про вложенные транзакции и автономные транзакции. Вкратце расскажи, что у вас запланировано по этому вопросу?
ИФ: Первая возможность с использованием автономных транзакций, которая обычно требуется – это логирование. Пользователь выполняет такую-то операцию, вдруг у него rollback происходит, все данные теряются. Может, он хочет что-то нехорошее сделать и было бы неплохо это учесть. С автономными транзакциями мы можем регистрацию этой операции проводить внутри отдельных транзакций, совершенно независимо от основной операции. Есть еще такой тонкий момент, когда без этой автономной транзакции либо без внешнего приложения ничего сделать не получится. Например, я с этим столкнулся, когда нужно было отправлять биткойны.
В биткойнах какая ситуация? Там есть глобальная главная книга бухгалтерская, blockchain называется, в нее пишутся транзакции: со счета такого на счет такой-то такая-то сумма. Совершенно стандартно. Все несколько хитрее, но для простоты предположим, что это так. Проблема заключается в том, что транзакция становится истинной, когда ее подтвердят другие участники обмена. То есть мы, отправляя транзакцию, не знаем, прошла она или нет. Мы отправили деньги, и не исключено, что потребуется их переотправить. На такое может нарваться раз в месяц, предположим. Мы выполняем операцию по отправке денег, а транзакция потом взяла и откатилась. Да, мы честные люди, мы не будем делать double-spending, но как-то странно закладываться в коде на честное слово, так что мы это ни откатить не можем, ни проверить, прошла она или нет.
Двухфазный commit у нас не получается по очевидным причинам, а если бы могли проверить – тогда мы могли бы реализовать свойство идемпотентности, что отправляли уже, и больше не будем. То есть в итоге результат выполнения мы не знаем. Мы отправить можем только один раз и надеяться на то, что все будет хорошо. В рамках СУБД мы это никак не можем сделать. Когда транзакция откатывается, с точки зрения прикладного программиста, вроде как и не было ничего, стало быть, с одной стороны мы должны зафиксировать факт попытки выплаты, а с другой — при откате все теряется.
PG Day: Без сторонней помощи уже не разобраться.
ИФ: Если мы это делаем из прикладной программы, мы можем открыть второе соединение и попытку отправки регистрировать отдельной транзакцией. Причем сначала регистрируем, что пытаемся отправить, и потом уже отправлять. Внутри СУБД без автономных транзакций такое сделать, к сожалению, невозможно. С автономными транзакциями такое вполне реализуемо. Что еще? Это вторая задача, которая возникает – избежать повторного выполнения отменяемых операций.
Еще я буду рассказывать об интересной возможности scheduler – выполнение заданий по расписанию. Она доступна из pl/pgsql, можно так вызывать запросы, плюс она еще интересна задачами. Можно отправить задачу на выполнение. Что в нашем шедулере интересно? У нас задания могут зависеть одно от других. То есть, такое-то задание не будет выполнено, прежде чем не будут выполнены другие.
PG Day: то есть, уже какую-то бизнес-логику можно программировать таким образом.
ИФ: Да, если помнишь, у меня в mbus были упорядоченные сообщения.
Вот как раз это реализация той же логики. То есть, мы некую операцию можем проводить в несколько шагов. В случае, если она не выполнится, мы должны опять же в несколько шагов ее откатить. Для него сейчас делают интерфейс пользовательский, посмотрим, что получится. Пока что он доступен только в API.
PG Day: звучит очень внушительно, много всего интересного. У нас некоторые участники высказывали скепсис, что не будет ли это просто маркетинговым докладом, где ты будешь рассказывать, что все эти фичи очень крутые. Планируешь ли ты какую-то практику, примеры, чтобы участники могли убедиться, что это действительно круто? Можно ли ожидать демонстрацию с наглядными примерами?
ИФ: Планирую. Раздавать я версию Postgres Pro EE не планирую, но сам все покажу на своем компьютере. На тему того, какие крутые фичи, рассказывать естественно буду. Зачем тогда вообще рассказывать, если бы было плохо?
Мастер-класс будет интересен особенно для людей и организаций, которые действительно размышляют о том, чтобы воспользоваться нашим продуктом. Я надеюсь, что данный семинар будет полезен ровно для того, чтобы какие-то опасения развеять, показать новые возможности, а может быть, и продемонстрировать пока не осознаваемые проблемы…
Если бы я хотел заниматься маркетингом, я бы в первую очередь рассказывал о том, что у нас есть лицензия ФСТЭК, и мы для одного заказчика сделали проект с уровнем секретности «государственная тайна». Да, далеко не всем это надо — даже, пожалуй, мало кому, но кому надо — тем действительно надо. Помимо этого, мы можем обрабатывать персональные данные на самом высоком уровне («1 группа — специальные категории ПДн, к которым относятся информация о национальной и расовой принадлежности субъекта, о религиозных, философских либо политических убеждениях, информацию о здоровье и интимной жизни субъекта»). Для медицины это ограничение вполне может быть критичным. Если бы я занимался маркетингом, я бы рассказывал вот это. Потому что для ряда применений это просто убойные требования. Но я не буду.
PG Day: Что бы ты посоветовал начинающим DBA, на какую технологию посмотреть, чьи статьи и блоги почитать?
ИФ:
1. Внимательно прочитать книжку Architecture of a Database System.
2. Не менее внимательно изучить документацию к используемой СУБД.
3. Изучить основы бухгалтерского учета. Во-первых, оно просто чисто житейски полезно, во-вторых, станет понятно, откуда появились требования к СУБД…
4. Следите за всеми основными СУБД, благо их немного.
5. Очень рекомендую с ними ознакомиться — в первую очередь с Oracle и DB2, тем более, что этого хватит надолго — штуки это очень серьезные.
Я лично читаю списки рассылки Postgres, но не думаю, что это обязательное для всех чтение.
PGDay: И в заключение, с точки зрения использования для работы и в личном быту какими операционными системами, приложениями и техникой пользуешься?
ИФ: Ничего неожиданного — дома у меня старенький ноутбук с Windows 10, иначе жена с дочкой не поймут, и маленький разъездной с убунтой — опять же плюс, домашние туда из-за убунты туда в принципе не полезут, все мое. На работе — обычный Debian. Из приложений — важнейшим приложением для программиста является Word (или Libre Office), как известно; а так — vi, psql, pgAdmin3 и Netbeans — привык я к нему.
Разработка нового форка — задача масштабная. К сожалению, мы не смогли уместить все подробности об отечественной разработке в рамки 30-минутной беседы. Друзья, обязательно задавайте свои вопросы, Иван и его коллеги будут очень рады. Ну а мы спешим пригласить всех в на PG Day'17 Russia. Иван проведет workshop Postgres Pro Enterprise для разработчиков, в рамках которого в подробностях расскажет про те возможности форка, которые уже были упомянуты в интервью, и многие другие. Вас также ждет множество интересных докладов от коллег Ивана: Олега Бартунова, Александра Короткова, Ивана Панченко и других специалистов компании Postgres Professional.
До встречи на PG Day'17 Russia!
Автор: PG Day'17 Russia
