Накопление знаний

Dev/SDx/ - mount (ext4,xfs, btrfs) и снова про PG

Но начнём мы с MSSQL - если вы собираетесь мигрировать на PG начните с другого. Точно убедитесь что у вас

  • MSSQL старше версии 2012 SP1 - то есть если вы решили мигрировать не обновив текущую СУБД, скорее всего миграция не для Вас.

Почему так в большинстве своём уже миллион раз обсуждалось, но я напомню - в связи с разными коммерческими интересами Microsoft часть "очень сильно платной функциональности" портировал в меньшую лицензию Standart.

Помимо низкоуровневых особенностей - важным является Сжатие.
Применяется быстро и сокращает объем диска (архивные копии также сжимаются).

Быстрые диски дороже быстрых процессоров


собственно здесь мы и переходим к теме поста - а какие диски нужны под PG. Учитывая что редакция 12.x наконец-то "неназывнной компанией из двух букв" опубликована как "потенциально стабильная) - хотя нормальные пацаны давно ждут 13-тую редакцию.http://repo.postgrespro.ru/1c-archive/


Опять же напомню, что в 12-той редакции есть 1 важный момент


  • в 12-той редакции индкесы btree на тестах показывают уменьшение размера на 33%

Те кто подписан на список рассылки PG - могут даже найти как так получилось и почему структура хранения поменялась.

Но вернемся к дискам - итак у нас есть операционная система *nix (ну например CentOS) и у нас есть люди которые не боятся "командной строки".

Делаем диски - для удобства лучше почитать https://www.reddit.com/r/DataHoarder/comments/f5uzv8/filesystem_efficiancy_comparision_of_ext4_xfs/

  • /dev/sda (xfs) -> mount /
  • /dev/sdb (btrfs) -> mount /var/lib/pg12pro
  • /dev/sdc (btrfs) -> mount /data/v8data
  • /dev/sdd (btrfs) -> mount /data/v8index
  • /dev/sde (ext4) -> mount /archive

Касательно последнего - данный диск делается для любителей Pgdump - им туда делать бэкапы. Особая заметка для владельцев vmWare vCloud Dicrector - лучше всего для архивных копий использовать IndependentDisk - его можно подключить ко всем контурам с PG, данный независимый диск конечно медленный по сравнению с SSD, но зато это будет единое хранилище архивных копий, которое уже можно "ЭрСинкить".

Внимательный читател видит что используетс BTRFS - оно используется в связи с вот этой функциональностью https://btrfs.wiki.kernel.org/index.php/Compression
Фактически применительно к PG мы используем TOAST сжатие, которое родное, а также испольуем сжатие на уровне файловой системы. Процессорного времени нам не жалко.

Не забываем про табличные пространства


На самом деле ни называются v81c_data и v81c_index, что кстати нам намекает "когда" было созданно данное архитектурное решение (еще во времена 8.1 наверное).

Вообще-то табличных пространств должно быть 3 (три), а не 2 - но это если у вас есть много RAM.

CREATE TABLESPACE %I OWNER %I LOCATION %L

ну и соответственно - мы делаем

  • v81c_data -> /data/v8data
  • v81c_index -> /data/v8index
  • tmptblspc -> /tmp/pgtemp

Касательно последнего - суть в том чтобы ту нагрузку для которой не хватило выделнной памяти ы файле postgresql постараться увести в RAM хотя бы средствами операционной системы (я напомню что часть операций ORDER BY выполняется напрямую на диске, в случаях нехватки памяти выденной в WorkMem)

PG то однопоточный


И этот тезис - самый главный - формально исполнитель одного запроса, будет работать в один поток. Но если мы используем старшие версии - 12-тую и выше, часть операций уже могут быть парралельными - а в случаях когда у нас 4 диска (включая temp) - исполнителю запроса будет проще создать 4 отдельных потока и они будут работать более быстро, так как будут использовать 4 независимых диска. Иначе вся эта паррельность будет утыкаться в "один" контролер дискового устройства. Снижая весь выйгрыш.

Как обычно в мире PG - всё это действо надо мониторить и тестировать. Для скорости могу посоветовать OKmeter, но если есть время - то конечно лучше посмотреть в сторону


В качестве завершения заметки, создается такое ощущение, что накопленные компетенции по PG+1C каждый DBA оставляет при себе, и каждому последующему DBA приходится проходить "с нуля" все возможные грабли. Получается сложность такого процесса O(n) - где n: количество развертываний СУБД PG. При таком подходе MSSQL 2019 с его улучшениями в части tempDB может и победить ;-).

Полезная ссылка для чтива в метро на сегодня: