PostgreSQL *

С тех пор как число активных пользователей Instagram стало постоянно расти, Postgres оставался нашим надежным фундаментом и неизменным хранилищем данных для большинства данных, создаваемых пользователями. И хотя меньше года назад мы писали о том, как мы храним большое количество данных на Instagram при 90 лайках в секунду, сейчас мы обрабатываем более 10000 лайков в секунду – и наша основная технология хранения данных не изменилась.

За последние два с половиной года, мы поняли несколько вещей и подобрали пару инструментов для масштабирования Postgres и мы хотим ими поделиться – то, что мы хотели бы знать при запуске Instagram. Некоторые из них специфичны для Postgres, другие представлены также и в других базах данных. Чтобы знать, как мы горизонтально масштабируем Postgres, смотрите наш пост Sharding and IDs at Instagram

Думаю многим известна особенность PostgreSQL, которая приводит к эффекту раздувания таблиц, или table bloat. Известно что она проявляет себя в случаях интенсивного обновления данных, как при частых UPDATE так и при INSERT/DELETE операциях. В результате такого раздувания снижается производительность. Рассмотрим почему это происходит и как с этим можно бороться.

Навеяно недавним постом.

Как то действительно мало затрагивается тема десктопных БД-конструкторов, хотя наверное ни один здравомыслящий человек не будет проектировать свой проект сразу в СУБД.

Хочу написать мини-обзор о совсем не новом, но верном помощнике — SQL Power Architect'е. Опенсорсном кроссплатформенном приложении написанном на java, с поддержкой различных БД.

Ни для кого не секрет, что проектирование структуры БД является одной из основных и порой очень трудозатратных задач при разработке любого ПО, работающего с данными. Все мы так или иначе проектируем БД, пытаясь представить себе схему взаимосвязей таблиц, а зачастую рисуем, визуализируем структуру БД, прежде чем перенести ее в СУБД. Для моделирования баз данных MySQL есть MySQL Workbench, поставляемый разработчиком, для MS SQL есть Database Diagrams; я до недавнего времени пользовался Dia, а кто-то, может быть, использует для этих целей MS Visio. Но для 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 приводит к полному зависанию потока (процесса), отрабатывающего запрос.

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

Мне хотелось создать прекрасный объемлющий мануал Getting Start без всякой воды, но включающий основные плюшки для начинающих по системе PostgreSQL в Linux.

PostgreSQL является объектно-реляционной системой управления базами данных (ОРСУБД) на основе POSTGRES, версия 4.2, разработанной в Университете Калифорнии в Беркли департаменте компьютерных наук.

PostgreSQL является open source потомком оригинального кода Berkeley. Он поддерживает большую часть стандарта SQL и предлагает множество современных функций:

• Cложные запросы
• Внешние ключи
• Триггеры
• Представление
• Транзакционная целостность (transactional integrity)
• Управление конкурентным доступом с помощью многоверсионности

Кроме того, PostgreSQL может быть расширен пользователем во многих отношениях, например, путем добавления новых

• типов данных
• функций
• операторов
• агрегатных функций
• индекс методов
• процедурных языков

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

В этой статье я расскажу, как я решил эту проблему с помощью 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

О секционировании можно найти много информации, в частности здесь можно прочитать о теории, и дальше автор развивает идею и предоставляет свое решение для быстрого добавления секции. Рекомендую к ознакомлению.
После изучения теории почти ко всем приходит идея автоматизации процесса создания секций. Выше был один из вариантов, второй комплексный вариант я видел у создателей уважаемого, думаю, не только мной Zabbix.
После небольшого адаптирования я решил внедрить его у себя… К сожалению, в нем выяснилось несколько недостатков: при создании новой секции первая запись в эту секцию терялась; при большом количестве секций вставка даже одной записи занимает слишком много времени (вызвано 2 факторами: каждый раз вычислялась таблица, куда следует положить запись; использования множества rules вместо 1 триггера со всеми условиями). Тем не менее ребята проделали отличную работу и я, пользуясь случаем, посылаю им лучи уважения.

Всем доброго времени суток!
Как известно, недавно вышел 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) эту проблему заметили и уже решили.

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