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


19

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

Я, мабуть, куплю SSD (256-512GB) для цієї мети. Я раніше не використовував SSD для БД, тому є чого, чого я повинен боятися? Чи можу я поставити всю БД на SSD або просто індекси? Чи потрібна певна порада / посібник для настройки PostgreSQL для SSD? Зауважте, що у мене гарна робоча станція з i7 та 32Gb оперативної пам’яті, тому, можливо, ви можете також порадити там.

Відповіді:


16

так чи є чогось, чого я повинен боятися?

Не має резервного копіювання. Як і будь-який запам'ятовуючий пристрій, він може загинути. Зберігайте резервні копії.

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

Чи можу я поставити всю БД на SSD або просто індекси?

Якщо вона підходить, зберігайте всю БД.

Якщо цього не відбувається, покладіть на SSD простір таблиць і використовуйте його для зберігання індексів і стільки запитуваних таблиць, скільки підходить.

Чи потрібна певна порада / посібник для настройки PostgreSQL для SSD?

Більшість переваг SSD є для завантаження OLTP записом. Основна перевага для завантаження лише для читання - це швидке прагнення, і slardiere покрив це.

Ви можете встановити effective_io_concurrency = 5або щось відобразити той факт, що SSD можуть робити швидкі, сильно конвеєрні випадкові зчитування ..., але це впливає лише на сканування індексованих растрових карт, і на практиці це random_page_costвже включає.

Для завантаження лише для читання це не суттєво відрізняється.

Початкове завантаження даних див.

Зауважте, що у мене гарна робоча станція з i7 та 32Gb оперативної пам’яті, тому, можливо, ви можете також порадити там.

Встановіть велике maintenance_work_memдля завантаження даних. Я б принаймні користувався 8GB.

Встановіть велику кількість work_memдля запиту. Відповідний розмір трохи залежить від складності запиту. Почніть з 500MBі підйміть звідти.

Збільшити checkpoint_segments(масово) за початкове завантаження даних.

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


22

Щодо SSD-дисків, головна порада - опустити '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.