PostgreSQL *

Известно, что SQL — декларативный язык, который указывает, «что» мы хотим выбрать из базы, а «как» это сделать — СУБД решает сама. Задачу выбора для SQL-запроса конкретного способа его выполнения(плана) решает планировщик запросов, который есть практически в любой СУБД. Но иногда он выбирает не самый лучший план. Многие коммерческие СУБД предоставляют на этот случай «хинты», которые позволяют в ручном режиме подсказывать базе, как лучше выполнить запрос. В Open Source СУБД PostgreSQL такого механизма не было.

И вот, наконец, случилось то, о чем многие мечтали и чего уже устали ждать, а другие боялись. Японские разработчики из NTT реализовали хинты планера PostgreSQL. Причем, им удалось это сделать, не меняя ядро, в виде отдельного модуля pg_hint_plan, поддерживающего версии PostgreSQL 9.1 и 9.2. Модуль реализует хинты, позволяющие устанавливать методы сканирования и соединения таблиц, установку значений GUC. За деталями установки и использования добро пожаловать под кат.

Статья — заметка, выросшая из вопроса, заданного в Q&A. Вкратце дело было так… Был предложен вариант тестирования PostgreSQL на определенной файловой системе и стоял вопрос, нормальный ли это подход и можно ли хоть как-то доверять результатам этого теста. В ходе обсуждения вопроса альтернативных вариантов не нашлось и я решил тестировать как и задумал изначально.

Хочу обратить внимание хабрасообщества на возможную «уязвимость» в TCL, PostgreSQL и теоретически в некоторых других системах, использующих модули ругулярных выражений или NFA утилиты, изначально написаные самим Генри Спенсором (Henry Spencer). Измененных исходников можно найти добрую сотню (у того же Sun Microsystems, UUNET и т.д.). И хотя, я не думаю, что баг существует изначально с далеких 90-х, хотя бы потому, что кода где возникает эта ошибка я у Генри, в старых его источниках, не нашел, проверить ваши системы все-таки стоит.

И так ошибка: это busyloop на стадии компиляции регулярного выражения вида (((((x)*)*)*)*)*. Причем именно не исполнения, а компиляции, т.е. если есть проверка валидности регулярки и она базируется на том же коде NFA — имеем тот же безконечный цикл + 100% cpu usage.

Ошибку нашли коллеги по opensource проекту TCL, во всех его актуальных версиях (включая develop). Зная, что Postgres использует похожее API, нетрудно было выяснить, что скармливание этого регулярного выражения Postgres приводит к полному зависанию потока (процесса), отрабатывающего запрос.

Ошибка возникает при таком группировании только в пятом и более порядке вложенности — т.е. четыре вложеных группы корректно компилируются и исполняются.

Встала задача организовать административные центры в чёткую иерархию по принципу матрёшки, например, Украина — Крым — ЮБК — Ялта, и исправить имеющиеся ошибки в текущей базе данных.

В этой статье я расскажу, как я решил эту проблему с помощью KML-файлов обрамляющих границ и Postgres+Postgis.

Дело в том, что база, которой мы пользуемся для нашего проекта, не коммерческая (user generated, open source) и в ней есть ошибки. Например, самый частый случай — множесто городов приписаны к стране, но не относятся ни к одному из её регионов и областей, мы называем их orphaned cities.

Плюс к этому, бизнес у нас туристический, так что административно-политическое дробление стран не всегда подходит, иногда нет-нет да и приходится добавлять туристические регионы вручную. Например, такого административного региона как «Южный берег Крыма» нет, но есть такой туристический район, по которому туристы выбирают, куда ехать — ищут «дома на ЮБК», а не «дома в ялте, гаспре, гурзуфе и вообще где-то там».

