Выбор файловой системы для postgresql

Обновлено: 06.07.2024

PostgreSQL, как сказано на её официальном сайте, это самая продвинутая в мире реляционная база данных с открытым исходным кодом.

Использование PostgreSQL

Как запустить службу PostgreSQL. Как управлять службой PostgreSQL

Запуск службы PostgreSQL:

Остановка службы PostgreSQL:

Добавление службы PostgreSQL в автозагрузку:

Удаление службы PostgreSQL из автозагрузки:

Для просмотра состояния процесса PostgreSQL:

Альтернативный вариант запуска службы для работы с определённой базой данных следующий:

Как узнать, какая версия PostgreSQL запущена

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

Для определения версии сервера выполните команду:

Для определения версии клиента:

Ещё один вариант определения версии PostgreSQL:

Если вам нужен только номер версии (например, для скрипта), то используйте следующую команду:

Хотя вместо postgres можно использовать postmaster, использование postgres предпочтительнее, поскольку postmaster это устаревший псевдоним для postgres.

Если вы предпочитаете вариант с SQL, то подключитесь к интерактивному терминалу:

Также вам может пригодиться один из следующих вариантов

Как инициализировать базу данных PostgreSQL

Остановите службу, если она запущена:

Директория /var/lib/postgres/ должна принадлежать пользователю postgres:

Смените пользователя на postgres:

Выполните инициализацию БД:

Если вы столкнулись с ошибкой:

То найдите расположение файла initdb:

И укажите до него полный путь в команде инициализации:

Нажмите CTRL+D

Запустите службу PostgreSQL:

Создайте нового пользователя (например, user):

При желании, вы можете установить пароль для пользователя, это делается командой с ключом -W:

Создайте базу данных (например, my-first-db):

Как подключиться к локальному серверу PostgreSQL

Для подключения к интерактивному терминалу PostgreSQL используется команда psql.

Примеры синтаксиса команд:

Для psql требуется указать имя пользователя и если он не указан, то пересылается имя текущего пользователя системы, который скорее всего отсутствует в базе данных PostgreSQL, что вызывает ошибку. По умолчанию создаётся пользователь postgres, поэтому без дополнительной настройке вы можете подключиться к серверу PostgreSQL следующим образом:

Какой конфигурационный файл использует PostgreSQL

Конфигурационный файл PostgreSQL носит имя postgresql.conf.

В системе может быть несколько конфигурационных файлов PostgreSQL. Вы можете найти их командой:

Что особенно важно, systemd может использовать свои собственные конфигурационные файлы, например:

/usr/lib/systemd/system/postgresql@.service.d/kali_postgresql.conf (путь в Kali Linux)
/usr/lib/sysusers.d/postgresql.conf (путь в Arch Linux)

Если вы настраиваете PostgreSQL, но после перезапуска службы с помощью systemd (systemctl) изменения не применяются, возможно, вы просто редактируете неверный файл.

Также конфигурационный файл имеется в директории с базой данных, например:

/var/lib/postgres/data/postgresql.conf

С пакетом PostgreSQL могут поставляться образцы конфигурационных файлов, например:

/usr/share/postgresql/14/postgresql.conf.sample
/usr/share/postgresql/postgresql.conf.sample

Как обновить базу данных PostgreSQL при переходе на новую версию

Оно означает, что в системе 2 установленные версии PostgreSQL:

Если запустить службу PostgreSQL командой:

И проверить версию командой:

То будет выведено следующее:

То есть по умолчанию используется 13, устаревшая версия.

Удаление старых версий пакетов, например, командой:

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

Последующие действия подразумевают, что вы

1) установили новую версию PostgreSQL, но ещё не использовали её, то есть не сохраняли базы данных, поскольку файлы новой версии будут удалены.

2) хотите перенести старые база данных в новый формат

С помощью следующей команды просмотрите доступные кластеры:

На скриншоте только один из них online (я успел удалить пакет postgresql-13), но у вас оба должны быть online, иначе перенос базы данных не удастся.

