Основні переваги PostgreSQL:
- підтримка БД практично необмеженого розміру;
- потужні і надійні механізми транзакцій і реплікації;
- розширювана система вбудованих мов програмування;
- масштабованість.
Виконаємо установку з системи портів:
# Cd / usr / ports / databases / postgresql92-server make install clean rehash
Опції збірки все залишив за замовчуванням.
По завершенню установки, порт вивів короткі рекомендації щодо подальшої налаштування:
Оскільки PostgreSQL використовує кодування UTF-8 за замовчуванням, для уникнення проблем у подальшому, підемо раді і для користувача pgsql (в нових версіях PostgreSQL працює від імені користувача pgsql. А не postgres) трохи підкоригуємо локаль. Для цього в внесемо такий блок в файл /etc/login.conf:
pgsql: \
: Lang = en_US.UTF-8: \
: Setenv = LC_COLLATE = C: \
: Tc = default:
# Sh /usr/local/etc/rc.d/postgresql status
pg_ctl: server is running (PID: 30752)
/ Usr / local / bin / postgres "-D" "/ var / db / pgsql"
Що ж, PostgreSQL сервер запущений і працює. Однак, в настройках за умовчанням сервер налаштований так, що до нього можна підключитися з локального хоста без пароля. Це явна дірка в безпеці, тому спробуємо виправити ситуацію.
Сервер PosgreSQL надає два варіанти управління користувачами і базами даних:
Скористаємося інтерактивним терміналом для настройки прав доступу. Підключимося від імені користувача pgsql. Пароль не потрібен.
# Psql -U pgsql template1
psql (9.2beta4)
Введіть "help", щоб отримати довідку.
Наберемо команду help і ознайомимося з довідкою:
Раджу ознайомитися з довідкою по операторам SQL і командам psql. Тепер створимо тестового користувача і базу даних, до якої він матиме доступ.
template1 = # CREATE USER username;
CREATE ROLE
Перевіримо список ролей:
Підвищимо створеному користувачеві права доступу:
template1 = # ALTER USER username superuser createrole createdb;
ALTER ROLE
Повторно перевіримо список ролей:
Звичайному користувачеві такі права ні до чого, їх варто видавати тільки адміністратору системи. Скасуємо певні права доступу:
template1 = # ALTER USER username nosuperuser nocreaterole nocreatedb;
ALTER ROLE
А ось паролі для користувача - річ обов'язкова. Задамо пароль для створеного користувача:
template1 = # \ password username
Введіть новий пароль:
Повторіть його:
При введенні пароль не відображається! Також варто встановити пароль для користувача pgsql. Після цього включаємо перевірку пароля при підключенні до PostgreSQL сервер. Неоходімо внести зміни в файл /var/db/pgsql/pg_hba.conf. Метод підключення trust необхідно змінити на md5 (також повністю видаляємо рядок для IPv6). В результаті маємо такий результат:
Для того, щоб зміни вступили в силу, необхідно перезапустити PostgreSQL сервер:
В принципі, все інтуїтивно зрозуміло. Використовуйте в своїй роботі документацію і підказки, і робота з сервером PostgreSQL не повинна викликати великих проблем.
Останній штрих - тюнінг PostgreSQL-сервера. Всі основні настройки зберігаються в файлі /var/db/pgsql/postgresql.conf. Відзначимо опції, на які варто звернути увагу (переклад опису опцій узятий тут):
- max_connections - максимальна кількість одночасних підключень до сервера БД. Використовуйте цей параметр, щоб не допустити запуску великої кількості процесів сервера. Інакше є ймовірність, що серер БД вичерпає весь обсяг ОЗУ і буде активно використовуватися підкачка, що в свою чергу спричинить за собою падіння продуктивності.
- shared_buffers - обсяг пам'яті, що, використовуваний сервером БД. За замовчуванням - 32 Мб, але може бути менше, якщо налаштування вашого ядра не дозволяють виділити такий обсяг пам'яті, визначається при ініціалізації кластера БД утилітою initdb. Великі значення цього параметра позитивно позначаються на продуктивності сервера БД.
Якщо у вас виділений комп'ютер з ОЗУ 1 Гб і більше під сервер БД, то хорошим значенням цієї змінної буде 25% від обсягу пам'яті. При великому навантаженні навіть великі значення цього параметра можуть бути ефективними, але так як PostgreSQL покладається на кеш ОС, то виділення більше 40% від обсягу пам'яті навряд чи має сенс. Для великих значень цього параметра потрібно також збільшити значення параметра checkpoint_segments.
На системах з ОЗУ менше 1 Гб правильніше буде використовувати менший обсяг пам'яті (чим 25%), щоб не вичерпати весь обсяг оперативної пам'яті. На винде великі значення цього параметра можуть виявитися ефективними. Ви можете добитися більшої продуктивності зберігаючи це значення маленьким і більше використовуючи засоби кешування ОС. Хорошим діапазоном значень для Windows є 64-512 Мб. - temp_buffers - максимальний розмір тимчасових буферів для кожної сесії. Ця пам'ять використовується тільки локально в сесії для тимчасових таблиць. За замовчуванням - 8 МБ. Значення може бути змінено під час сесії, але тільки до першого використання цієї пам'яті.
- max_prepared_transactions - максимальна кількість "prepared" транзакцій (дивіться опис SQL команди PREPARE TRANSACTION в документації). Щоб відключити цю фішку, поставте значення в 0.
- work_mem - визначає обсяг пам'яті, який буде використовуватися внутрішніми операціями сортування та хеш-таблицями перш, ніж перейти на тимчасові дискові файли. Врахуйте, що для складних запитів кілька внутрішніх операцій сортування і робота з хеш-таблицями можуть працювати паралельно (одночасно). Крім того, кілька сесій можуть робити такі операції одночасно. У підсумку необхідний обсяг пам'яті для цих операцій може в кілька разів перевищувати значення параметра work_mem. Врахуйте це при виборі значення для цього параметра. Під внутрішніми операціями сортування мається на увазі - ORDER BY, DISTINCT і злиття.
- maintenance_work_mem - максимальний обсяг пам'яті, який використовується для внутрішніх операцій, таких як VACUUM, CREATE INDEX і ALTER TABLE ADD FOREIGN KEY. За замовчуванням - 16 Мб. Ці команди виконуються тільки під під час сесії, так що можна вибирати великі значення для цього параметра, ніж для параметра work_mem. Великі значення можуть позитивно позначитися на продуктивності vacuuming і швидкості відновлення БД з дампа. Тільки врахуйте, що процес autovacuum запускається autovacuum_max_workers раз, тому може знадобитися більше вільної пам'яті.
- max_stack_depth - максимальна глибина стека. Хорошим значенням цього параметра є максимально дозволена глибина стека в системі.
- max_fsm_pages - за допомогою цього параметра можна управляти картою вільного простору. Коли щось віддаляється з таблиці, то місце займане цим щось не звільняється на диску, замість цього займане місце просто позначається як "вільно" в карті вільного простору. Потім це місце використовується для нових записів. Якщо на вашому сервері дуже багато видаляється / додається даних з / в таблиці, то великі значення цього параметра можуть позитивно позначитися на продуктивності.