PostgreSQL максимизирует производительность SSD


19

У меня будет огромная база данных PostgreSQL 9.3 с множеством таблиц с более чем 100 миллионами записей в таблице. Эта база данных будет в основном доступна только для чтения (как только я заполню все необходимые таблицы и создаю индексы, больше нет операций записи в БД) и однопользовательского доступа (запуск и тестирование нескольких запросов от localhost), так как будет использоваться БД только для исследовательских целей. Запросы всегда будут использовать JOIN для целочисленных полей БД.

Я, вероятно, куплю SSD (256-512 ГБ) для этой цели. Я не использовал SSD для БД раньше, так что есть что-то, чего я должен бояться? Можно ли поставить всю БД на SSD или только индексы? Есть ли какой-то конкретный совет / учебное пособие, необходимое для настройки PostgreSQL для твердотельных накопителей? Обратите внимание, что у меня есть хорошая рабочая станция с i7 и 32 ГБ оперативной памяти, так что, возможно, вы тоже можете дать несколько советов.

Ответы:


16

так чего мне бояться?

Не имея резервных копий. Как и любое устройство хранения, оно может умереть. Храните резервные копии.

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

Можно ли поставить всю БД на SSD или только индексы?

Если это подходит, храните всю БД.

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

Есть ли какой-то конкретный совет / учебное пособие, необходимое для настройки PostgreSQL для твердотельных накопителей?

Большинство преимуществ SSD для загрузки записи OLTP. Основным преимуществом для загрузок только для чтения является быстрый поиск, и slardiere покрыл это.

Возможно, вы захотите установить effective_io_concurrency = 5или что-то в этом роде, чтобы отразить тот факт, что твердотельные накопители могут выполнять быстрые, сильно конвейерные случайные операции чтения ... но это влияет только на сканирование растровых индексов, и на практике это random_page_costуже включено.

Для нагрузки только для чтения это не имеет большого значения.

Для начальной загрузки данных см .:

Обратите внимание, что у меня есть хорошая рабочая станция с i7 и 32 ГБ оперативной памяти, так что, возможно, вы тоже можете дать несколько советов.

Установите большой maintenance_work_memдля загрузки данных. Я бы использовал по крайней мере 8GB.

Установите большой work_memдля запрашивающей работы. Подходящий размер зависит от сложности запроса. Начните с 500MBи поднимитесь оттуда.

Увеличьте ваш checkpoint_segments(массово) для начальной загрузки данных.

Не забудьте отключить VM overcommit! (см. руководство по PostgreSQL: http://www.postgresql.org/docs/current/static/kernel-resources.html ).


22

Что касается твердотельных накопителей, основной совет - понизить значение random_page_cost до 1 (равно 'seq_page_cost') в postgresql.conf, в дополнение к другим обычным настройкам.


Возможно, оба значения должны быть меньше 1,0, как указано в postgresql.org/docs/11/… : «Вы можете увеличивать или уменьшать оба значения вместе, чтобы изменить важность затрат на дисковый ввод-вывод относительно затрат на ЦП, которые описываются следующие параметры ".
Кирилл Булыгин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.