Пример правильного вывода:

Как можно увидеть, обе версии 13 и 14 в настоящее время установлены и запущены. Держите в уме, что при переносе старой базы данных в новый формат вам понадобиться двойной объём места на диске, поскольку pg_upgradecluster копирует данные.

Процедура обновления включает в себя следующее:

1. Удаляем данные новой версии:

2. Запускаем процедуру обновления кластера:

3. Когда операция будет завершена, дважды проверьте, что всё работает

4. Удалите старую версию

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

Вновь проверяем версию:

Теперь используется 14, то есть самая последняя версия.

В чём разница между postgres и psql

postgres

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

Один экземпляр postgres всегда управляет данными только одного кластера базы данных. Кластер базы данных — это набор баз данных, который хранится в общей папке файловой системы («область данных»). В системе может работать более одного экземпляра postgres одновременно, если они используют разные области данных и разные порты связи. Когда postgres запускается, ему необходимо знать расположение области данных. Местоположение должно быть указано параметром -D или переменной среды PGDATA; по умолчанию это значение не установлено. Обычно -D или PGDATA указывает непосредственно на каталог области данных, созданный initdb.

Чтобы запустить сервер в однопользовательском режиме, используйте такую команду, как

Чтобы запустить postgres в фоновом режиме со значениями по умолчанию, введите:

Чтобы запустить postgres с определенным портом, например, 1234:

Чтобы подключиться к этому серверу с помощью psql, укажите этот порт с параметром -p:

или установите переменную окружения PGPORT:

psql

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

Пример запуска psql:

Запуск psql от пользователя postgres, который создаётся по умолчанию:

Ошибки PostgreSQL

psql: error: не удалось подключиться к серверу: Нет такого файла или каталога

При попытке подключиться к серверу PostgreSQL или выполнить запрос на сервере PostgreSQL, например:

вы можете столкнуться с ошибкой:

В англоязычной версии эта ошибка выглядит так:

Эта ошибка означает, что служба PostgreSQL не запущена, для её запуска выполните команду:

Альтернативный вариант запуска службы следующий:

Другой возможной причиной ошибки может быть то, что psql ищет файл сокета в неверной директории: например, файл сокета помещён в /tmp, а psql ищет его в /run/postgresql/. В этом случае вы можете с помощью опции --host явно указать директорию, в которой находится сокет:

FATAL: не удалось создать файл блокировки "/run/postgresql/.s.PGSQL.5432.lock": Нет такого файла или каталога

При запуске системы БД, например, следующей командой:

Вы можете столкнуться с ошибкой:

В англоязычной версии ошибка выглядит так:

Создать данную директорию (если она отсутствует) и сделать её владельцем пользователя postgres
Отредактировать конфигурационный файл так, чтобы служба пыталась создавать файл блокировки в директории /tmp, на которую у всех пользователей есть право записи

Первый вариант — создаём директорию /run/postgresql/ и назначаем её владельцем пользователя postgres:

Второй вариант — открываем конфигурационный файл postgresql.conf (у вас может быть другое расположение)

И добавляем туда следующую запись:

sudo: postgres: command not found

Если при использовании postgres вы столкнулись с ошибкой:

то у этой проблемы может быть две возможных причины:

1. Не установлен пакет postgresql.

Установите его одной из следующих команд.

В Debian, Kali Linux, Linux Mint, Ubuntu и их производных:

В Arch Linux, Manjaro, BlackArch и их производных:

2. Исполнимый файл postgres находится за пределами $PATH

Это необязательно говорит о проблеме — такой подход может использоваться для возможности иметь на одном компьютере сразу несколько серверов PostgreSQL.

Найдите исполнимый файл

Как можно видеть на скриншоте, исполнимый файл присутствует для двух версий сервера:

/usr/lib/postgresql/13/bin/postgres
/usr/lib/postgresql/14/bin/postgres