Когда вопрос заходит о хранении в БД гибких (заранее не известных, часто изменяемых) структур данных, разработчики обычно обращаются к «великому и ужасному» EAV-паттерну, либо к ныне модным NOSQL базам данных.
Не так давно такая задача стала и передо мной.
— EAV. Вызывает у меня стойкую неприязнь, да и сказано и написано об этом было очень много всего негативного (Кайт, Фаулер, Карвин, Горман). Главный минус в том, что при написании запросов приходится оперировать уже не реальными сущностями («Сотрудник», «Дом», «Клиент», то для чего и предназначен SQL), а объектами, орагнизованными на более низком уровне (извините за сумбур). Поэтому это был самый не желательный вариант.
— NOSQL. Поначалу очень заинтересовал этот вариант (в частности MongoDB). После продолжительного использования реляционок, первое время начинаешь испытывать чувство тотальной свободы, от которого захватывает дыхание. Хранение документов любой структуры, моментальное создание новых коллекций, запросы к ним — красота! Но после непродолжительного использования эйфория начала спадать, а проблемы обнаруживаться:
— Бедный язык запросов (ИМХО) + отсутствие джойнов;
— Отсутствие схем (хорошая статья недавно была на эту тему (и не только на эту) habrahabr.ru/post/164361);
— Отсутствие встроенной поддержки ссылочной целостности;
— Отсутствие прибамбасов в виде хранимых процедур/функций, триггеров, представлений и многого другого.
— В моем приложении помимо данных с гибкой(изменяемой) структурой также необходимо хранить обычные статические данные — таблица пользователей, посещений, сотрудников и т.д. Работать с которыми (опять же имхо) гораздо проще и (самое главное) надежнее в обычной реляционной базе (та же самая ссылочная целостность и пр.).

Доброго времени суток.

Работая в институте, мне приходится иметь дело с большим количеством полу-структурированной информации. Здесь приставка «полу» значит, что в целом все данные похожи, но, как правило, распиханы в локальных папках на компьютерах у сотрудников, в .xls, .txt или в бинарном формате. Информация представляет из себя данные полученные с различных приборов( датчиков уровня, температуры, скорости течений, атмосферного давления, влажности и так далее до 20-30 различных параметров). Все приборы выгружают данные каждый в своем формате: либо в ascii либо бинарный формат, который потом обрабатывается, и, на выходе, снова получаются ascii. Ну вообщем все как всегда, вы и сами представляете весь этот хаос.

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

Обработка всего этого хозяйства — вполне стандартные вещь, ничего нового и интересного: проверка временных рядов на целостность(если нужна – интерполяция), построение кучи различных графиков, запуск различных моделей на этих данных, обработка вывода моделей(снова куча графиков), вывод статистики. О последней я и расскажу в этой статье.

Вариант простой для понимания асинхронной master-slave репликации на базе Postgresql 9.1

Впервые встала задача единоличной реализации полноценной репликации и впервые был написан мини-мануал, который и хочу здесь представить.

Для системы репликации Мастер-Слейв использовалась комбинация

• PostgreSQL 9.1 (БД) +
• Bucardo 4.5 (репликатор) +
• PgPool-II (пулер и файловер)

Добрый день, хаброжители. Прошло много времени с выпуска 2 версии книги по PostgreSQL — успела выйти версия 9.1 и 9.2 этой замечательной базы данных. Материалов по практическому использованию этой БД также накопилось немало, поэтому я решил выпустить обновление по книге. Итак, встречайте:«Работа с PostgreSQL: настройка и масштабирование», 3-е издание.

Как и раньше, в книге исследуются вопросы по настройке производительности PostgreSQL, репликации и кластеризации. Список изменений можно глянуть на странице книги. Любые пожелания или замечания можно высылать по почте (в моем блоге указано) или писать в github issues (или даже делать pull request на исправления). Приятного прочтения!

Страница книги: postgresql.leopard.in.ua
Исходники: github.com/le0pard/postgresql_book

Всем доброго времени суток!
Как известно, недавно вышел PostgreSQL 9.2 с массой интересных и полезных вещей. Недолго думая мы решили обновить наш кластер потоковой репликации с 9.0 на 9.2. Все бы ничего, если бы не несколько обстоятельств:

• это продакшен с большой суточной посещаемостью.
• даунтайм исключен.

Чтож, так даже интересней… Как мы это делали и что из этого вышло читайте дальше.

Сравнение с точки зрения разработчика

Сразу оговорюсь — я не имею ничего против размещения части бизнес логики в хранимых функциях, если это предусмотрено в архитектуре системы и оправдано по ряду практических соображений, которые выходят за рамки этой статьи.

Приходилось ли Вам когда-нибудь ломать голову над тем как вернуть из хранимой процедуры PostgreSQL сложную конструкцию с хитрой иерархией, и при этом не писать в приложении огромный костыль для парсинга древовидной структуры, утолканной силами разработчика в плоскую реляционную таблицу? Если ответ положительный, то прошу под кат…

