Створіть найшвидший у світі аналіз веб-сайтів (2021)

Понад рік ми намагалися встигати за зростанням наших аналітичних даних. Fathom зростав зі швидкістю світла, дедалі більше людей відмовлялися від Google Analytics, а кількість наших даних стрімко зростала.

У березні 2021 року ми перемістили всі наші аналітичні дані в нашу омріяну базу даних.

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

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

Історія нашої бази даних Випуск 1

Коли ми вперше створили Fathom на Laravel, ми вирішили використовувати Heroku. Я вже говорив про це докладно, тому не буду вдаватися в подробиці, але я вирішив, що база даних Postgres буде найкращим вибором, оскільки Heroku пропонує її як службу, яку вони керують . Це була не просто додаткова послуга; це був той, який вони погодилися надати «офіційно». Оглядаючись назад, це було помилкою, оскільки я не мав досвіду роботи з Postgres.

Версія 2

Для версії 2 ми повністю перебудували Fathom Analytics і перейшли на Laravel Vapor. Ми зберегли подібну структуру бази даних, але перейшли до керованої MySQL. Перевагою було те, що я повернувся у свою зону комфорту (де я мав досвід), але недоліком було те, що ми нічого не зробили для покращення структури нашої бази даних. Справи пішли швидше? звичайно Ми збільшили ЦП і оперативну пам’ять, і запити працювали краще, але це не було стійким рішенням для нашої інформаційної панелі чи гаманця.

Проблеми з MySQL

Перед тим, як перелічувати причини відмови від MySQL, я хочу чітко й голосно заявити, що я знаю, що MySQL не був розроблений для такого великомасштабного аналітичного використання. З’ясувавши це, ось основні причини, чому нам довелося відмовитися від RDS для MySQL:

Низька продуктивність

Хоча ми зберігали лише підсумкові таблиці (дані згорталися по годинах), нашій базі даних було важко виконувати SUM і GROUP BY. А з даними високої потужності було ще гірше. Прикладом був клієнт, який мав 11 000 000 унікальних переглядів сторінок за один день. MySQL займе, можливо, 7 хвилин, щоб обробити для них запит SUM/GROUP, а наші запити на інформаційній панелі минуть. Щоб обійти це обмеження, мені довелося створити спеціальне завдання cron, яке попередньо обчислювало дані панелі інструментів.

Нам потрібно було більше гнучкості

Для версії 3 ми доклали всіх зусиль, щоб дозволити вам докладніше та фільтрувати дані, що означає, що ми зберігаємо 1 рядок для кожного перегляду сторінки. Якщо MySQL не може обробляти агрегації зведених таблиць середнього масштабу, як він впорається з цим новим підходом, коли ми маємо сотні мільйонів рядків для одного веб-сайту?

IOPS

З RDS нам довелося подумати про IOPS. Після напруженого досвіду роботи з вірусним веб-сайтом ми почали надлишково використовувати IOPS для RDS. І це дорого. Якщо ви не знайомі з IOPS, найпростішим способом пояснити це є те, що вам потрібно надати певний обсяг пам’яті, який супроводжується фіксованою кількістю IOPS, що визначає максимальну кількість читань/записів у вашій базі даних за секунду. І якщо ви отримуєте сайт, який стає вірусним, і ви не маєте належного IOPS, щоб впоратися з цим, ласкаво просимо до міста застарілих, заповнюйте.

Щоб забезпечити обробку потоків трафіку, ми заплатили за 2000 ГБ пам’яті бази даних. Це дало нам 6000 IOPS, що нас влаштувало. Тож ми платили додаткові 500 доларів на місяць за непотрібне нам сховище, на той випадок, якщо у нас буде ще один вірусний сайт. І на момент написання статті ми все ще платимо за це, оскільки AWS не дозволяє вам легко зменшити обсяг пам’яті. (Так, мені це погано.)

Ліміт підключення

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

Наші пошуки нового друга

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

це повинно бути смішно швидко Воно повинно рости разом з нами. Ми не...