Теперь вместо postgres используйте полный путь в команде запуска, например:

psql: ошибка: ВАЖНО: роль "" не существует

При попытке запуска интерактивного терминала PostgreSQL

Вы можете столкнуться с ошибкой:

Имя пользователя может быть другим — там будет показано имя того пользователя, котоырй пытается выполнить вход.

В англоязычной версии ошибка выглядит так:

Для psql необходимо имя пользователя и если оно не указано явно, то передаётся имя пользователя системы. Но поскольку данный пользователь не существует на сервере PostgreSQL, то возникает указанная выше ошибка.

Вы можете создать пользователя с любы именем, как это показано выше и ошибка исчезнет.

По умолчанию присутствует пользователь postgres, поэтому вы можете подключиться от его имени:

Вы должны указать его расположение в параметре --config-file или -D, либо установить переменную окружения PGDATA

При запуске postgres вы можете столкнуться с ошибкой:

В англоязычной версии:

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

Конфигурационный файл называется postgresql.conf, но нужно указать не его, а директорию, в которой он содержится. Например:

initdb: command not found

Смотрите объяснение данной проблемы, а также дополнительные пути устранения в описании аналогичной ошибки: sudo: postgres: command not found

Найдите initdb с помощью:

/usr/lib/postgresql/13/bin/initdb
/usr/lib/postgresql/14/bin/initdb

И используйте в ваших командах абсолютный путь до файла initdb нужной вам версии, например:

Статья — заметка, выросшая из вопроса, заданного в Q&A. Вкратце дело было так… Был предложен вариант тестирования PostgreSQL на определенной файловой системе и стоял вопрос, нормальный ли это подход и можно ли хоть как-то доверять результатам этого теста. В ходе обсуждения вопроса альтернативных вариантов не нашлось и я решил тестировать как и задумал изначально.

HP Proliant DL160 G5
1x Intel Xeon CPU E5405 @ 2.00GHz (L1 128KiB, L2 12MiB)
4x FB-DIMM DDR2 Synchronous 667 MHz (1.5 ns) итого 8GB RAM
RAID LSI SAS1064E 4-Port PCI-E 3Gb/s
4x SAS HP DF146BABUE 146GB 3.5" LFF 3G 15K RPM
Gentoo Linux kernel-3.7.1, glibc-2.15-r3, gcc-4.5.4
PostgreSQL Server 9.2.1

форматируем том и монтируем в каталог;
запускаем инициализацию postgresql-кластера;
копируем в кластер заранее подготовленный конфигурационный файл postgresql.conf;
запускаем postgresql и создаем тестовую базу pgbench;
запускаем инициализацию таблиц с помощью pgbench;
циклически в режиме «SELECT's only» запускаем pgbench с разным количество клиентских подключений, результаты сохраняем (каждый тест длится 2 часа)
циклически в режиме "TPC-B" запускаем pgbench с разным количество клиентских подключений, результаты сохраняем (каждый тест длится 2 часа).

RAID работает без WriteCache;
все процессы/сервисы были остановлены/выключены за исключением PostgreSQL, таблица процессов практически пуста (за исключением ядерных процессов);
WAL журналы живут на том же разделе что и данные;
тестовая база инициализировалась таким образом, чтобы занять 80% пространства всего диска;
перед каждым запуском pgbench выполнялся сброс кэшей.

Настройки postgresql.conf
max_connections = 100
shared_buffers = 1500MB
work_mem = 16MB
maintenance_work_mem = 128MB
effective_io_concurrency = 1
checkpoint_segments = 32
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9

Результаты для «SELECT's only» и TPC-B

Выводы: вобщем как и ожидалось прорывных и революционных разрывов в результатах нет, все файловые системы вобщем имеют приблизительно одинаковый уровень производительности. Если же приглядываться, то можно отметить несколько моментов:
— ext4 показывает чуть большую производительность чем ext3 (в среднем на 1-3%);
— ext4 показывает наибольшую производительность в TPC-B тесте (от 1% до 8%);
— xfs показывает наибольшую производительность в SELECT's only (от 1% до 3%);

