Рубрика «postgresql» - 52

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

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

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

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

Z-order vs R-tree, продолжение - 1

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

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

Вот именно этим мы и займёмся под катом.
Читать полностью »

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

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

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

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

Читать полностью »

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

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

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

Производительность запросов в PostgreSQL – шаг за шагом - 1

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

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

Вступление

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

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

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

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

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

Читать полностью »

image

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

Читать полностью »

PostgreSQL slave + btrfs и systemd=горячая тестовая база - 1

При активной разработке ПО нередко нужна тестовая база с актуальными данными из боевой базы. Хорошо, если база маленькая и развернуть копию не долго. Но если в базе десятки гигабайт данных и все нужны для полного тестирования, да ещё и посвежее, то возникают трудности. В этой статье я опишу вариант преодоления подобных неприятностей с помощью snapshot-ов btrfs. А управлять работой получившегося комплекса будет systemd – удобный и функциональный инструмент.

Читать полностью »

image

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

Почему asyncpg?

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js