PostgreSQL *

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

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

Чтобы разобраться в сложившейся ситуации, администратору БД необходимо понять, какой процесс блокирует и какой процесс является блокируемым, а также иметь возможность отменить или «убить» блокирующий процесс и в конце проверить результат.

В этой статье я хочу коснуться темы блокировок в PostgreSQL и рассказать об инструментах для работы с ними. Но сначала попробуем разобраться в самой теме.

В прошлый раз мы пришли к выводу, что для эффективной работы пространственного индекса на основе Z-order необходимо сделать 2 вещи:

• эффективный алгоритм получения подинтервалов
• низкоуровневую работу с B-деревом

Вот именно этим мы и займёмся под катом.

Обычно при составлении структур данных и таблиц никто не заморачивается порядком столбцов. Собственно, какой в этом смысл? При необходимости можно поменять порядок столбцов в SELECT, так о чем беспокоиться? Так вот, беспокоиться есть о чем, так как порядок столбцов может ощутимо влиять на размер таблицы. Да-да, размер таблицы может зависеть от порядка столбцов, даже если данные одни и те же.

В этой заметке речь пойдет о том, как писать рекурсивные запросы. Тема эта поднималась не раз и не два, но обычно все ограничивается простыми «деревянными» случаями: спуститься от вершины до листьев, подняться от вершины до корня. Мы же займемся более сложным случаем произвольного графа.

Начнем с того, что повторим теорию (очень кратко, потому что с ней все ясно), а затем поговорим о том, что делать, если непонятно, как подступиться к реальной задаче, или вроде бы понятно, но запрос упорно не хочет работать.

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

Индекс на основе Z-order кривой в сравнении с R-деревом имеет массу преимуществ, он:

• реализован как обычное B-дерево, а мы знаем что
• страницы B-дерева имеют лучшую заполняемость, кроме того,
• Z-ключи сами по себе более компактны
• B-дерево имеет естественный порядок обхода, в отличие от R-дерева
• B-дерево быстрее строится
• B-дерево лучше сбалансировано
• B-дерево понятнее, не зависит от эвристики расщепления/слияния страниц
• B-дерево не деградирует при постоянных изменениях
• ...

Впрочем, у индексов на основе Z-order есть и недостаток — сравнительно низкая производительность :). Под катом мы попробуем разобраться с чем связан этот недостаток и можно ли что-то с этим сделать.

Илья Космодемьянский ( hydrobiont )

Для начала сразу пару слов о том, о чем пойдет речь. Во-первых, что такое оптимизация запросов? Люди редко формулируют и, бывает так, что часто недооценивают понимание того, что они делают. Можно пытаться ускорить какой-то конкретный запрос, но это не обязательно будет оптимизацией. Мы немного на эту тему потеоретизируем, потом поговорим о том, с какого конца к этому вопросу подходить, когда начинать оптимизировать, как это делать, и как понять, что какой-то запрос или набор запросов никак нельзя оптимизировать – такие случаи тоже бывают, и тогда нужно просто переделывать. Как ни странно, я почти не буду приводить примеров того, как запросы оптимизировать, потому что даже 100 примеров не приблизят нас к разгадке.

Вступление

В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.

Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:

Неповторяемое чтение — транзакция повторно читает те же данные, что и раньше, и обнаруживает, что они были изменены другой транзакцией (которая завершилась после первого чтения).

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

Что же касается Serializable, то данный уровень изоляции самый строгий, и не имеет феноменов чтения данных.

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

asyncpg — новая Python open-source библиотека для работы с PostgreSQL. Она была написана с использованием asyncio и Python 3.5. asyncpg — самый быстрый драйвер для работы с PostgreSQL среди похожих реализаций на Python, NodeJS и Go.

Почему asyncpg?

Мы создаем EdgeDB — базу данных нового поколения, с PostgreSQL на бэкенде. Нам необходима высокая производительность, низкая задержка доступа и дополнительные возможности самого PostgreSQL.

Самый очевидный вариант – использовать psycopg2 — популярнейший драйвер Python для работы с PostgreSQL. У него отличное комьюнити, он стабильный и проверенный временем. Также есть aiopg, который реализует асинхронный интерфейс, поверх psycopg2. Тогда очевиден вопрос — зачем писать свой велосипед? Короткий ответ: производительность и поддержка возможностей PostgreSQL. Ниже мы рассмотрим это более детально.