В целом можно сказать «а можно ставить любую фс, разница настолько мала, что ею можно пренебречь». Но помните что (тут можно вставить любую пафосную фразу про важность мелочей). В общем, не пренебрегайте мелочами))

На этом все. Можно ~~кидаться какашками,~~ критиковать, высказывать мысли, выносить свои идеи…

С точки зрения файловой системы кластер баз данных представляет собой один каталог, в котором будут храниться все данные. Мы называем его каталогом данных или областью данных. Где именно хранить данные, вы абсолютно свободно можете выбирать сами. Какого-либо стандартного пути не существует, но часто данные размещаются в /usr/local/pgsql/data или в /var/lib/pgsql/data . Прежде чем с каталогом данных можно будет работать, его нужно инициализировать, используя программу initdb , которая устанавливается в составе PostgreSQL .

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

Чтобы инициализировать кластер баз данных вручную, запустите initdb , передав в параметре -D путь к желаемому расположению данных кластера в файловой системе, например:

Заметьте, что эту команду нужно выполнять от имени пользователя PostgreSQL , о котором говорится в предыдущем разделе.

Подсказка

В качестве альтернативы параметра -D можно установить переменную окружения PGDATA .

Также можно запустить команду initdb , воспользовавшись программой pg_ctl , примерно так:

Этот вариант может быть удобнее, если вы используете pg_ctl для запуска и остановки сервера (см. Раздел 18.3), так как pg_ctl будет единственной командой, с помощью которой вы будете управлять экземпляром сервера баз данных.

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

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

Так как каталог данных содержит все данные базы, очень важно защитить его от неавторизованного доступа. Для этого initdb лишает прав доступа к нему всех пользователей, кроме пользователя PostgreSQL и, возможно, его группы. Если группе разрешается доступ, то только для чтения. Это позволяет непривилегированному пользователю, входящему в одну группу с владельцем кластера, делать резервные копии данных кластера или выполнять другие операции, для которых достаточно доступа только для чтения.

Заметьте, чтобы корректно разрешить или запретить доступ группы к данным существующего кластера, необходимо выключить кластер и установить соответствующий режим для всех каталогов и файлов до запуска PostgreSQL . В противном случае в каталоге данных возможно смешение режимов. Для кластеров, к которым имеет доступ только владелец, требуется установить режим 0700 для каталогов и 0600 для файлов, а для кластеров, в которых также разрешается чтение группой, режим 0750 для каталогов и 0640 для файлов.

Однако даже когда содержимое каталога защищено, если проверка подлинности клиентов настроена по умолчанию, любой локальный пользователь может подключиться к базе данных и даже стать суперпользователем. Если вы не доверяете другим локальным пользователям, мы рекомендуем использовать один из параметров команды initdb : -W , --pwprompt или --pwfile и назначить пароль суперпользователя баз данных. Кроме того, воспользуйтесь параметром -A md5 или -A password и отключите разрешённый по умолчанию режим аутентификации trust ; либо измените сгенерированный файл pg_hba.conf после выполнения initdb , но перед тем, как запустить сервер в первый раз. (Возможны и другие разумные подходы — применить режим проверки подлинности peer или ограничить подключения на уровне файловой системы. За дополнительными сведениями обратитесь к Главе 20.)

Команда initdb также устанавливает для кластера баз данных локаль по умолчанию. Обычно она просто берёт параметры локали из текущего окружения и применяет их к инициализируемой базе данных. Однако можно выбрать и другую локаль для базы данных; за дополнительной информацией обратитесь к Разделу 23.1. Команда initdb задаёт порядок сортировки по умолчанию для применения в определённом кластере баз данных, и хотя новые базы данных могут создаваться с иным порядком сортировки, порядок в базах-шаблонах, создаваемых initdb, можно изменить, только если удалить и пересоздать их. Также учтите, что при использовании локалей, отличных от C и POSIX , возможно снижение производительности. Поэтому важно правильно выбрать локаль с самого начала.