Сегодня разнообразные открытые СУБД встают лицом к лицу против массивных, неуклюжих и дорогостоящих «корпоративных» систем, таких как SQL Server и Oracle. Часто открытые СУБД прекрасно работают лучше закрытых систем, не уступая даже в функциональных возможностях.

Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.

Уже догадались, о чем будет статья?

Третий год занимаюсь разработкой крупной системы на Java с использованием СУБД PostgreSQL. Система десктопная, клиент-серверная. Опытного Senior-Java-Developer-а у нас нет, поэтому приходится думать самим. Думать, строить, ломать, строить заново, опять ломать…
За время работы накопился некоторый опыт как по организации непосредственно работы с БД, так и по взаимоувязыванию этих платформ, о котором и хочу рассказать в этой статье.

Опишу выборочно некоторые вопросы, с которыми мы столкнулись при разработке и которые решили.

В ADO.NET провайдерах для Oracle, PostgreSQL и, возможно, других есть одна неприятная особенность, которая может сказаться на производительности вашего приложения, если вы запрашиваете у сервера большие объемы данных: они не кэшируют вызовы метода IDataReader.GetOrdinal. Как оказалось это очень критично для NHibernate, но, к счастью, разработчики NHibernate (а точнее Hibernate) эту проблему заметили и уже решили.

Но эта фича осталась незамеченной и почти не задокументированной.

Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами.

В конце декабря компания Oracle сообщила о падении своих акций на 9%. Но мне эта новость не показалась удивительной, потому что всего за пару дней до её появления я беседовал с Эдом Бояджаном (Ed Boyajian), президентом и CEO компании EnterpriseDB.

Судите сами — компания EnterpriseDB предлагает аналогичную СУБД, но стоимость её продуктов гораздо ниже, чем у Oracle. Сейчас, когда все стремятся найти более функциональные решения, за меньшие деньги, Oracle все труднее убедить клиентов переплачивать за своё ПО.

По приходу в одну контору, которая занимается разработкой карт, схем и планов, меня очень удивила одна вещь: не было централизованного хранилища всех материалов. Пользователи работали каждый со своими наработками. И если возникала потребность что-то взять из другого проекта – приходилось или бежать с «флэшечкой», или копировать файлы по сети. Что создавало неимоверное количество «мусора» в виде дубликатов разной свежести на множестве рабочих станций.

После наблюдения всего этого хаоса, я решил все это дело «причесать» и сделать централизованным хранение картографического материала, с разграничением прав доступа к отдельным проектам, да еще и с мониторингом изменений, внесенных в проекты.

По следам статьи «Уникальный ключ в условиях распределенной БД».

У нас есть база которую мы хотим разделить. В идеальном случае хочется сделать master-master. Один из самых сложных моментов, это обеспечение уникальности ключей на всех серверах. И хорошо если база изначально проектировалась с учетом масштабирования… Опять же, это что-то из области идеала, который встречается, скажем так — не часто.

Итак у нас есть база которую нужно подготовить к синхронизации master-master — сделаем все ключи в нашей базе уникальными в пределах проекта.

В упомянутой статье рассматривались несколько вариантов, но мы остановимся на одном предложенным Instagram

Идея этого проектика (именно «проектика») возникла спонтанно. В компании используется memory-DB TimesTen, содержит одну большую таблицу с данными, более 150 млн записей, и объем около 15 гигов. TimesTen всегда работал исправно, ответ по любому запросу получали за считанные миллисекунды, всех это устраивало. В один из дней, T10 стал отвечать на запросы очень долго, время ответа увеличилось до 3-5 секунд. Техподдрежка конечно начала проведение работ по поиску проблемы, но параллельно мы задались вопросом, а для чего вообще используется T10, почему нельзя перенести базу на обычную СУРБД Oracle или Postgres?

Возникла задача внедрения streaming репликации Postgresql 9.1 на продакшене. А т.к. раньше с нею дела не имели, решили провести ее «эстремальное тестирование».

Для этого были запущены две виртуальные машины VMWare Player с Ubuntu Server. Установлена и настроена streaming репликация на Postgresql 9.1.