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.

Приветствую. Хочу поделиться одним самописным костылём, авось кому-нибудь будет полезен.

Коротко о главном

Моделируем ситуацию: есть кластер PostgreSQL-серверов — мастер и n-реплик. Наступает черный день и одна(или несколько) реплик падает. Причины неважны — сдохла железка, уборщица перебила шваброй провод или НЛО временно зохавало серверную. Итог один — если реплика долго лежала, то сама она уже никогда не нагонится.

С 9.0 версии PostgreSQL есть встроенный механизм Master-Slave репликации (streaming replication).
Однако, с его появлением выбрасывать старые триггерные механизмы не следует.

В общем случае, если нам требуется нечто большее, чем одна абсолютно точная копия всего DB-сервера, то триггеры остаются с нами.

Примеры таких ситуаций:

• Если требуется failover (т.е. останавливается Master и все запросы временно идут на Slave, а потом запущенный Master начинает догоняется до актуального состояния со Slave).
• Master и Slave не являются 1:1 идентичными. Например, по какой-то причине на Slave надо держать дополнительные данные (базы/таблицы) или же копированию с Master подлежат не все базы/таблицы, или же при удалении данных — они должны сохраниться на Slave.
• В проекте приходится использовать продуктовый «зоопарк» — т.е. Master и Slave имеют по какой-то причине разные версии, или же версии одинаковые, но ОС разной «битности».
• В проекте требуется рекурсивная репликация Master-Slave1-Slave2-Slave3 или в реально нагруженном INSERT/UPDATE проекте к Master параллельно подключается больше, чем 1 Slave (хотя некоторые проекты имеют нагрузку, с которой могут нормально работать и до 5-6 Slave).
• Если по какой-то причине требуются различные права доступа к объектам базы на Master и Slave.

Добавляйте в комментариях дополнительные варианты.

Примечание: Возможность построения failover задекларирована месяц назад в версии 9.1 под названием «Synchronous Replication». Однако, лично я пока ещё эксперименты не проводил.

Вступление

Встречалась ли вам ситуация, когда необходимо реализовать хранение древовидной структуры в реляционной БД?



Примеров можно привести множество. Это и древовидные комментарии, и каталог продукции, и населенные пункты, разделенные по странам и областям. Я думаю, что каждый сможет самостоятельно привести несколько примеров.

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

„Среди всех СУБД с открытым исходным кодом PostgreSQL 9.1 предоставляет несколько наиболее передовых промышленных возможностей и поддерживается энергичным и инновационным сообществом с показавшим себя успехом у потребителя. PostgreSQL — хорошо зарекомендовавшее себя решение для установки и запуска приложений в «облаке»,“ — заявил Чарльз Фан, старший вице-президент отдела исследования и разработок VMware.

Информация для пользователей

Несколько функций, реализации которых пользователи просили годами, были добавлены в PostgreSQL 9.1, что позволяет избавиться от препятствий в развертывании новых или портированных приложений на PostgreSQL. В их числе:

• Синхронная репликация (Synchronous Replication): позволяет совместить высокую готовность со связностью на нескольких серверах.
• Сравнение по колонке (Per-Column Collations): поддерживает лингвистически корректную сортировку в базе данных, таблице или колонке.
• Беспротокольные таблицы (Unlogged Tables): значительное увеличение производительности работы с врéменными данными.

В этой статье я расскажу, как настроить репликацию баз данных для PostgreSQL. Для экспериментов будем использовать дистрибутив линукса CentOS 5.3, хотя это не принципиально. будем использовать версию PostgreSQL 8.4.7 и SymmetricDS-2.2.2.

Что такое репликация?

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

Для репликации нужно как минимум два сервера баз данных, поэтому готовим два одинаковых сервера с базой данных PostgreSQL на каждом. У первого будет IP адрес 10.0.2.20, у второго — 10.0.2.21, у обоих гейтвей 10.0.2.2.
Можно обойтись виртуальной машиной, например VirtualBox, создать в ней два виртуальных сервера и запустить их на своем собственном компе.

В приведенных командах первым символом будет стоять знак # либо $, эти знаки означают, что команда запускается из-под root или из-под обычного пользователя, соответственно.
Итак, какие действия нужно предпринять:

Новость о выходе EnterpriseDB Postgre Plus Advanced Server 9.0, главной особенностью которого стало добавление платформы HP-UX/Itanium, прошла как-то незаметно в рунете. Я решил восполнить этот пробел и перевести статью по этой теме, она, кстати, хорошо дополняет мои предыдущие посты:
— Как отразится противостояние HP и Oracle на Open Source?
— Противостояние HP и Oracle. Продолжение.
Внимание, перевод сокращён! (Честно говоря, взялся переводить только из-за последнего абзаца, прочитайте его обязательно. ;-)

Привет, Хабрсообщество!

Наверное, моя статья будет не интересна матерым сисадминам и покажется копипастом. Но я адресую ее тем, кто, как и я, будучи только разработчиком, впервые столкнулся с необходимостью еще и администрировать сервер, при этом решая задачи высоконагруженной БД. И чтобы гугл вас не проклял, постараюсь собрать в одном месте основные приемы для разгона сервера БД, которые мне успешно удалось реализовать.

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

В процессе разработки административных инструментов для клуба трельяж понадобилась функция ануллирования всех результатов конкретной игры. Казалось бы, что может быть проще. Меняем статус игры, откатываем денормализационные данные со статистикой игроков, инвалидируем оперативные кеши, затрагивающие эти данные, и дело в шляпе. Но у связки PostgreSQL и psycopg2 на этот счет оказалось собственное мнение, не совпадающее с мнением редакции.

Я решил не затягивать выход обновления справочника и выпустил 2 версию «Работа с Postgresql: настройка, масштабирование».

Как и раньше, в книге иследуются вопросы по настройке производительности Postgresql, репликации и кластеризации.
Добавил пару слов о расширениях PostgreSQL, методики решения проблем, сниплеты(пока в процессе). Произвел коррекцию ошибок в манах настроек. Пока что только сконвертирован pdf. Все правки и замечания прошу на этой странице github.com/le0pard/postgresql_book/issues или в комментариях.

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

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

В одном из докладов недавно проходившего CNews Forum я увидел «СУБД для предприятий» в списке ПО, которое навсегда останется проприетарным. Я не могу согласиться с таким тезисом, поэтому написал небольшую статью.