Команда initdb также задаёт кодировку символов по умолчанию для кластера баз данных. Обычно она должна соответствовать кодировке локали. За подробностями обратитесь к Разделу 23.3.

Для локалей, отличных от C и POSIX , порядок сортировки символов зависит от системной библиотеки локализации, а он, в свою очередь, влияет на порядок ключей в индексах. Поэтому кластер нельзя перевести на несовместимую версию библиотеки ни путём восстановления снимка, ни через двоичную репликацию, ни перейдя на другую операционную систему или обновив её версию.

18.2.1. Использование дополнительных файловых систем

Во многих инсталляциях кластеры баз данных создаются не в « корневом » томе, а в отдельных файловых системах (томах). Если вы решите сделать так же, то не следует выбирать в качестве каталога данных самый верхний каталог дополнительного тома (точку монтирования). Лучше всего создать внутри каталога точки монтирования каталог, принадлежащий пользователю PostgreSQL , а затем создать внутри него каталог данных. Это исключит проблемы с разрешениями, особенно для таких операций, как pg_upgrade , и при этом гарантирует чистое поведение в случае, если дополнительный том окажется отключён.

18.2.2. Файловые системы

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

18.2.2.1. NFS

Использовать параметр монтирования sync не обязательно. Поведения режима async достаточно, так как PostgreSQL вызывает fsync в нужные моменты для сброса кеша записи (так же, как и с локальной файловой системой). Однако параметр sync настоятельно рекомендуется использовать при экспортировании файловой системы на сервере NFS в тех ОС, где он поддерживается (в основном это касается Linux). В противном случае не гарантируется, что в результате выполнения fsync или аналогичного вызова NFS-клиентом данные действительно окажутся в надёжном хранилище на сервере, вследствие чего возможно повреждение данных, как и при выключенном параметре fsync. Значения по умолчанию параметров монтирования и экспортирования меняются от производителя к производителю и от версии к версии, поэтому рекомендуется перепроверить их или, возможно, явно задать нужные значения во избежание неоднозначности.

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

Если вы читали руководство, вы, должно быть, слышали о концепции кластера postgresql. Когда вы впервые услышите эту концепцию, вы можете немного запутаться. Кластер генерируется инструментом initdb при установке базы данных.Папку pgdata, созданную после initdb, можно понимать как физическую структуру хранения кластера. Когда база данных запускается и останавливается, папка, указанная параметром pg_ctl -D, является папкой кластера, поэтому PG-сервер может работать на PG-кластере.

Определение понятия объектов базы данных в СУБД:

any defined object in a database that is used to store or reference data

Объекты базы данных в PG включают, например: таблицы кучи, индексы, последовательности, функции и т. Д.

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

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

2 Физическая структура организации

2.1 Файловая структура

Теперь, чтобы инициализировать кластер, используйте спецификацию initdb, чтобы указать путь генерации.

После указания tree наблюдает за структурой каталогов файлов PGDATA

Корневой каталог вышеупомянутой файловой структуры - это папка PGDATA, созданная initdb, которая соответствует физической структуре хранения кластера (внутреннюю часть папки BASE см. В следующем разделе)

