Онлайн-встреча с ведущими экспертами PostgreSQL, 30 июня 2008
30 июня компания «Постгресмен» провела онлайн-сессию «Вопросы к ведущим мировым экспертам PostgreSQL». В течение трёх часов любой желающий мог задать вопрос одному из приглашённых гостей и получить исчерпывающий ответ. В результате было получено более 40 вопросов, ни один из которых не остался без внимания.
Участники сессии:
- Брюс Момджан (Bruce Momjian), координатор разработки PostgreSQL, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB.
- Максим Богук, ведущий администратор баз данных компаний Rambler и Мастерхост, известный специалист по PostgreSQL.
- Фёдор Сигаев, разработчик подсистемы полнотекстового поиска, систем индексации GiST, GIN и множества дополнительных модулей, один из основных членов PostgreSQL Global Development Group.
- Марко Креэн (Marko Kreen), один из основных архитекторов баз данных компании Skype, разработчик и мантейнер таких проектов как PL/Proxy, Skytools, PgBouncer и pgcrypto.
Вопрос №1
Сергей Коноплёв:
Вопросы к Марко Креэн:
1) Когда планируется реализовать механизм контекста ошибок (errcontext mechanism) в plpython?
2) Мы используем try-except-print-traceback решение для упрощения поиска мест ошибок в plpyhton процедурах, есть ли более эффективный способ?
Марко Креэн, инженер компании Skype:
1) Я не являюсь активным разработчиком PL/Python, лучше всего об этом может рассказать Ханну Кросинг (Hannu Krosing), который сейчас поддерживает этот проект.
2) Если Вы говорите об ошибках Python, тогда да, действительно, механизмы работы с исключениями должны быть улучшены, чтобы предоставлять больше подробностей об ошибке. Если имеются в виду SQL-ошибки, в их обработке существуют довольно большие проблемы, и я не знаю, имеет ли Ханну какие-либо планы по их устранению. В настоящий момент лучше пытайтесь обойтись без их отлова.
Вопрос №2
kai:
Появится ли когда нибудь официальный русскоязычный ресурс по Postgres с русской документацией, обсуждениями и русскоязычным сообществом? Ведь продукт сложный, обладает большим функционалом и кучей дополнительных модулей. Подчас сложно бывает разобраться со всем этим обладая только англоязычной документацией и общаясь с англоязычным коммунити. (Однако при установке новой версии при прочтении соглашения ведется ссылка на русский док, а там перенаправление на «как обычно».)
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
В русскоязычном списке рассылки http://archives.postgresql.org/pgsql-ru-general/ Вам всегда ответят на все Ваши вопросы. Также достаточно большая активность есть на форумеhttp://www.sql.ru/forum/actualtopics.aspx?bid=7. Дополнительно, обратите внимание на ресурс «Постгресмена» (компании-организатора этой конференции), разделы «Новости» и «Cтатьи».
Вопрос №3
kai:
Одна из досадных штук в работе — это отсутствие конструкции "INSERT OR UPDATE". В MySQL можно сделать так: "INSERT INTO users (username, email) VALUES ('Jo', '') ON DUPLICATE KEY UPDATE email = ''". Появится ли что-нибудь похожее в PostgreSQL?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Стандартный (ANSI) способ для таких вещей — это MERGE или UPSERT. Оба способа находятся у нас в TODO-листе и, насколько я знаю, кто-то работает над этой функциональностью для PostgreSQL 8.4, хотя лично я ещё не видел этого патча. Мы, вне всяких сомнений, нуждаемся в таком синтаксисе.
Вопрос №4
kai:
Будет ли улучшена работа с обработкой данных на различных языках? Например, у меня многоязычный сайт, и я был бы рад получать для него форматированные из timestamp даты в зависимости от указанной в SQL запросе локали.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Работа над этим ведётся, но в основном она сосредоточена в области COLLATION и полнотекстового поиска. Первое, с чем надо разобраться — это хотя бы создание базы с локaлью, отличной от локали кластера. А формирование даты обычно намного проще и гибче делается в приложении.
Вопрос №5
Alexander:
Вопросы к разработчикам Skype:
1) Хочется оценить масштабы Skype, хотя бы приблизительно. Сколько пользователей сейчас зарегистрировано? Сколько пользователей находятся одновременно онлайн? Сколько транзакций в секунду выполняет Ваш PostgreSQL? Сколько у Вас серверов PostgreSQL?
2) Как правильно померить количество транзакций в секунду в PostgreSQL?
Марко Креэн, инженер компании Skype:
1) Общее количество пользователей у нас сейчас в районе 300 миллионов. Я точно не знаю насчёт активных пользователей, но мой Skype-клиент показывает, что сейчас онлайн находятся 10 миллионов пользователей, и это далеко не пиковая нагрузка. У меня нет точных цифр по количеству транзакций в секунду (TPS), но, кажется, наша нагрузка — где-то в районе 10-20 тысяч TPS. Всего у нас более 100 серверов PostgreSQL, хотя и не все из них работают одновременно.
2) Используйте анализатор логов или pgBouncer, установленный перед базой данных, он даёт такую статистику.
Вопрос №6
Сергей Коноплёв:
Планируется ли реализация механизмов для повышения производительности OLAP-функционала? Если да, то где можно найти информацию об этом?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Не могли бы Вы уточнить, какая OLAP-функциональность Вам необходима? У нас в TODO-листе есть windowing-функции, и кто-то работает над ними для 8.4. У нас также уже есть WITH RECURSIVE патч для PostgreSQL 8.4.
Сергей Коноплёв:
Спасибо за ответ. Имелись ввиду внутренние механизмы, улучшающие производительность.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мне кажется, Вы имеете в виду фунциональность CUBE. Вы пробовали contrib/cube?
Сергей Коноплёв:
Да, я имел ввиду работу с гиперкубами, насколько я могу судить по названию контриба. Нет, contrib/cube не пробовал, а где страница этого проекта? Я не могу её найти. Не знаю, возможно я перемудриваю, но по-моему было бы полезно реализовать ondisk-гиперкубы в ядре. Насколько я понимаю, это должно представлять собой авто-пополняемую таблицу с индексами по перестановкам всех полей.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Contrib/cube является частью дистрибутива исходных кодов PostgreSQL.
Вопрос №7
Сергей Коноплёв:
У нас есть задачи генерации событий на основе операций в БД: добавление/изменение/удаление. Это, конечно, можно делать в триггерах, но на уровне WAL файлов IMHO это было бы эффективнее, не говоря о том, что обработку можно было бы делать отложенной и вынесенной. Вопрос - есть ли хорошо документированный API для работы с WAL файлами и, если есть, насколько сильно он будет меняться от версии к версии? Если да, то где можно найти информацию об этом?
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Внешнее API отсутствует, поскольку никогда не предполагался внешний доступ к WAL-файлам. Более того, их формат совместим только для минорных версий, гарантии совместимости форматов между major-версиями никогда даже не предполагалось. В Постгресе даже нет центрального расшифровщика WAL-записей, каждая запись в некотором смысле контейнер, который имеет признак расшифровщика (таблица, btree-индекс, GiST-индекс и т.д.) Строить свою обработку на WAL-логах не очень удобно ещё и по следующей причине: файлы могут использоваться повторно, и Постгрес никак не оповещает внешний мир об этом.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
То есть, Вы ищете способ чтения WAL-файлов напрямую? Не существует никакого API для этого, так как их внутренний формат достаточно сложен. Я сейчас понял, что возможность чтения логов могла бы быть полезной, возможно, нам стоит рассмотреть вопрос о включении этого пожелания в TODO-лист. У нас есть на самом деле pg_filedump (http://sources.redhat.com/rhdb/utilities.html), но я не уверен, что он дампит WAL-файлы.
Марко Креэн, инженер компании Skype:
Может быть, это более эффективно, но менее надёжно (например, WAL-файл может сротироваться без вашего ведома). Пожалуйста, попробуйте PgQ из пакета Skytools и поизучайте скрипты, которые используют этот механизм для организации очереди. Это очень эффективная очередь внутри базы данных, легкая в использовании и надёжная. Также в ней существуют встроенный фреймворк для того, чтобы гарантировать транзакции между несколькими базами данных при обработке очереди. Ещё в ней существуют триггеры, которые автоматически определяют структуру таблиц и форматируют данные в легко разбираемом формате (urlencode).
Вопрос №8
sakalr:
Вопрос по поводу книг. Сегодня мне пришла книга из британского Амазона, пришлось ждать несколько недель. В России из актуальных версий нашёл только книгу за 3900 рублей. В общем, пусть книги будут даже на английском, но я хочу прийти в «Библио-Глобус» или в «Молодую Гвардию» и увидеть эту книгу на полке, но не за 3900 рублей (на Амазоне эта же книга была в 2 раза дешевле). Есть потребность в разработке на PostgreSQL, но для меня, как для новичка в PgSQL, это сложно. Постоянно приходится общаться на freenode на ломаном английском, осваивать азы, потратив много времени, когда это должно быть просто механическим усвоением. Именно поэтому возникает вопрос про книги. Книги по postgresql (англ./рус.) очень нужны.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Если Вы уже знакомы с каким-либо диалектом SQL, то работа в Постгресе не должна причинять Вам большие неудобства. Документация в Постгресе очень хороша и ее обычно хватает (при внимательном чтении, конечно). Если Вы не знакомы с SQL, то лучше взять любой учебник по SQL.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Я полностью согласен с тем, что нужно больше английских и русских книг. В идеале, нам нужно иметь переведённую на русский язык документацию по PostgreSQL.
Вопрос №9
yar-tour:
Здравствуйте! Интересует вопрос про поддержку COLLATION и поддержку установки триггеров на отдельные поля таблицы. Спасибо.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Ух, мы еще не релизовали механизм COLLATION, но кое-кто уже работает над реализацией поддержки локалей (locales) на уровне баз данных для PostgreSQL 8.4. Колоночные триггеры занесены в наш список TODO, но мне не известно, работает ли кто-нибудь над этим в настоящее время.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
COLLATION — насколько я помню, такие работы ведутся в 8.4, но пока этот патч не до конца прошёл процедуру принятия. Триггер на поле таблицы отсутствует, и пока его появление не предвидится. Его эмуляция легко строится на основе обычных триггеров: триггерная функция имеет доступ и к старой, и к новой версии записи.
Вопрос №10
alexanderfess:
Здравствуйте! Интересует, есть ли в области Postgres что-то мощнее pgAdmin или phpPgAdmin для разработчика БД. ИМХО они довольно слабые. Планируются ли какие-нибудь проекты в данной области?
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Не знаю, я ими не пользуюсь. Да и сам Постгрес не включает себя графического клиента.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Я не знаю более мощных утилит, кроме, возможно, коммерческих продуктов Navicat или EMS SQL Manager. Я никогда не пользовался такими средствами (http://www.freshee.info/program.php?id=31408).
Вопрос №11
Михаил Дружинин:
Здравствуйте. К вопросу про генерацию событий на основе операций в БД: добавление/изменение/удаление. Есть ли возможность сделать обработку отложенной/асинхронной? Чтобы результат обработки не мог повлиять на транзакцию и не замедлял ход её выполнения.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Обычно в этом случае разработчики добавляют изменения в таблицу и обрабатывают их большими пачками позднее.
Марко Креэн, инженер компании Skype:
Попробуйте Skytools. Они содержат модуль для создания обобщенной очереди (PgQ) и простые в использовании триггеры для вставки событий в эту очередь. Skytools также содержит фреймворк для обработки очереди на языке Python, хотя Вы можете это сделать и на любом другом языке. Чтобы прочитать событие из очереди, достаточно пары вызовов SQL-функций.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Триггер по определению обязан отработать в транзакции, поэтому чисто триггерное решение отложенной обработки невозможно. Первое, что напрашивается, — это складывание триггером событий в таблицу или использование механизма LISTEN/NOTIFY. Кстати, в PostgreSQL 8.4 ожидаются улучшения этого механизма: будет возможно добавить строковый параметр к NOTIFY-событию.
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Чтобы результат обработки не мог повлиять на транзакцию и не замедлял ход её выполнения, проще всего скидывать триггером задания на обработку в отдельную таблицу и уже далее асинхронно обрабатывать задания внешним процессом + возможно использовать LISTEN/NOTIFY для уведомления процесса-обработчика о появлении нового задания в очереди.
Вопрос №12
Артем Ходлевский:
Здравствуйте. У меня вопрос такой: могут ли эксперты порекомендовать способ поддержки значительного количества систем, в условиях довольно интенсивной разработки? Код весь находится в SVN-репозитории, а для обновления существующих систем приходится делать большое количество ручной/рутинной работы.
Если нужно, могу уточнить вопрос:
Есть базы данных, уже установленные и работающие, их количество более десяти. Но в процессе дальнейшей разработки структура меняется (добавляются поля, добавляются/модифицируются хранимые процедуры), эти изменения попадают в инициализационный SQL-сценарий (хранится в SVN). Как сделать удобным (возможно, полуавтоматическим) применение этих изменений ко всем системам, то есть, апгрейд существующих БД? Мы частично решили эту проблему — ведём параллельный SQL-сценарий, который содержит команды, которые выполняют изменения (ALTER / CREATE OR REPLACE), но его поддержка требует от разработчиков очень большого внимания, а малейшие ошибки потом приводят к конфликтам или сбоям.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Да, это «больной вопрос». Для автоматизации могу только посоветовать http://apgdiff.sourceforge.net/.
Артем Ходлевский:
Спасибо за ответ, как-то мы не очень искали сторонние инструменты, думали для этого есть штатный способ. Будем пробовать.
Вопрос №13
algo:
Когда STATEMENT TRIGGER получат доступ к записям?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Я слышал о том, что кто-то работает над тем, чтобы STATEMENT TRIGGER мог получать доступ к записям. Точно не знаю, какое именно API мы должны сделать для этого.
Вопрос №14
yar-tour:
Вопрос всем и особенно Брюсу, которого я очень рад встретить: каким вы видите развитие PostgreSQL на ближайшие пару лет?
Марко Креэн, инженер компании Skype:
Я предполагаю рост, конечно. Следующие два года имеют один интересный аспект: PostgreSQL имеет шанс заменить MySQL как самую популярную систему управления базами данных с открытым кодом. Но сможем ли мы сделать это? Саморазрушения MySQL, которое происходит в настоящее время, будет недостаточно, нам самим потребуется решить несколько важных проблем — в частности, создать лёгкую в использовании репликацию, лёгкий при построении кластер, встроенную систему апгрейдов. Всё это сделало бы PostgreSQL более удобным для большего количества пользователей.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Это, кстати, тема моей последней презентации, «Путь PostgreSQL в будущее» (http://momjian.us/main/writings/pgsql/future_path.pdf [PDF]). Мне кажется, что Постгрес двигается к тому, чтобы занять лидирующее место в индустрии систем управления базами данных. Всё свидетельствует об этом — активная разработка, компании, которые используют Постгрес, пресса, мнения людей и т. д. Я только что был на конференции OSCON, и там интерес к Постгресу был просто невероятен. Может быть, у Вас есть какие-нибудь вопросы по моему PDF?
yar-tour:
Не могли бы Вы назвать несколько больших компаний, которые начали интересоваться PostgreSQL в последнее время? Также интересно услышать про приложения сторонних разработчиков.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Конечно, у нас есть крупные пользователи почти во всех сегментах индустрии. Это технология, производство, правительственные учреждения, розничная торговля, сервисные компании, финансовые учреждения. Например, на конференции OSCON на прошлой неделе оказалось, что глава всего IT-направления компании Google любит Постгрес, хоть в Google и используют MySQL. Он взял футболку с Постгресом и будет носить ее в офисах Google. Кажется, сегодня уже каждый слышал про Постгрес — совсем не так дело обстояло всего несколько лет назад, когда мы были почти неизвестны. Мы нравимся даже разработчикам MySQL.
Нам нужно больше приложений сторонних разработчиков — мы растём недостаточно быстро в этом направлении, хотя многие приложения разрабатываются в расчёте на то, что они будут поддерживать несколько баз данных и вполне поэтому могут добавить себе поддержку Постгреса.
Вопрос №15
algo:
Уважаемые разработчики, а хранимые битмап-индексы когда планируются?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Кто-то их уже реализовывал, но тогда возникла проблема с тем, как vacuum будет чистить такие индексы, ведь это индексы с потерями (lossy).
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Разработчик этого патча вроде бы потерял интерес к нему в первую очередь из-за нерешённой проблемы автоматического вычисления длины bitmap и возможного полного перестроения индекса. Воoбще говоря, on-disk bitmap индекс имеет очень ограниченную область применения и очень плохо автоматизируется (если Вы его используете, значит, Вы должны очень хорошо подумать).
Марко Креэн, инженер компании Skype:
Существует патч для этого. Вы можете посмотреть в архивах рассылки или спросить разработчиков о его состоянии.
Вопрос №16
Юрий Леонович Русинов:
Здравствуйте! Я разрабатываю подсистему поиска в базе геоданных на основе связки PostgreSQL + PostGIS. Хотелось бы запускать поиск на сервере БД в виде отдельного потока, насколько это возможно?
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Не понял. Что значит — отдельного потока? Постгрес сам по себе не умеет использовать больше одного потока (на самом деле — процесса) для обработки одного SQL-запроса. Видимо, Вас может удовлетворить использование нескольких соединений к Постгресу.
Вопрос №17
yar-tour:
Это баг или фича, что AFTER-триггер может прерваться, например, из-за ошибки в процедуре, и записи при этом не добавятся? В случае с BEFORE-триггером это логично, а вот мне кажется, что AFTER-триггер должен работать только после добавления записи в таблицу, это как бы вытекает из его названия.
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Это вполне логичная фича. Так как даже AFTER-триггер выполняется внутри транзакции (даже если включен автокоммит, это только значит, что любая команда будет формально в BEGIN; COMMIT; завернута). Поэтому ошибка в AFTER-триггере, как и любая вообще ошибка внутри транзакции, будет вызывать откат транзакции (ROLLBACK). И запись, даже уже внесенная в таблицу, на самом деле не появится.
yar-tour:
Извините, тогда я не очень понимаю различия между AFTER- и BEFORE-триггерами...
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Например, если у таблицы есть serial поле или default поле, то при вставке BEFORE-триггер не увидит значения этих полей. А AFTER-триггер уже видит новую запись полностью, включая default поля (и изменения возможно внесенные BEFORE-триггерами). Фактически, BEFORE-триггер работает со значениями, пришедшими от запроса, а AFTER-триггер работает со значениями, реально записанными в базу (а это не одно и то же).
Вопрос №18
kai:
Вот ещё вопросик, про pgAdmin - планируется ли регулярно собирать пакеты под распространенные версии Linux? Например, в Ubuntu 8.04 сейчас pgAdmin 1.8.2 (глючит), а на сайте pgadmin.org уже лежит pgAdmin 1.8.4.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мне сказали, что эти проблемы были исправлены в Убунту (Ubuntu), которым, кстати, я сам пользуюсь. Я думаю, единственной проблемой здесь является заставить разработчиков Убунту обновить сервера для апдейтов. Также отлично работает связка пакетов программного обеспечения с Постгресом для Убунту и, возможно, Вам стóит её попробовать. Там есть PostgreSQL-сервер, pgAdmin и много другого ПО в пакетах, подготовленных Дейвом Пейджем (Dave Page), автором pgAdmin, а не разработчиками Убунту.
Вопрос №19
alrond:
1) Хотелось бы более детальных рекомендаций по тюнингу производительности, а то везде только о shared_buffers написано (чем больше, тем лучше :), все остальное расплывчато.
2) Как насчет обновления базы с версии на версию без необходимости в создании дампа, чтобы не было простоев в работе, если система не кластерная. Может, такое есть и я просто еще не знаю. Имеется в виду смена мажорной версии.
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
1) Все остальные параметры помимо shared_buffers очень сильно зависят от типа нагрузки на Вашу базу. И единого оптимального решения там нет (иначе бы оно уже давно попало в базовый конфиг). Полное руководство по тюнингу Postgres будет представлять из себя хороший такой том килограмм на 5 (лежит у меня дома один такой по Oracle). Полезность его при отсуствии большого опыта достаточно небольшая, а ресурсов на написание и обновление при выходе новых версий будет уходить много. Опыт + понимание принципов + документация на сайте, как правило, достаточны для решения большинства задач тюнинга.
2) Ведутся работы по написанию встроенной upgrade-системы. Но пока она явно не готова. Как промежуточное, но вполне рабочее решение для миграции рекомендуется использовать Slony-I (и эта схема вполне работает, даже для очень больших баз). У нас есть положительный опыт активного использования этого метода для подобных задач в Rambler.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
1) По опыту, люди очень часто забывают менять параметр effective_cache_size и work_mem — они оба очень важны для планировщика/оптимизатора запросов, а второй еще оказывает значительное влияние на время выполнения запроса.
2) Поддержите работу Зденека Коталы (Zdenek Kotala) — это его проект. Там есть очень много сложностей связанных с layout-ом дисковых страниц.
Марко Креэн, инженер компании Skype:
1) Вики на основном сайте Постгреса содержит секцию про настройку производительности: http://wiki.postgresql.org/wiki/Main_Page.
Несколько дополнительных замечаний на основе моего опыта:
* По крайней мере на OLTP-базах большие shared_buffers не являются чем-то необходимым, они просто съедают кэш операционной системы (по крайней мере в Linux).
* Все хотят править postgresql.conf и знают, что нужно сделать, чтобы улучшить производительность, но есть несколько вещей, о которых обязательно стóит помнить (опять же, речь об OLTP-нагрузках):
- Используйте короткие транзакции. Открытые транзакции потребляют ресурсы и открывают много блокировок.
- Чем меньше запросов входит в транзакцию, тем лучше. В идеале — это единственный запрос в autocommit-режиме, который вызывает функцию, содержащую всю логику транзакции. При использовании PL/pgSQL это автоматически приводит к кэшированию планов запросов.
- Используйте небольшое число работающих процессов сервера PostgreSQL (PostgreSQL backends). Каждый запущенный процесс PostgreSQL потребляет ресурсы, даже если он не выполняет транзакций. Это значит, что Вам следует использовать хороший менеджер соединений. Я слышал, что у Java-разработчиков есть собственные решения для этого, во всех остальных случаях я рекомендую pgBouncer.
2) Если действительно хотите минимизировать время простоя, тогда встроенная возможность апгрейда вам не поможет. Единственное по-настоящему работающее решение — реплицировать всю базу данных на другую машину и затем переключить их роли. Может быть сделано с помощью Slony-I или Skytools.
Вопрос №20
kai:
У меня лично есть проблема с распространением изменённых схем между серверами. При удаленной работе у каждого разработчика стоит своя копия БД, собственно если один добавляет новое поле в таблицу, то это нужно сделать всем. И это довольно таки сложно организовать. Посему родился вопрос, не собираются ли разработчики PG расширить инструментарий полезной утилиткой diff для схем БД, что бы к примеру можно было сравнить схему БД из .sql файла и существующей БД? Конечно, такой функционал, как вhttp://www.sqlmanager.net/en/products/mysql/dbcomparer не нужен, но просмотреть разницу между схемами было бы очень удобно.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Нет, боюсь, подобный продукт всегда будет сторонним, не входящим в основной дистрибутив.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Эти задачи как раз и решает (как минимум должен) http://apgdiff.sourceforge.net/.
Вопрос №21
algo:
Eсть много приложений, написанных на MySQL, портировать которые на PG «одним движением пальца» мешает отсутствие в последнем нескольких простых «syntax sugar» фич типа: REPLACE, ON DUPLICATE KEY UPDATE. Планируются ли дальнейшие шаги в этой области? Практическая реализация представляется несложной, а увеличение области применения — значительное. Имеется в виду не принципиальная возможность реализации таких операций, а непосредственно синтаксис.
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Вряд ли кто будет делать такие вещи специально совместимыми по синтаксису с MySQL... Функциональность REPLACE/ON DUPLICATE KEY UPDATE сейчас в работе и скорее всего будет включена в релиз 8.4. Но синтаксис скорее всего будет ANSI, а не MySQL. (Как правило, пройтись глобальным поиском и заменить конструкции на совместимые с PostgreSQL не так сложно, как кажется.)
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Здесь позиция сообщества разработчиков такова: максимально пытаться соответствоать существующему стандарту SQL и не пытаться делать свой синтаксис или повторять чей-то ещё. Именно по этой причине отказались от патча CONNECT BY в пользу WITH RECURSIVE.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Вряд ли мы будем поддерживать точный MySQL-синтаксис для REPLACE. Сейчас это стало ANSI-стандартом, а если мы будем поддерживать MySQL-синтаксис [и их gotchas], наш собственный станет слишком сложным.
Вопрос №22
kai:
И ещё один вопрос, по поводу драйверов. Можно ли как-нибудь форсировать разработку драйвера для perl (DBD::Pg)? Основная проблема - PostgreSQL поддерживает различные типы данных, включая массивы и хеши, а драйвер - нет. Хоть поддержка массивов появилась в новой версии драйвера, но, на сколько я знаю, за последний год ни один распространенный Linux-дистрибутив не включил в себя обновлённую версию этого драйвера.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Так дело лишь в задержке в обновлении Linux-дистрибутива продукта Perl::DBD. Я бы поинтересовался у производителей дистрибутива. Обычно, когда люди задают производителям дистрибутивов подобные вопросы, они выпускают обновления быстро.
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
За последний год DBD::Pg был фактически переписан с нуля и появилась поддержка многих приятных вещей. И насколько я вижу, DBD::Pg продолжает активно развиваться (по сравнению с тем, что было 2 и более лет назад). Вопрос обновления DBD::Pg в Linux дистрибутивах лучше задавать тем, кто поддерживает эти дистрибутивы (но насколько я знаю, многие Linux-дистибутивы крайне консервативны в обновлении подобных вещей). В крайнем случае всегда можно собрать руками мимо системы портов/пакетов.
Вопрос №23
Юрий Леонович Русинов:
Федору Сигаеву: если на сервере есть хранимая процедура на C/C++, то могу ли я в ней создать дочерний поток и выполнить в нём какие-либо операции?
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Можете, но смотря что за операции. Ни одна внутренняя функция Постгреса не разрабатывалась с оглядкой на thread-safe. Так что в отдельном потоке Вам предстоит самостоятельно заботиться обо всём, включая аварийное завершение этого потока.
Вопрос №24
Михаил Дружинин:
Спасибо за ответ на мой предыдущий вопрос. Собственно, решение с таблицей для заданий пришло и мне. Только функция-обработчик этих заданий с увеличением их количества тоже будет усложняться.
Попутно вспомнилось ещё два вопроса:
1) Есть ли для PostgreSQL модуль, реализующий выполнение задач по расписанию.
2) Можно ли вызвать функцию, возвращающую что-то отличное от void, по его строковому имени 'my_func_1' и, соответственно, получить возвращаемое ей значение.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
1) Не слышал и сомневаюсь, что такой есть. В Постгресе просто нет такого «хука».
2) Можно, конечно, но я не понял вопроса — это вопрос по С, PL/pgSQL или SQL? в первом случае — man dlopen, во втором и третьем — EXECUTE (http://www.postgresql.org/docs/8.3/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN)
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
1) Разработчики pgAdmin сделали вот такую вот вещь для Ваших задач: http://www.pgadmin.org/docs/1.4/pgagent.html. При использовании pgAdmin штука достаточно удобная. Но в production я его не использовал ни разу. Мне штатного крона хватает.
Вопрос №25
Будет ли Skype открывать исходный код каких-либо новых PostgreSQL-проектов? Также интересует их опыт по использованию PL/Proxy и Skytools.
Марко Креэн, инженер компании Skype:
Первая часть вопроса: да, есть планы по открытию кода нашего фреймворка по мониторингу/управлению [PostgreSQL-серверами]. Но он все еще находится в разработке, поэтому я не могу назвать точную дату релиза.
Вторая часть: также есть идея опубликовать небольшой пример базы данных «в стиле Skype», в которой будут увязаны все наши компоненты одновременно — PL/Proxy, PgBouncer, PgQ и различные варианты репликации на основе Skytools. Пользователи смогут тогда увидеть, как мы используем их вместе. Но мы пока не нашли времени, чтобы сделать всё это...
Вопрос №26
Как в Skype осуществляется миграция PostgreSQL между основными (major) версиями?
Марко Креэн, инженер компании Skype:
С помощью Londiste (компонент репликации в Skytools).
Вопрос №27
Николай:
Почему компании-хостеры не торопятся включать PostgreSQL в список предоставляемых услуг, продолжая предлагать в основном MySQL? Стоит ли ждать изменения ситуации и если да, то когда?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Это та же самая проблема, которую мы имеем с приложениями сторонних разработчиков. Провайдеры осуществляют миграцию одними из последних, потому как они на самом деле не используют базы данных. Они довольно консервативны — как и разработчики сторонних приложений. Со временем ситуация точно изменится.
Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Сейчас у хостеров в России появилась заинтересованность в предоставлении подобной услуги, так что, я думаю, в течении года появится некоторое количество вариантов.
Вопрос №28
Собираются ли улучшать партицирование (partitioning)?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Да, есть разговоры об улучшении синтаксиса, чтобы упростить процедуры обслуживания. Может быть, это войдет в 8.4, но я не пока уверен.
Вопрос №29
Планируется ли в будущем метод доступа index cover (уж не знаю, как по-русски)?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Вы имеете в виду доступ к данным только через индекс (без доступа к «куче», heap)? Мы обсуждали эту идею в применении к таблицам «только для чтения», для которых заранее известно, что все записи в индексе являются актуальными. Причина, по которой мы не можем сделать это для read-write таблиц, заключается в том, что информация о видимости записи содержится только в «куче», но не в индексе.
Вопрос №30
Планируются ли в будущем аналоги IOT-таблиц Oracle или clustered indexes в MS SQL, Sybase?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
У нас есть патч для чего-то похожего на clustered index под названием «Group Index Tuples» (GIT). Хейки [Хейки Линнакангас, Heikki Linnakangas] сделал основную работу в нём, но мне не удалось уговорить его найти время для дополнительной работы над патчем к 8.4. Поэтому сейчас это пока просто патч. Точно не понял, что имеется в виду под IO-tables в Oracle.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Это много раз обсуждалось, но практического патча пока не предоставлено. Первое приближение — GIT (Group Index Tuples) от Хейки, но патч еще не завершён.
Вопрос №31
Планируется ли в будущем компрессия индексов в виде Oracle или db2 for z/OS (последний вариант, наверное, предпочтительней)?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
О, что-то похожее будет реализовано при внедрении Group Index Tuples от Хейки [Хейки Линнакангас, Heikki Linnakangas] (к сожалению, пока работа не завершена). Лично я был бы определённо рад появлению подобных возможностей.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Нет пока, потому что в Постгресе bottleneck [узкое место] сидит не в размере индексов, а в доступе к таблицам — каждую запись надо проверять на видимость данной транзакцией. Это побочный эффект [реализации СУБД, основанной на методе] версионности записей.
Вопрос №32
Планируется ли в будущем общий кэш для планов?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Проблема с реализацией кэша плана запросов заключается в издержках при процессе инвалидации кэша. В данный момент мы не разработали эффективный алгоритм для этого. Мы могли бы заняться реализацией уже сейчас, но ведь если такой кэш будет работать медленнее, чем сам процесс подготовки запроса в сессии — кому это будет нужно?
Вопрос №33
Когда наконец будут хинты? Или хотя бы stored outlines, как в Oracle?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мы не думаем, что займёмся реализацией «хинтов», т. к. существующий оптимизатор запросов достаточно хорош. У нас есть механизм грубой настройки запросов (переменные enable_*), которые, как правило, могут помочь в большинстве случаев, когда оптимизатор всё же ошибается. Основная проблема с «хинтами» заключается в том, что [при их наличии] мы [разработчики PostgreSQL] перестаём понимать, когда же оптимизатор ошибается и перестаём его развивать. Кроме того, многие люди, настроив свои «хинты» на определённые массивы данных, могут получить совершенно другой уровень производительности системы при изменении этих данных.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
В обозримом будущем даже не планируется. Считается, что если оптимизатор запросов ошибается, то надо править оптимизатор, а не добавлять хинты.
Вопрос №34
Планируется ли корректная поддержка Unicode в регулярных выражениях?
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Сделайте патч — закоммитим. Просто на удивление редко запрашиваемая фича, раз в полгода. Там есть большие сложности с производительностью регулярных выражений в мультибайтовых кодировках.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Ух, я не был в курсе, что у нас есть проблемы с поддержкой Unicode в регулярных выражениях. Что это за проблема? Никогда не слышал.
Вопрос №35
Планируется ли ввести в PostgreSQL механизмы, аналогичные 'EVENTS' в MySQL? Это позволило бы, например, в наименее загруженное время суток самой базе производить VACUUM FULL ANALYZE или производить анализ данных и кластеризацию таблиц.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Этот вопрос перекликается с одним из предыдущих, о планировщике. Я думаю, что проекты-спутники (например, pgevents) наилучшим образом подходят в данном случае.
Вопрос №36
Дмитрий:
Планируется ли введение встроенной мульти-мастер репликации? Если да, то когда можно ожидать beta-версию?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мы могли бы попробовать реализовать мульти-мастер репликацию, но блокировки зачастую делают её малопроизводительной. Большинство разработчиков считает мастер/слейв репликацию или партицирование данных по серверам лучшей альтернативой. PgPool, кстати, может работать в мульти-мастер режиме. PgCluster реализует мульти-мастер, но его производительность оставляет желать лучшего. Slony-II пытался реализовать мульти-мастер, но опять же-таки производительность была невысокой.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Есть планы на встроенную репликацию Master-Multiple Slaves, надеемся, что это будет в 8.4. Про Multi-Master — посмотрите на Postgres-R, его исходные коды открыты уже месяц как.
Марко Креэн, инженер компании Skype:
Если Вы хотите распределить нагрузку по записи на несколько машин, посмотрите PL/Proxy — он не является мульти-мастером в общепринятом смысле этого слова, но он обладает очень хорошей производительностью, которой так не хватает в обычных мульти-мастер системах.
Вопрос №37
Арлен
У меня, скорее, филосовский вопрос, чем практический. Не рассматривает ли сообщество PostgreSQL вопрос о смене лицензии с BSD на GPL ввиду быстрого роста популярности открытого кода и защиты его от закрытия крупными компаниями, взявшим PostgreSQL себе на вооружение и для наживы ради?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Это действительно интересный вопрос. GPL могла бы предотвратить коммерциализацию Постгреса некоторыми компаниями, но тогда они бы не нашли деньги для финансирования разработки или спонсорства, поэтому мне кажется, что GPL является худшей альтернативой для нас. Если отвечать буквально на Ваш вопрос, никто в Постгрес-сообществе никогда всерьёз не рассматривал возможность изменить лицензию на GPL; она не имеет ни одного преимущества, зато имеет множество недостатков.
Фёдор Сигаев, ведущий разработчик PostgreSQL:
Нет, и не планируется. GPL накладывает излишние ограничения.
Вопрос №38
sakalr:
Cегодня только получил книгу с материалом по PL/PgSQL, потому слегка в растерянности, так как ещё не читал её. С одной стороны, возможно, в ней есть большинство ответов на мои вопросы, с другой стороны, подобные конференции проводятся не каждый месяц и глупо было бы не спросить здесь. Можете ли Вы порекомендовать обзорные статьи или рецепты (cookbook) на тему pl/pgsql? Сам reference в руководстве вполне толковый, но нужны именно рецепты.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Ух, раньше у нас была книга рецептов по plpgsql, но я сейчас не вижу её онлайн. Я бы начал с изучения в src/test/regress/sql/plpgsql.sql на Вашем месте.
Вопрос №39
Алексей:
Когда можно ожидать реализацию нормальной репликации между двумя PostgreSQL-серверами, хотя бы master-slave с горячим переключением с master на slave? PITR не подходит нормально нагруженной среде из-за длительности переключения на резервный сервер, а сделанные на коленке и триггерах системы вроде Slony в сколько-нибудь серьезный продакшн ставить страшно.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Проблема с failover-ом (переключением нагрузки на резервный сервер при отказе основного), встроенным в PostgreSQL, заключается в том, что мы не знаем достаточно о Вашей операционной системе, чтобы произвести переключение. Я боюсь, что автоматический failover будет сильно зависеть от ОС и, следовательно, он будет создаваться либо самим пользователем, либо тем, кто создает пакеты для его системы.
Вопрос №40
Алексей:
Можно ли изменить формат выходного представления типа UUID, чтобы получать на выходе просто 32-х символьную строку, а не разбитую по группам? В основном, входные данные именно varchar(32) в большинстве проектов, а то, что получается сейчас на выходе, неудобно использовать.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мы обсуждали возможность добавления форматирования вывода UUID в PostgreSQL 8.4. Я не припомню, сделано это уже или нет, но мне кажется, что Вы всегда можете использовать PL/PgSQL, чтобы форматировать UUID так, как Вам нравится.
Вопрос №41
Арлен:
Очень хотелось бы узнать, идут ли уже сейчас обсуждения в сообществе того, что войдёт в PostgreSQL 9-ой версии?
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Вау, PostgreSQL 9.0. Мне кажется, никто еще не загадывал так далеко вперёд. Мы работаем над 8.4 и не строим далеких 9.0 планов. Извините.
Вопрос №42
Арлен:
Хотелось бы узнать ваше отношение к проекту Postgres-R (http://www.postgres-r.org/) и мнение насчет его будущего в проекте PostgreSQL.
Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Postgres-R реализовал мульти-мастер репликацию на основе группового сетевого взаимодействия. В Slony-II разработчики попытались использовать подобный подход, но столкнулись с плохой производительностью и отказались от этого пути. Кто-то сейчас работает над Postgres-R, но я не уверен, что они имеют хорошие показатели производительности. Когда у нас будут данные о ней, можно будет обсуждать проект подробнее.