Мы активно готовимся к PG Day'17, расширяем тематику конференции, поэтому в скором времени вас ждет большое количество интереснейших постов не только о PostgreSQL, но и о других широко используемых базах данных. Сегодня хотим предложить вашему вниманию перевод статьи Gulcin Yildirim, которая послужила основой для ее доклада на PG Conf Europe'16.

«Как бы парадоксально это ни звучало, но истина заключается в том, что чем больше мы узнаём, тем более невежественными становимся в абсолютном смысле, ибо только через просветление мы осознаём нашу ограниченность. Если говорить конкретнее, то одним из наиболее отрадных результатов интеллектуальной эволюции является постоянное открытие новых и более широких перспектив». Никола Тесла



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

База данных стран, регионов и городов под лицензией MIT. База данных представлена в виде sql скрипта для PostgreSQL. При запуске скрипт создает необходимые таблицы и заполняет их данными. База данных содержит:

Страны	218
Регионы	1611
Города	17287

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

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

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

Сразу приведу ссылку на полное описание (там же написано, где взять демо-базу и как ее установить).

Это вторая часть статьи, в которой изложен опыт работы со списком адресообразующих элементов ФИАС, загруженным в базу данных под управлением PostgreSQL. С первой частью статьи можно ознакомиться здесь.

Как бы мы не относились к качеству адресов ФИАС с ними необходимо работать, потому что это единственный общероссийский справочник адресов. Поэтому рано или поздно приходится решать задачу связи местоположения объектов недвижимости, юридических и физические адресов с адресом из ФИАС.

В этой статье изложен опыт работы со списком адресообразующих элементов ФИАС, загруженным в базу данных под управлением PostgreSQL. Для работы с адресообразующими элементами ФИАС создано несколько функций на языке PL/pgSQL.

Привет! Этот пост о том, что нового в DataGrip 2016.3. Напомню, что описанное справедливо и для других IDE на платформе IntelliJ с поддержкой баз данных: PHPStorm, PyCharm, RubyMine и, конечно, IntelliJ IDEA. Кроме одной маленькой возможности, о чём отмечу отдельно.

Этот релизный цикл был очень важным — удалось многое из того, что нас долго просили сделать: поддержка триггеров, поиск использований внутри представлений и функций, отложенное редактирование таблиц. Благодарим тех, кто не стесняется тестировать наши инструменты и пробует новые версии задолго до релиза.

Итак, DataGrip 2016.3!

Настраивая postgresql.conf, Вы могли заметить, что там есть параметр full_page_writes. Имеющийся рядом с ним комментарий гласит что-то о частичной записи страниц и люди, как правило, оставляют его в состоянии on — что не плохо, это я и объясню далее в данной статье. Тем не менее, очень полезно понимать что full_page_writes делает, так как влияние на работы системы может быть значительным.

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

---

Трансляция первого дня от 7 ноября окончена. 8 ноября в 09:45 Мск продолжение видео на странице спецпроекта и текстовой трансляции в новом посте и на странице спецпроекта.

---

Сегодня в этом посте весь день будет вестись текстовая трансляция конференции HighLoad++ 2016, проходящей в Сколково 7 и 8 ноября. HighLoad++ — это более 200 экспертов высочайшего класса с докладами о высоконагруженных сервисах, проблемах работы с ними и вопросах администрирования. Более 15 залов, плотный график, честный и полезный опыт спикеров — HighLoad++ умеет собирать крутые темы, задавать тон дискуссии и всё на одном дыхании.

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

Так получилось, что я начал работать с PostgreSQL три года назад и за это время умудрился методично собрать все возможные грабли, которые можно вообразить. И сказать по правде, если бы была возможность поделиться с собой трехлетней давности нынешним горьким опытом, моя жизнь была бы куда проще и нервные клетки целее. Именно поэтому я решил написать абсолютно субъективную статью со сводом правил, которых придерживаюсь при разработке на PostgreSQL. Возможно, кому-то эта статья поможет обойти собранные мной грабли (и наступить на другие, ха-ха!).