Початковий розмір бази даних PostgreSQL

До мого питання є 2 частини.

1. Чи є спосіб вказати початковий розмір бази даних в PostgreSQL?
2. Якщо цього немає, як боротися з фрагментацією, коли база даних зростає з часом?

Нещодавно я перейшов з MSSQL на Postgres, і однією з речей, які ми робили у світі MSSQL при створенні бази даних, було вказати початковий розмір бази даних та журналу транзакцій. Це зменшило фрагментацію та підвищило продуктивність, особливо якщо заздалегідь відомий "нормальний" розмір бази даних.

У міру збільшення розміру продуктивність моєї бази даних падає. Наприклад, робоче навантаження, яке я переношу, зазвичай займає 10 хвилин. Зі збільшенням бази даних цей час збільшується. Здійснення VACUUM, VACUUM FULL та VACUUM FULL ANALYZE не вирішує проблему. Що вирішує проблему продуктивності - це зупинка бази даних, дефрагментація диска, а потім виконання ВАКУУМОВОГО АНАЛІЗУ приводить показники мого тесту до початкових 10 хвилин. Це змушує мене підозрювати, що фрагментація - це те, що заподіює мені біль.

Я не зміг знайти жодної посилання на резервування простору таблиць / простору бази даних у Postgres. Або я використовую неправильну термінологію і, таким чином, нічого не знаходжу, або є інший спосіб пом'якшення фрагментації файлової системи в Postgres.

Якісь покажчики?

Рішення

Надані відповіді допомогли підтвердити те, про що я почав підозрювати. PostgreSQL зберігає базу даних у декількох файлах, і саме це дозволяє базі даних рости, не турбуючись про фрагментацію. Поведінка за замовчуванням полягає в тому, щоб упакувати ці файли до крайок з даними таблиці, що добре для таблиць, які рідко змінюються, але погано для таблиць, які часто оновлюються.

PostgreSQL використовує MVCC для забезпечення одночасного доступу до даних таблиці. Відповідно до цієї схеми, кожне оновлення створює нову версію рядка, який був оновлений (це може бути через штамп часу або номер версії, хто знає?). Старі дані не відразу видаляються, але позначаються для видалення. Фактичне видалення відбувається при виконанні операції VACUUM.

Як це стосується коефіцієнта заповнення? Коефіцієнт заповнення таблиці за замовчуванням 100 повністю упаковує сторінки таблиці, що, в свою чергу, означає, що на сторінці таблиці немає місця для розміщення оновлених рядків, тобто оновлені рядки будуть розміщені на іншій сторінці таблиці від початкового рядка. Це погано для продуктивності, як показує мій досвід. Оскільки мої зведені таблиці оновлюються дуже часто (до 1500 рядків / сек), я вирішив встановити коефіцієнт заповнення 20, тобто 20% таблиці буде для вставлених даних рядків і 80% для даних оновлення. Хоча це може здатися надмірним, велика кількість місця, відведеного для оновлених рядків, означає, що оновлені рядки залишаються на тій самій сторінці, що і оригінал, і там сторінка таблиці не заповнена до моменту запуску демона автовакууму для видалення застарілих рядків.

Щоб "виправити" мою базу даних, я зробив наступне.

1. Встановіть коефіцієнт заповнення моїх підсумкових таблиць на 20. Ви можете це зробити під час створення, передавши параметр CREATE TABLE або після факту через ALTER TABLE. Я видав таку команду plpgsql:ALTER TABLE "my_summary_table" SET (fillfactor = 20);
2. Випустив VACUUM FULL, оскільки він пише абсолютно нову версію файлу таблиці і, таким чином, за наслідками записує новий файл таблиці з новим коефіцієнтом заповнення .

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

TL; DR - Фрагментація файлів не була причиною, це фрагментація простору таблиці. Це пом'якшується шляхом підстроювання коефіцієнта заповнення таблиці відповідно до конкретного випадку використання.

1. Не єдине, що є близьким до цього, коли ви компілюєте сервер за допомогою перемикача --with-segsize, це може допомогти, якщо ваша таблиця займає більше місця, ніж концерт, і ваша файлова система може обробляти один файл, перебуваючи на концерті. Якщо ви вставляєте 20 концертів, вам потрібно буде створити 20 файлів, якщо ви не використовуєте цей перемикач. Якщо ваша файлова система може обробляти файл через концерт, ви можете просто встановити його на велике значення, швидше за все, побачити якусь вигоду, в гіршому випадку - невелику вигоду.

2. Погляньте на CLUSTER http://www.postgresql.org/docs/9.1/static/sql-cluster.html та FILLFACTOR http://www.postgresql.org/docs/9.1/static/sql-createtable.html , http://www.postgresql.org/docs/9.1/static/sql-createindex.html

Зауважте, що FILLFACTOR можна застосувати як до таблиць, так і до індексів.

У грі є ще одна річ, яка ще не ввійшла до ваших рівнянь: ГОРЯЧЕ оновлення . Відповідні відповіді:

• PostgreSQL незрозумілий розмах таблиці
• Чи рекомендується регулярний аналіз ВАКУУМУ відповідно до пункту 9.1?
• Яке значення n_live_tup та n_dead_tup в pg_stat_user_tables
• Як прискорити повільний запит ОНОВЛЕННЯ

Установка FILLFACTORнастільки ж низько , як 20 це , здається надмірним. Він роздуває стіл до п'яти разів перевищує його розмір. Якщо оновлення HOT працюють, вам не доведеться йти так низько - як правило .

Є винятки: оновлення HOT можуть використовувати повторно лише мертві кортежі з попередніх транзакцій , а не з тих самих чи одночасних . Тому велике одночасне навантаження або довгі транзакції, неодноразово оновлюючи одні й ті ж рядки, можуть гарантувати таке низьке (або навіть нижче) значення.

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

Зауважте, що оновлення HOT працюють лише тоді, коли змінені стовпці жодним чином не задіяні в індексах (ні як дані, ні як умова в частковому індексі). Можливо, ви блокуєте гарячі оновлення з індексами в оновлених стовпцях. Якщо вони витратні, ви можете покращити загальну продуктивність без них.

Нарешті, ви можете встановити параметри автовакууму на кожну таблицю . Ви можете орієнтуватися на сильно оновлені таблиці з агресивними налаштуваннями, що дозволяє дещо жорсткіше упакувати рядки, ніж тільки FILLFACTOR 20.

Якщо ваша проблема - фрагментація файлів, то ні, немає. У Postgres кожна таблиця отримує власний файл або набір файлів, якщо він використовує TOAST, у файловій системі. Це відрізняється від, скажімо, Oracle (або, мабуть, MS-SQL), коли ви створюєте файли просторового табличного простору для передачі ваших таблиць - хоча там навіть у вас можуть виникнути проблеми з фрагментацією файлової системи, якщо файли просторової таблиці будуть розширені або файлова система є погано фрагментарно для початку.

Що стосується вашого другого питання ... я не маю уявлення, як би чітко боротися з фрагментацією файлової системи, оскільки MS-Windows є єдиною ОС, у якій виникли проблеми з фрагментацією, і я не запускаю MS-Windows більше ніж абсолютно потрібно бути в ці дні. Можливо, розміщення файлів баз даних на власних дисках може певною мірою пом'якшити це.