|
|
# Задания
|
|
|
|
|
|
## 1. Установка
|
|
|
Установите postgresql на любую виртуальную машину. Перейдите в пользователя `postgres`.
|
|
|
```
|
|
|
$ sudo su - postgres
|
|
|
```
|
|
|
|
|
|
Вы суперпользователь базы данных.
|
|
|
|
|
|
## 2. Знакомство с командной строкой psql
|
|
|
В `psql` выполните инициализацию таблиц базы данных
|
|
|
```
|
|
|
\i scripts/weather.sql
|
|
|
```
|
|
|
|
|
|
Первая команда, которую нужно знать, это команда помощи:
|
|
|
```
|
|
|
\?
|
|
|
```
|
|
|
Вы увидите страницу общей помощи по командам терминала. Результаты будут разбиты на страницы, которые можно пролистать клавишей пробел.
|
|
|
|
|
|
Чтобы вывести список возможных SQL команд, наберите
|
|
|
```
|
|
|
\h
|
|
|
```
|
|
|
|
|
|
Чтобы вывести информацию о команде, добавьте её после `\h`. Например
|
|
|
```
|
|
|
\h create database
|
|
|
```
|
|
|
|
|
|
Выведите список всех баз данных
|
|
|
```
|
|
|
\l
|
|
|
```
|
|
|
|
|
|
Из командой строки `psql` также можно выполнить команду linux. Например список файлов корневого каталога операционной системы
|
|
|
```
|
|
|
\! ls -la
|
|
|
```
|
|
|
|
|
|
### 2.1 Описание таблиц
|
|
|
|
|
|
Команда `\d` без параметров выведет список всех таблиц и объектов в текущей базе данных. Если добавить символ `+`, для каждой таблицы можно увидеть дополнительную информацию такую как количество занимаемого места на диске.
|
|
|
```
|
|
|
\d+ weather
|
|
|
```
|
|
|
|
|
|
Существует множество `\d`-команд. Наиболее часто используемые:
|
|
|
- `\dt` - вывод всех таблиц,
|
|
|
- `\dn` - вывод всех схем,
|
|
|
- `\dv` - вывод всех представлений (views),
|
|
|
- `\du` - вывод всех пользователей,
|
|
|
- `\df` - вывод всех функций,
|
|
|
- `\dp` - вывод привилегий доступа для таблиц и представлений.
|
|
|
|
|
|
### 2.2 Пейджер
|
|
|
|
|
|
По умолчанию пейджер `psql`, который разбивает вывод на страницы, включён. Вы можете отключить его установив значение параметра `pager` равным 0.
|
|
|
```
|
|
|
\pset pager 0
|
|
|
```
|
|
|
|
|
|
## 3. Язык SQL
|
|
|
|
|
|
Попробуйте дать базе данных простой запрос
|
|
|
```sql
|
|
|
SELECT event_type FROM weather LIMIT 20;
|
|
|
```
|
|
|
Это запрос на получение данных колонки `event_type` из таблицы `weather`. Количество результатов будет ограничено 20 записями.
|
|
|
|
|
|
В терминале вы также можете написать многострочный запрос. Вводите запрос как обычно, используя Enter для переноса строки. `psql` создаст так называемый буфер запроса. Запрос не будет интерпретирован, пока вы не введёте символ `;`. Чтобы сбросить буфер при ошибке ввода, используйте `\r`.
|
|
|
```sql
|
|
|
\r
|
|
|
SELECT DISTINCT(event_type)
|
|
|
FROM weather
|
|
|
WHERE state = 'HAWAII';
|
|
|
```
|
|
|
|
|
|
### 3.1 Замер времени выполнения запроса
|
|
|
|
|
|
Вы можете замерить время выполнения запроса, включив его командой `\timing`
|
|
|
```sql
|
|
|
\timing
|
|
|
SELECT DISTINCT(event_type) FROM weather LIMIT 40;
|
|
|
```
|
|
|
|
|
|
### 3.2 Data Definition Language (DDL), Data Modification Language (DML) запросы
|
|
|
|
|
|
SQL запросы, связанные с модификацией данных таблиц называют DML (Data Modification Language) запросами. SQL запросы, связанные с модификацией базы данных называют DDL (Data Definition Language) запросами.
|
|
|
|
|
|
Попробуйте в командой строке простой DML запрос
|
|
|
```sql
|
|
|
UPDATE weather
|
|
|
SET magnitude = 40
|
|
|
WHERE episode_id = 57676;
|
|
|
```
|
|
|
|
|
|
Чтобы выйти из консоли введите `\q`.
|
|
|
|
|
|
## 4. Соединения таблиц
|
|
|
|
|
|
В реляционных базах данные разбиваются на таблицы так, чтобы избыточность хранимой информации была минимальной, запросы и долгосрочная поддержка были эффективными. Это приводит к необходимости объединять информацию из разных таблиц с помощью механизма `JOIN`.
|
|
|
|
|
|
В этом разделе мы рассмотрим выдуманную базу данных, созданную для HR отдела для управления человеческими ресурсами. Перед выполнением выполните инициализацию базы данных
|
|
|
```sql
|
|
|
\i scripts/hr.sql
|
|
|
```
|
|
|
|
|
|
```sql
|
|
|
\d departments
|
|
|
```
|
|
|
Схема таблицы Отделы (departments)
|
|
|
|
|
|
| Колонка | Связь с |
|
|
|
|-----------------|---------------------------------------------|
|
|
|
| department_id | |
|
|
|
| department_name | |
|
|
|
| location_id | таблицей `locations` колонкой `location_id` |
|
|
|
|
|
|
|
|
|
```
|
|
|
\d employees
|
|
|
```
|
|
|
|
|
|
Схема таблицы Сотрудники (employees)
|
|
|
|
|
|
| Колонка | Связь с |
|
|
|
|---------------|-------------------------------------------------|
|
|
|
| employee_id | |
|
|
|
| first_name | |
|
|
|
| last_name | |
|
|
|
| start_date | |
|
|
|
| job_title | |
|
|
|
| salary | |
|
|
|
| manager_id | таблицей `employees` колонкой `employee_id` |
|
|
|
| department_id | таблицей `departments` колонкой `department_id` |
|
|
|
|
|
|
Каждый сотрудник имеет свой идентификационный номер `employee_id`. В таблице хранится также важная информация как имя, фамилия, должность и зарплата. Принадлежность к отделу выражается в наличии связи с таблицей `departments` через поле `department_id`. Поле `manager_id` ведёт к менеджеру сотрудника.
|
|
|
|
|
|
### 4.1 Внутренние соединения (inner join)
|
|
|
Внутреннее соединение является наиболее распространенным и соединяет столбец в одной таблице и со столбцом в другой. В нашей базе данных HR мы хотели бы найти сотрудников и их отделы. Итак, допустим, мы хотим вывести сотрудников и отделы, в которых они числятся:
|
|
|
```sql
|
|
|
SELECT e.employee_id, e.first_name, e.last_name, d.department_name
|
|
|
FROM employees e
|
|
|
INNER JOIN departments d ON (e.department_id = d.department_id);
|
|
|
```
|
|
|
|
|
|
Обратите внимание, как мы обращаемся к `employee_id`, `first_name`, `last_name` из таблицы `employees` и к `department_name` из таблицы `departments`. Мы связываем эти два множества информации в части `FROM`. Обратите внимание, что `INNER JOIN` и `ON` зарезервированные слова. В примеры выше мы хотим получить пересечение элементов таблицы `employees` и `departments` по полю `department_id`.
|
|
|
|
|
|
Мы обратились к СУБД на специальном языке и СУБД взяла на себя самую сложную часть, избавив нас от необходимости писать специализированную программу для поиска и выгрузки информации.
|
|
|
|
|
|
### 4.2 Левые внешние соединения (left outer join)
|
|
|
|
|
|
При использовании механизма `LEFT OUTER JOIN` из левой таблицы вернуться все строки, и если справа не найдётся соответствия, то в столбцах правой таблицы вместо значений будет присутствовать `NULL`.
|
|
|
|
|
|
В базе данных, с которой мы работаем младшие сотрудники зависят от старших. Ниже приведена схема третьей таблицы `dependents`, которая фиксирует эти отношения.
|
|
|
|
|
|
```
|
|
|
\d dependents
|
|
|
```
|
|
|
|
|
|
Схема таблицы Подчиненные (dependents)
|
|
|
|
|
|
| Колонка | Связь с |
|
|
|
|-------------|---------------------------------------------|
|
|
|
| employee_id | |
|
|
|
| first_name | |
|
|
|
| last_name | |
|
|
|
| employee_id | таблицей `employees` колонкой `employee_id` |
|
|
|
|
|
|
|
|
|
Допустим, что кроме отдела сотрудника нам также нужно вывести его подчинённых:
|
|
|
```sql
|
|
|
SELECT e.employee_id, e.first_name, e.last_name, d.department_name, dep.first_name || ' ' || dep.last_name AS dependent
|
|
|
FROM employees e
|
|
|
INNER JOIN departments d ON (e.department_id = d.department_id)
|
|
|
LEFT OUTER JOIN dependents dep ON (e.employee_id = dep.employee_id);
|
|
|
```
|
|
|
|
|
|
Этим запросом мы объединяем таблицу сотрудников слева и подчинённых справа. Если у сотрудника нет подчинённых, его строке будет сопоставлена строка с значениями `NULL`. Мы можем увидеть, чтоб PostgreSQL вернула сотрудника John Smith у которого в подчинении два человека: Spoiled and DoNothing Smith, и сотрудника Howard TheDuck, возможно middle python-программиста, у которого никого в подчинении нет.
|
|
|
|
|
|
Если бы мы использовали `INNER JOIN`, то исключили бы обычных сотрудников из результатов запроса.
|
|
|
|
|
|
### 4.3 Правые внешние соединения (right outer join)
|
|
|
|
|
|
В ситуации с `RIGHT OUTER JOIN` всё происходит наоборот. При отсутствии соответствующей записи слева для записи таблицы указанной справа значениями `NULL` заполняются столбцы левой таблицы.
|
|
|
|
|
|
Ранее в схеме departments мы видели, что каждый отдел связан с географическим положением через поле `location_id` таблицы Местоположения (locations).
|
|
|
|
|
|
```
|
|
|
\d locations
|
|
|
```
|
|
|
|
|
|
Схема таблицы Местоположения (locations)
|
|
|
|
|
|
| Колонка |
|
|
|
|----------------|
|
|
|
| location_id |
|
|
|
| street_address |
|
|
|
| postal_code |
|
|
|
| city |
|
|
|
| state_province |
|
|
|
| country_id |
|
|
|
|
|
|
Узнаем, где географически расположены отделы компании
|
|
|
|
|
|
```sql
|
|
|
SELECT d.department_name, l.city, l.state_province, l.country_id
|
|
|
FROM departments d
|
|
|
RIGHT OUTER JOIN locations l ON (d.location_id = l.location_id);
|
|
|
```
|
|
|
|
|
|
Результат нам сообщают, что в городе Effingham штата Индиана США нет отдела. Значит офис был закрыт.
|
|
|
|
|
|
### 4.4 Соединения на себя (self join)
|
|
|
|
|
|
Соединение на себя - вид соединения, хотя и не имеет специального синтаксиса, стоит упомянуть отдельно. Такой способ соединения полезен, когда таблица содержит иерархические данные. В нашем примере это таблица `employees`.
|
|
|
|
|
|
```
|
|
|
Table "public.employees"
|
|
|
Column | Type | Collation | Nullable | Default
|
|
|
---------------+------------------------+-----------+----------+----------------------------------
|
|
|
employee_id | integer | | not null | generated by default as identity
|
|
|
first_name | character varying(20) | | |
|
|
|
last_name | character varying(25) | | not null |
|
|
|
start_date | date | | not null | CURRENT_DATE
|
|
|
job_title | character varying(100) | | not null |
|
|
|
salary | numeric(9,2) | | not null |
|
|
|
manager_id | integer | | |
|
|
|
department_id | integer | | |
|
|
|
```
|
|
|
|
|
|
Обратите внимание, что каждому сотруднику назначен менеджер `manager_id`, который в свою очередь сам является сотрудником, а значит имеет вышестоящего менеджера, если только он не основатель компании.
|
|
|
|
|
|
Используя соединение на себя мы можем запросить у базы данных список сотрудников и их менеджеров
|
|
|
|
|
|
```sql
|
|
|
SELECT e.first_name, e.last_name, e.job_title, format('%s %s', m.first_name, m.last_name) AS manager
|
|
|
FROM employees e LEFT OUTER JOIN employees m ON (e.manager_id = m.employee_id);
|
|
|
```
|
|
|
|
|
|
Поздравляем! Вы познакомились с наиболее типичными видами соединений таблиц.
|
|
|
|
|
|
|
|
|
## 5. Транзакции
|
|
|
|
|
|
Транзакция - это набор действий, которые выполняются атомарно для внешнего наблюдателя. Если часть действий выполнится не может, откатываются все изменения транзакции.
|
|
|
|
|
|
Использование транзакций СУБД позволяет уменьшить количество кода необходимого для работы с данными. Если бы СУБД не управляли состоянием транзакций, тогда управляющий код пришлось бы реализовывать в каждом приложении, что усложняло бы код и приводило к ошибкам. Например, представьте типичную ситуацию регистрации пользователя в системе. На уровне приложения вам пришлось бы выполнить следующие действия:
|
|
|
1. Создать пользователя
|
|
|
2. Проверить, что он создан. Если не создан, завершить процесс с ошибкой.
|
|
|
3. Создать аккаунт.
|
|
|
4. Проверить, что он создан. Если не создан, удалить пользователя, завершить процесс с ошибкой.
|
|
|
5. Соединить аккаунт и пользователя.
|
|
|
6. Проверить, что соединение создано. Если не создано, удалить пользователя и аккаунт, завершить процесс с ошибкой.
|
|
|
|
|
|
С механизмом транзакций количество шагов уменьшается в 2 раза:
|
|
|
1. Создать пользователя
|
|
|
2. Создать аккаунт
|
|
|
3. Соединить аккаунт и пользователя
|
|
|
|
|
|
Транзакции позволяют не писать логику возврата в предыдущее состояние, до начала транзакции.
|
|
|
|
|
|
### 5.1 Простейшие транзакции
|
|
|
|
|
|
Самая простая транзакция состоит из одного запроса на модификацию данны, заключенного между `BEGIN` и `COMMIT`.
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id)
|
|
|
VALUES ('Cris', 'Winslett', current_date, 1, 'Director of the Highwire', 2, 2)
|
|
|
RETURNING employee_id;
|
|
|
COMMIT;
|
|
|
```
|
|
|
|
|
|
Чтобы подтвердить, что данные были успешно внесены в БД выполните запрос
|
|
|
```sql
|
|
|
SELECT * FROM employees
|
|
|
WHERE
|
|
|
first_name = 'Cris' AND
|
|
|
last_name = 'Winslett';
|
|
|
```
|
|
|
|
|
|
Однако, если вы решите откатить транзакцию после изменений вводом команды `ROLLBACK`, то вы увидите другой результат
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id)
|
|
|
VALUES ('Elizabeth', 'Christensen', current_date, 1, 'Master of the Highwire', 2, 2)
|
|
|
RETURNING employee_id;
|
|
|
ROLLBACK;
|
|
|
```
|
|
|
|
|
|
Добавленная строка имела идентификатор 10, но была удалена процедурой отката транзакции.
|
|
|
```sql
|
|
|
SELECT * FROM employees
|
|
|
WHERE
|
|
|
first_name = 'Elizabeth' AND
|
|
|
last_name = 'Christensen';
|
|
|
```
|
|
|
|
|
|
Однако некоторые изменения всё-таки происходят даже в случае отката. Убедитесь в том, что `employee_id` монотонно возрастает, выполнив транзакцию с откатом ещё несколько раз. Это происходит, чтобы у каждой транзакции гарантированно было уникальное значение, взятое из последовательности идентификаторов.
|
|
|
|
|
|
Команда `ROLLBACK` всегда завершает транзакцию и отбрасывает изменения. `COMMIT` выполняется только тогда, когда в ходе выполнения действий транзакции не было ошибок. Попробуйте выполнить следующий пример с ошибкой, чтобы в этом убедиться
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
INSERT INTO employees (first_name, last_name)
|
|
|
VALUES ('Tome', 'Jones')
|
|
|
RETURNING employee_id;
|
|
|
COMMIT;
|
|
|
```
|
|
|
|
|
|
### 5.2 Комплексные транзакции
|
|
|
|
|
|
В реальной жизни транзакции состоят из множества действий.
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id)
|
|
|
VALUES ('Chris', 'Winslett', current_date, 1, 'Jr Director of the Highwire', 2, 2);
|
|
|
INSERT INTO dependents (first_name, last_name, employee_id)
|
|
|
VALUES ('oldest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Chris' AND last_name = 'Winslett'));
|
|
|
INSERT INTO dependents (first_name, last_name, employee_id)
|
|
|
VALUES ('youngest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Chris' AND last_name = 'Winslett'));
|
|
|
COMMIT;
|
|
|
```
|
|
|
|
|
|
Если вы попробуете выполнить эту транзакцию два раза подряд, то второй раз получите ошибку. Это произойдет потому, что вложенный запрос второй раз вернёт 2 результата - для внесённого ранее сотрудника и внесённого только что. Таким образом транзакци не даст создать запись-дубликат.
|
|
|
|
|
|
В следующем запросе попробуем внести `null` значение в обязательное поле `first_name` для второго подчинённого. Транзакция не выполнится из-за нарушеного ограничения.
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id)
|
|
|
VALUES ('Bob', 'Young', current_date, 1, 'Jr Director of the Highwire', 2, 2);
|
|
|
INSERT INTO dependents (first_name, last_name, employee_id)
|
|
|
VALUES ('oldest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));
|
|
|
INSERT INTO dependents (first_name, last_name, employee_id)
|
|
|
VALUES (null, 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));
|
|
|
COMMIT;
|
|
|
```
|
|
|
|
|
|
Проверьте, что Bob Young не добавился.
|
|
|
|
|
|
### 5.3 Область видимости изменений транзакции
|
|
|
|
|
|
Что произойдёт, если вы запустили транзакцию, а в этом время к данным, которые вы модифицируете в новой транзакции обратился другой пользователь? Изменения в транзакциях невидимы другим транзакциям, пока транзакция производящие измнения не завершились.
|
|
|
|
|
|
В Postgres изменения структуры таблиц также не реализуются (committed) пока транзакция не выполнится успешно. Это уникальное свойство мире баз данных. Проведём два эксперимента - с корректной и некорректной транзакциями.
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
ALTER TABLE employees
|
|
|
ADD COLUMN niddle_name VARCHAR(50) DEFAULT NULL;
|
|
|
COMMIT;
|
|
|
```
|
|
|
Проверьте, что структура таблицы изменилась командой `\d employees`.
|
|
|
|
|
|
Теперь попробуем транзакцию с ошибкой:
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
ALTER TABLE employees ADD COLUMN address_line_1 VARCHAR(50) DEFAULT NULL;
|
|
|
ALTER TABLE employees ADD COLUMN address_line_2 VARCHAR(50) DEFAULT NULL;
|
|
|
ALTER TABLE employees ADD COLUMN city VARCHAR(50) DEFAULT NULL;
|
|
|
ALTER TABLE employees ADD COLUMN province VARCHAR(50) DEFAULT NULL;
|
|
|
ALTER TABLE employees ADD COLUMN postal_code VARCHAR(50) NOT NULL;
|
|
|
COMMIT;
|
|
|
```
|
|
|
Из-за того, что изменения структуры были внутри одной большой транзакции и значение по умолчанию для `postal_code` не было указано никакие изменения не были применены. Проверьте, что структура таблицы не изменилась.
|
|
|
|
|
|
Такой вид транзакций ещё называют транзакционным язык описания данных (Transactional DDL). Они жизненно важны для миграций баз данных.
|
|
|
|
|
|
### 5.4 Продвинутые транзакции с вложенными точками отката
|
|
|
|
|
|
Для некоторый специфичный случаев могут потребоваться вложенные транзакции. Postgres позволяет сделать даже больше - делать точки сохранения внутри транзакции. Точка сохранения (SAVEPOINT) предоставляет указатель на который может ссылаться комадна `ROLLBACK`.
|
|
|
```sql
|
|
|
BEGIN;
|
|
|
INSERT INTO employees (first_name, last_name, start_date, salary, job_title, manager_id, department_id)
|
|
|
VALUES ('Bob', 'Young', current_date, 1, 'Jr Director of the Highwire', 2, 2);
|
|
|
SAVEPOINT saved_employee;
|
|
|
INSERT INTO dependents (first_name, last_name, employee_id)
|
|
|
VALUES ('oldest', 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));
|
|
|
INSERT INTO dependents (first_name, last_name, employee_id)
|
|
|
VALUES (null, 'kid', (SELECT employee_id FROM employees WHERE first_name = 'Bob' AND last_name = 'Young'));
|
|
|
ROLLBACK TO SAVEPOINT saved_employee;
|
|
|
COMMIT;
|
|
|
```
|
|
|
|
|
|
Теперь, если вы попробуете найти Bob Young - вы найдёте его, но не найдёте его подчинённых. Что случилось? Эту транзакцию стало возможным выполнить частично из-за использования команды `SAVEPOINT`.
|
|
|
|
|
|
|
|
|
### 5.5 Я в транзакции?
|
|
|
|
|
|
Чтобы узнать идентификатор транзакции, в которой вы находитесь, вызовите команду
|
|
|
```sql
|
|
|
SELECT txid_current();
|
|
|
```
|
|
|
|
|
|
Вы можете удивиться, ведь вы не запускали транзакцию. На самом деле Postgres выполняет все команды, даже самые простые в контексте транзакций.
|
|
|
|
|
|
## 6. Индексы
|
|
|
|
|
|
### 6.1 B-Tree
|
|
|
Познакомимся с наиболее распространённым индексом - B-Tree индексом - на примере тестовых данных `weather.sql`.
|
|
|
|
|
|
Попробуем найти всё про снежные бури.
|
|
|
```sql
|
|
|
SELECT *
|
|
|
FROM weather
|
|
|
WHERE event_type = 'Winter Storm';
|
|
|
```
|
|
|
|
|
|
Чтобы проанализировать запрос используйте `EXPLAIN ANALYZE`
|
|
|
```sql
|
|
|
EXPLAIN ANALYZE
|
|
|
SELECT *
|
|
|
FROM weather
|
|
|
WHERE event_type = 'Winter Storm' limit 2;
|
|
|
```
|
|
|
Анализ покажет вам время планирования выполнения запроса `Planning Time` и время выполнения `Execution Time`.
|
|
|
```sql
|
|
|
QUERY PLAN
|
|
|
-------------------------------------------------------------------------------------------------------
|
|
|
Seq Scan on weather (cost=0.00..115.00 rows=11 width=622) (actual time=0.014..0.311 rows=11 loops=1)
|
|
|
Filter: ((event_type)::text = 'Winter Storm'::text)
|
|
|
Rows Removed by Filter: 1189
|
|
|
Planning Time: 0.066 ms
|
|
|
Execution Time: 0.332 ms
|
|
|
(5 rows)
|
|
|
```
|
|
|
|
|
|
Создадим B-Tree индекс для столбца `event_type` таблицы `weather` и повторим анализ запроса.
|
|
|
```sql
|
|
|
CREATE INDEX idx_weather_event_type ON weather(event_type);
|
|
|
```
|
|
|
|
|
|
Видим, что был использован созданный индекс, благодаря чему время выполнения существенно сократилось.
|
|
|
```sql
|
|
|
QUERY PLAN
|
|
|
---------------------------------------------------------------------------------------------------------------------------------
|
|
|
Bitmap Heap Scan on weather (cost=4.36..37.56 rows=11 width=622) (actual time=0.029..0.036 rows=11 loops=1)
|
|
|
Recheck Cond: ((event_type)::text = 'Winter Storm'::text)
|
|
|
Heap Blocks: exact=6
|
|
|
-> Bitmap Index Scan on idx_weather_event_type (cost=0.00..4.36 rows=11 width=0) (actual time=0.025..0.025 rows=11 loops=1)
|
|
|
Index Cond: ((event_type)::text = 'Winter Storm'::text)
|
|
|
Planning Time: 0.234 ms
|
|
|
Execution Time: 0.057 ms
|
|
|
(7 rows)
|
|
|
```
|
|
|
|
|
|
### 6.2 Многоколоночный индекс
|
|
|
|
|
|
Postgres позволяет создавать сложные индексы для нескольких колонок. Как и в случае с одной колонкой, если вы выполняете запрос по нескольких колонкам часто, такой индекс позволит выполнять его эффективнее.
|
|
|
|
|
|
Удалите старый индекс командой `DROP INDEX idx_weather_event_type;`. Выполним другой запрос - найдём снежные бури, которые привели к потере урожая
|
|
|
```sql
|
|
|
EXPLAIN ANALYZE
|
|
|
SELECT *
|
|
|
FROM weather
|
|
|
WHERE event_type = 'Winter Storm'
|
|
|
AND damage_crops > '0';
|
|
|
```
|
|
|
|
|
|
Выдача до создания индекса
|
|
|
```sql
|
|
|
QUERY PLAN
|
|
|
------------------------------------------------------------------------------------------------------
|
|
|
Seq Scan on weather (cost=0.00..118.00 rows=8 width=622) (actual time=0.011..0.399 rows=11 loops=1)
|
|
|
Filter: (((damage_crops)::text > '0'::text) AND ((event_type)::text = 'Winter Storm'::text))
|
|
|
Rows Removed by Filter: 1189
|
|
|
Planning Time: 0.073 ms
|
|
|
Execution Time: 0.419 ms
|
|
|
(5 rows)
|
|
|
```
|
|
|
|
|
|
Создадим индекс
|
|
|
```sql
|
|
|
CREATE INDEX idx_storm_crop ON weather(event_type,damage_crops);
|
|
|
```
|
|
|
|
|
|
Выдача после создания индекса
|
|
|
```sql
|
|
|
QUERY PLAN
|
|
|
------------------------------------------------------------------------------------------------------------------------
|
|
|
Bitmap Heap Scan on weather (cost=4.36..29.69 rows=8 width=622) (actual time=0.022..0.029 rows=11 loops=1)
|
|
|
Recheck Cond: (((event_type)::text = 'Winter Storm'::text) AND ((damage_crops)::text > '0'::text))
|
|
|
Heap Blocks: exact=6
|
|
|
-> Bitmap Index Scan on idx_storm_crop (cost=0.00..4.36 rows=8 width=0) (actual time=0.018..0.018 rows=11 loops=1)
|
|
|
Index Cond: (((event_type)::text = 'Winter Storm'::text) AND ((damage_crops)::text > '0'::text))
|
|
|
Planning Time: 0.203 ms
|
|
|
Execution Time: 0.048 ms
|
|
|
(7 rows)
|
|
|
```
|
|
|
|
|
|
Время уменьшилось на порядок.
|
|
|
|
|
|
Вы можете вывести существующие индексы базы данных sql запросом
|
|
|
```sql
|
|
|
SELECT indexname, indexdef
|
|
|
FROM pg_indexes
|
|
|
WHERE tablename = 'weather';
|
|
|
```
|
|
|
|
|
|
### 6.3 Анализ производительности
|
|
|
|
|
|
Как мы увидели, добавление индексов может играет важную роль в производительности вашего приложения. Индексы особенно ценны для больших таблиц.
|
|
|
|
|
|
Выполним следующий запрос, чтобы узнать размер таблиц в количестве записей и процентное соотношение обращений, по индексам и без них.
|
|
|
```sql
|
|
|
SELECT
|
|
|
relname,
|
|
|
100 * idx_scan / (seq_scan + idx_scan) percent_of_time_index_used,
|
|
|
n_live_tup rows_in_table
|
|
|
FROM pg_stat_user_tables
|
|
|
WHERE seq_scan + idx_scan > 0
|
|
|
ORDER BY n_live_tup DESC;
|
|
|
```
|
|
|
|
|
|
Идеальном случае мы хотим видеть `99%` для таблиц больших чем 10000 записей. Если вы нашли такую таблицу, где это не так - она хороший кандидат для создания новых индексов.
|
|
|
|
|
|
Также полезной может быть информация о том, сколько блоков индексированных данных читается из кэша Postgres, а сколько с диска.
|
|
|
```sql
|
|
|
SELECT
|
|
|
sum(idx_blks_read) as idx_read,
|
|
|
sum(idx_blks_hit) as idx_hit,
|
|
|
(sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as ratio
|
|
|
FROM pg_statio_user_indexes;
|
|
|
```
|
|
|
|
|
|
Упомянем ещё пару хитростей.
|
|
|
|
|
|
Использование команды `CREATE INDEX CONCURRENTLY` позволит избежать блокировки таблицы.
|
|
|
|
|
|
Параметр `maintenance_work_mem` определяет объём памяти задействованный под процесс создания индексов и другие фоновые задачи, например `vacuum`. По умолчанию это значение равно 64 МБ (вы можете найти его из psql в списке `select name, setting from pg_settings;`). Подумайте о том, чтобы увеличить это значение перед созданием больших индексов.
|
|
|
|
|
|
## 7. Проблема разбухания базы данных Postgres
|
|
|
|
|
|
У Postgres есть особый способ обработки обновлений или удалений. При удалении данных место на диске не освобождается до тех пор, пока база данных не будет запущена специальный процесс очистки `vacuum`. Если база данных загружена большим количеством DML запросов на удаление строк, через какое-то время в ней появится много неиспользуемого пространства, что негативно повлияет на производительность, если ничего не сделать.
|
|
|
|
|
|
Попробуйте следующий запрос https://wiki.postgresql.org/wiki/Show_database_bloat, чтобы увидеть находится ли база данных в оптимальном или раздутом (bloat) состоянии.
|
|
|
|
|
|
```sql
|
|
|
SELECT
|
|
|
current_database(), schemaname, tablename, /*reltuples::bigint, relpages::bigint, otta,*/
|
|
|
ROUND((CASE WHEN otta=0 THEN 0.0 ELSE sml.relpages::float/otta END)::numeric,1) AS tbloat,
|
|
|
CASE WHEN relpages < otta THEN 0 ELSE bs*(sml.relpages-otta)::BIGINT END AS wastedbytes,
|
|
|
iname, /*ituples::bigint, ipages::bigint, iotta,*/
|
|
|
ROUND((CASE WHEN iotta=0 OR ipages=0 THEN 0.0 ELSE ipages::float/iotta END)::numeric,1) AS ibloat,
|
|
|
CASE WHEN ipages < iotta THEN 0 ELSE bs*(ipages-iotta) END AS wastedibytes
|
|
|
FROM (
|
|
|
SELECT
|
|
|
schemaname, tablename, cc.reltuples, cc.relpages, bs,
|
|
|
CEIL((cc.reltuples*((datahdr+ma-
|
|
|
(CASE WHEN datahdr%ma=0 THEN ma ELSE datahdr%ma END))+nullhdr2+4))/(bs-20::float)) AS otta,
|
|
|
COALESCE(c2.relname,'?') AS iname, COALESCE(c2.reltuples,0) AS ituples, COALESCE(c2.relpages,0) AS ipages,
|
|
|
COALESCE(CEIL((c2.reltuples*(datahdr-12))/(bs-20::float)),0) AS iotta /* very rough approximation, assumes all cols */
|
|
|
FROM (
|
|
|
SELECT
|
|
|
ma,bs,schemaname,tablename,
|
|
|
(datawidth+(hdr+ma-(case when hdr%ma=0 THEN ma ELSE hdr%ma END)))::numeric AS datahdr,
|
|
|
(maxfracsum*(nullhdr+ma-(case when nullhdr%ma=0 THEN ma ELSE nullhdr%ma END))) AS nullhdr2
|
|
|
FROM (
|
|
|
SELECT
|
|
|
schemaname, tablename, hdr, ma, bs,
|
|
|
SUM((1-null_frac)*avg_width) AS datawidth,
|
|
|
MAX(null_frac) AS maxfracsum,
|
|
|
hdr+(
|
|
|
SELECT 1+count(*)/8
|
|
|
FROM pg_stats s2
|
|
|
WHERE null_frac<>0 AND s2.schemaname = s.schemaname AND s2.tablename = s.tablename
|
|
|
) AS nullhdr
|
|
|
FROM pg_stats s, (
|
|
|
SELECT
|
|
|
(SELECT current_setting('block_size')::numeric) AS bs,
|
|
|
CASE WHEN substring(v,12,3) IN ('8.0','8.1','8.2') THEN 27 ELSE 23 END AS hdr,
|
|
|
CASE WHEN v ~ 'mingw32' THEN 8 ELSE 4 END AS ma
|
|
|
FROM (SELECT version() AS v) AS foo
|
|
|
) AS constants
|
|
|
GROUP BY 1,2,3,4,5
|
|
|
) AS foo
|
|
|
) AS rs
|
|
|
JOIN pg_class cc ON cc.relname = rs.tablename
|
|
|
JOIN pg_namespace nn ON cc.relnamespace = nn.oid AND nn.nspname = rs.schemaname AND nn.nspname <> 'information_schema'
|
|
|
LEFT JOIN pg_index i ON indrelid = cc.oid
|
|
|
LEFT JOIN pg_class c2 ON c2.oid = i.indexrelid
|
|
|
) AS sml
|
|
|
ORDER BY wastedbytes DESC;
|
|
|
```
|
|
|
|
|
|
Колонки показывающие объём места, занимаемого удалёнными данными `wastedbytes` и индекс `wastedibytes` покажут наличие проблемы.
|
|
|
|
|
|
Postgres по умолчанию включает регулярное выполнение процедуры очистки. Вы можете посмотреть время последней запросом
|
|
|
```sql
|
|
|
SELECT relname, last_vacuum, last_autovacuum
|
|
|
FROM pg_stat_user_tables;
|
|
|
```
|
|
|
|
|
|
Очистку также можно запустить вручную утилитой `vacuumdb`. Попробуйте это сделать и вызвать запрос ещё раз.
|
|
|
|
|
|
## Релевантные источники
|
|
|
- Мартин Грабер — Понимание SQL
|
|
|
- https://www.postgresql.org/docs/
|
|
|
- https://theartofpostgresql.com
|
|
|
- https://www.crunchydata.com/developers/tutorials |