пункт	описание
PG_VERSION	Файл, содержащий основной номер версии PostgreSQL.
base	Содержит подкаталоги, соответствующие каждой базе данных
current_logfiles	Запишите файл журнала, который в настоящее время записывается сборщиком журналов
global	Подкаталог, содержащий таблицу с областью кластера, например pg_database
pg_commit_ts	Подкаталог, содержащий данные отметки времени фиксации транзакции
pg_dynshmem	Подкаталог, содержащий файлы, используемые подсистемой динамической общей памяти.
pg_logical	Подкаталог, содержащий данные о состоянии для логической репликации
pg_multixact	Подкаталог, содержащий данные о состоянии нескольких транзакций (для общих блокировок строк)
pg_notify	Подкаталог с данными статуса LISTEN / NOTIFY
pg_replslot	Подкаталог, содержащий данные слота репликации
pg_serial	Подкаталог, содержащий информацию об отправленных сериализуемых транзакциях.
pg_snapshots	Подкаталог, содержащий экспортированные снимки
pg_stat	Подкаталог, содержащий постоянные файлы для подсистемы статистики.
pg_stat_tmp	Подкаталог, содержащий временные файлы, используемые для подсистемы статистической информации
pg_subtrans	Поддиректория, содержащая данные о статусе суб-транзакций
pg_tblspc	Подкаталог, содержащий символические ссылки на табличные пространства
pg_twophase	Содержит подкаталоги для подготовки файлов состояния транзакции
pg_wal	Подкаталог, содержащий файлы WAL (журнал упреждающей записи)
pg_xact	Подкаталог, содержащий данные о статусе фиксации транзакции.
postgresql.auto.conf	Один для хранения ALTER SYSTEM Установите файл параметров конфигурации
postmaster.opts	Файл, в котором записаны параметры командной строки, использованные при последнем запуске сервера.
postmaster.pid	Файл блокировки, который записывает текущий идентификатор процесса postmaster (PID), путь к каталогу данных кластера, метку времени запуска postmaster, номер порта, путь к каталогу сокета домена Unix (пустой в Windows) и первый доступный listen_address ( IP-адрес или * , Или пустой означает, что TCP не прослушивается) и идентификатор сегмента общей памяти (файл не существует после закрытия сервера)

2.2 Организационная структура обычного табличного файла

Для каждой базы данных есть соответствующий подкаталог в PGDATA / base, а имя подкаталога - это OID базы данных в pg_database.

Давайте создадим таблицу ниже. Файл таблицы можно найти двумя способами:

Выполните запрос pg_class.relfilenode, чтобы получить relfilenode = 16384 таблицы tbl1. Для обычных файлов таблиц укажите номер файлового узла таблицы или индекса.

Таблица создается в библиотеке postgres, мы можем войти в каталог base / 13158, чтобы увидеть файл таблицы:

При определенных операциях с базой данных файлы таблиц перераспределяются, например truncate (Это также причина, по которой усечение выполняется быстрее, чем удаление).

2.3 Организационная структура файла системной таблицы

После инициализации системы таблицы не создаются, но многие файлы таблиц были созданы в base / 13158 /. Эти файлы являются текущими системными таблицами базы данных, такими как pg_class. Обратите внимание, что relfilenode системной таблицы равен 0. Для поиска таблицы можно использовать функцию oid скрытого столбца или pg_relation_filepath. файл.

Существует два типа системных таблиц: один - это уникальные системные таблицы в каждой базе данных, а другой - системные таблицы, общие для всех баз данных. Почему существуют общие таблицы? Например, pg_database записывает информацию обо всех базах данных в кластере, и нет необходимости хранить отдельную копию для каждой базы данных. Общие системные таблицы хранятся в $PGDATA/global/ Под содержимым.

Можно увидеть в каталоге данных *_fsm с участием *_vm Соответствуют два типа файлов, два типа файлов и файлы таблиц, которые будут представлены в следующих главах.

2.4 Табличное пространство

Табличное пространство можно понимать как каталог для хранения файлов таблиц. Табличное пространство обеспечивает гибкий метод управления хранением таблиц:
Например, когда текущий диск почти заполнен, вы можете создать табличное пространство в любой вновь смонтированной файловой системе и сохранить таблицу в новом каталоге; часто используемую таблицу можно поместить в IO. На дисках с более высокой производительностью, например SSD. Таблицы данных, которые используются редко, можно хранить на более дешевой и медленной дисковой системе.

Есть два способа использовать табличное пространство:

Укажите табличное пространство при создании таблицы
Укажите табличное пространство при создании базы данных

Создать табличное пространство

