Postgres прискорили у 300 разів завдяки SIMD і batching

Розробники прискорили аналітичні запити в PostgreSQL до 300 разів, не переписуючи базу і не мігруючи на спеціалізовані сховища. Секрет — три техніки обробки даних, які давно живуть у світі аналітичних систем, але тепер їх можна прикрутити до звичайного Postgres, який уже стоїть у половини українських компаній.

Це важливо тому, що аналітичний запит — «скільки трафіку прийшло з кожного джерела за квартал», «сума платежів по регіонах» — Postgres обробляє повільно за замовчуванням. Не тому що погана база, а тому що її двигун спроєктований для іншого: додати замовлення, знайти клієнта, оновити один рядок. Коли ж потрібно перемолоти мільйони рядків заради однієї цифри, класична механіка починає задихатися.

Чому один рядок — це повільно

Стандартний Postgres обробляє запит по рядку за раз. Для кожного рядка він викликає ланцюжок функцій: прочитати значення, порівняти, додати до суми, перейти далі. Уяви касира, який пробиває кожен товар окремо: сканує, кладе, тягнеться за наступним, знову сканує. Рухів багато, а корисної роботи — крапля.

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

Operator fusion прибирає зайві зупинки між операціями. Замість «порахуй всі суми, склади результат у пам'ять, потім прочитай його назад і відфільтруй» двигун зливає ці кроки в один прохід. Дані не гуляють туди-сюди через пам'ять — їх обробляють на місці.

SIMD: одна команда на вісім чисел

Найцікавіше — SIMD, Single Instruction Multiple Data. Сучасний процесор уміє додавати не два числа за раз, а вісім чи шістнадцять однією командою. Ця здатність є в кожному сервері вже років п'ятнадцять, але звичайний Postgres нею майже не користується, бо обробка по рядку не дає процесору того рівного потоку однакових чисел, який потрібен для такого фокусу.

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

Що з цього українському бізнесу

Головне: тут немає слова «замініть». Редакція, яка тримає статистику переглядів у Postgres, фінансовий відділ із квартальними звітами, інтернет-магазин із аналітикою продажів — усі вони вже сидять на базі, яку ці техніки прискорюють. Не треба купувати ліцензію на дороге аналітичне сховище, наймати команду під міграцію і місяцями переносити дані, ризикуючи їх втратити.

Практично це означає розширення до наявного Postgres або нову версію двигуна, а не паралельну систему. Дашборд, який будувався півхвилини і тому нікому не був потрібен, починає відповідати миттєво — і люди справді ним користуються. Різниця між «звіт за ніч» і «звіт за секунду» — це різниця між рішенням раз на квартал і рішенням щодня.

Для невеликих команд, де немає бюджету на окрему аналітичну інфраструктуру, це найдешевший спосіб дістати з даних те, що там уже лежить. База стара, залізо те саме, дані ті самі. Змінюється лише те, наскільки розумно двигун вантажить процесор — і виявляється, що досі він вантажив його ліниво.