У мене сильно оновлена / доступна таблиця, де я зберігаю серіалізовані об’єкти Java. Вони знаходяться в таблиці 2-3 години (також оновлюються протягом цього періоду), а потім видаляються. Розмір столу - близько 300 Мб. Я помітив, що це дуже, дуже часто VACUUMed і задаюся питанням, чи fillfactorдопоможе змінити ?
Відповіді:
Ключові слова тут:
Точка 1. вказує на нижчий коефіцієнт заповнення, а 2. - навпаки. Це сприяє продуктивності, якщо на одній сторінці даних зберігаються кілька рядкових версій. ГОРЯЧІ оновлення досягнуть цього. Прочитайте тут чи тут . На сторінці даних їм потрібна кімната, що перемикається - як мертві кортежі або простір, відведений на fillfactor<100. Але вони можуть робити свою справу лише в тому випадку, якщо жоден з індексів не містить жодного оновленого стовпця , що має відповідати вашому випадку.
Іншим важливим фактором тут буде розмір кортежу (порівняно з розміром вашої сторінки (найчастіше це 8 кбіт).
Якщо розмір кортежу становить 4 кб або більше, зменшення коефіцієнта заповнення буде марним, оскільки на сторінці даних ніколи не може бути більше ніж один кортеж. Ви також можете залишити його на 100(що все одно є за замовчуванням). Однак деякі типи даних "підсмажуються" та зберігаються поза межами рядка, якщо вони перевищують обмеження розміру, тому кортежі, що вимагають, що багато в основному вилку відношення, рідкісні.
Що б ви ні робили, VACUUM буде виконуватися часто. І це взагалі гарна річ, я б не переймався цим. Ви створюєте багато мертвих кортежів. VACUUMідентифікує мертві рядки, які вже не бачать жодної відкритої транзакції. Посібник:
Стандартна форма
VACUUMвидаляє версії мертвих рядків у таблицях та індексах і позначає простір, доступний для подальшого повторного використання .
Сміливий акцент мій.
Ви можете грати з налаштуваннями для кожного столу для автовакууму, щоб запустити його менше (або більше) часто лише для цієї таблиці:
Порогові значення та коефіцієнти шкали за замовчуванням взяті
postgresql.conf, але їх можна переосмислити за таблицею ;
Сміливий акцент мій. Зокрема з autovacuum_vacuum_thresholdіautovacuum_vacuum_scale_factor . Бігати VACUUMбагато може насправді бути хорошою ідеєю, а не дуже низькою fillfacter. Це залежить від моделей доступу. Якщо всі кортежі живуть, скажімо, 3 години, і кожен оновлюється кілька разів, я все одно знижую fillfactorдо приблизно 50. Вам доведеться перевірити і знайти солодке місце.
Все це вбік, оскільки ваші дані здаються непостійними для початку: використовуйте UNLOGGEDтаблицю :
Дані, записані в незаблоковані таблиці, не записуються в журнал попереднього запису (див. Главу 29 ), що робить їх значно швидшими, ніж звичайні таблиці. Однак вони не є безпечними для аварій : незамкнена таблиця автоматично обрізається після аварії або нечистого відключення. Вміст незаблокованої таблиці також не копіюється на сервери очікування.
Сміливий акцент мій. Не використовуйте це, якщо ваш сервер може вийти з ладу, і вам потрібні дані після цього. Але якщо ми говоримо про дані сеансу для веб-додатків, це може бути прийнятною ціною.
Або ще більш радикально: використовуйте сховище ключа-значення, як Redis, якщо ви не можете обійтися без функцій та безпеки, що надаються RDBMS взагалі.
Я б запропонував СУБД з ключовим значенням, але я викидаю це там заради інтересу.
Замість виконання INSERT & DELETE операцій виконайте лише оновлення.
Структура таблиці буде чимось на зразок
ID integer -- sequential ID
Used boolean -- default FALSE
Object -- whatever type is appropriateСтовпець, що тримає об'єкт, буде фіксованої довжини, щоб уникнути розбиття та переміщення рядків. Розміріть цей стовпець, щоб розмістити ваші об'єкти та ефективно заповнити сторінку на диску.
Попередньо заповніть таблицю стільки рядків, скільки вам потрібно, і ще декількома.
Коли слід записати об'єкт, знайдіть рядок з використанням = Недостовірне та ОНОВЛЕННЯ цього рядка. Коли об'єкт повинен бути знищений, встановіть, що він використовується "False". Сміття не створюється, а значить, і не збирається сміття.
Звичайно, існує багато, багато умов для виключень (переповнення рядків, переповнення таблиці, умови перегонів при використанні ідентифікатора тощо), але жодна не є нездоланною.