После создания табличного пространства вы можете $PGDATA/pg_tblspc Найдите символьную ссылку табличного пространства и обратите внимание, что путь к табличному пространству должен быть согласованным после резервного копирования и восстановления.

Адрес, возвращаемый pg_relation_filepath pg_tblspc/46803/PG_10_201707211/13158/46807 , PG использует ссылку в каталоге pg_tblspc для поиска соответствующего табличного пространства. Настоящий каталог файла таблицы:

Где PG_10_201707211 определяется в соответствии с номером версии:

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

3 Организационная структура табличного файла

Табличный файл по умолчанию состоит из блока размером 8 КБ, а 8 КБ является базовой единицей чтения и записи базы данных. «Анализ ядра базы данных PostgreSQL» описывается так:

Каждая страница состоит из пяти частей.

пункт	описание
PageHeaderData	Длина 24 байта. Содержит общую информацию о странице, включая указатели свободного места.
ItemIdData	Массив пар записей (смещение, длина), указывающих на фактический элемент. Каждый элемент занимает 4 байта.
Free space	Нераспределенное пространство (свободное место). Указатели новых элементов выделяются с начала этой области, а новые элементы - с конца.
Items	Сам предмет.
Special space	Индексируйте данные, относящиеся к шаблонам доступа. В разных методах доступа к индексу хранятся разные данные. В обычной таблице пусто.

Первые 24 байта страницы образуют PageHeaderData. После заголовка страницы идет 4-байтовый ItemIdData, который является LinpX в пути, его можно понять как указатель на фактическое место хранения кортежа (TupleX на рисунке). Обратите внимание, что порядок хранения linp и кортежа следующий. И наоборот, linp растет сверху вниз, а кортеж - снизу вверх.

Информация о текущей странице определяется в PageHeaderData:

площадь	Виды	длина	описание
pd_lsn	PageXLogRecPtr	8 bytes	LSN: первый байт после последнего байта записи WAL, которая последней изменила эту страницу.
pd_checksum	uint16	2 bytes	Код проверки страницы
pd_flags	uint16	2 bytes	Флаговый бит
pd_lower	LocationIndex	2 bytes	Смещение к началу свободного места
pd_upper	LocationIndex	2 bytes	Смещение до конца свободного места
pd_special	LocationIndex	2 bytes	Смещение к началу особого пространства
pd_pagesize_version	uint16	2 bytes	Информация о размере страницы и номере версии макета
pd_prune_xid	TransactionId	4 bytes	Самый старый восстановленный XMAX на странице или 0, если его нет

После заголовка ItemIdData из кода видно, что это 4-байтовая структура, используемая для побитовой разборки. Он записывает смещение, биты атрибутов и длину кортежа.

Кортеж обычно состоит из нескольких частей:

The overall structure of a heap tuple looks like:

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

Информация, хранящаяся в HeapTupleHeaderData, является основой для реализации механизма MVCC.

площадь	Виды	длина	описание
t_xmin	TransactionId	4 bytes	Вставить логотип XID
t_xmax	TransactionId	4 bytes	Удалить логотип XID
t_cid	CommandId	4 bytes	Вставить и / или удалить флаги CID (перезаписать t_xvac)
t_xvac	TransactionId	4 bytes	Операция VACUUM перемещает XID версии строки
t_ctid	ItemPointerData	6 bytes	TID текущей версии или указать на обновленную версию строки
t_infomask2	uint16	2 bytes	Некоторые атрибуты плюс несколько флагов
t_infomask	uint16	2 bytes	Несколько флагов
t_hoff	uint8	1 byte	Смещение к пользовательским данным

Когда кортеж получается путем сканирования таблицы или индекса, кажется, что он просто получил искаженные символы. Имеет смысл разделить данные с информацией о структуре таблицы. Информация о структуре таблицы хранится в системной таблице pg_attribute. Ключевые значения для определения позиции домена - attlen и attalign.

4 Считанные данные таблицы

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

Читайте также: