Вступ
Ми — компанія, що надає програмні послуги, і тому займаємось підтримкою Django-додатків для клієнтів, які не мають власної команди для цього завдання. Деякі з додатків, якими ми керуємо, досить старі, і через це вони побудовані за стандартами та конвенціями, які зараз уже не є актуальними.
Одна з таких конвенцій у світі відкритого коду полягала в використанні MySQL як бази даних. Тому не рідкість побачити старі додатки, які використовують цю базу даних, і насправді деякі з наших власних додатків, написаних нами колись, також використовують MySQL.
Чому варто розглядати перехід?
Як компанія, що надає програмні послуги, ми відіграємо важливу роль у автоматизації робочих процесів наших клієнтів, підтримуючи та покращуючи їхні основні додатки. Тому не дивно, що ми втручаємось, коли вважаємо, що настав час для змін.
Розглянемо на прикладі одного з наших клієнтів. Їхній Django-додаток вже більше десяти років, і, як згадувалося раніше, він був написаний для MySQL. Після продажу MySQL компанії Oracle ми перейшли на MariaDB, як і багато інших компаній, оскільки MySQL більше не є відкритим кодом і переходить на платні послуги для деяких функцій.
Як я вже говорив, ми часто радимо нашим клієнтам щодо покращень їхніх систем. Одним з таких покращень було перенесення їхньої бази даних з локально розміщеної MariaDB на керовану кластерну систему з вузлами на випадок відмови та резервним копіюванням за межами сайту. Одночасно ми запропонували перейти на Postgres.
Існує низка аргументів, чому перехід на Postgres є гарною ідеєю. Я міг би їх перелічити, але це не те, що я хочу обговорювати. Справа насправді у швидкості.
Підтверджено цифрами
Як ми часто робимо при підготовці пропозицій, ми створюємо доказ концепції. Ми робимо це, бо хочемо зрозуміти, що зміна призведе до конкретної ситуації. І так, ми це зробили, і одразу помітили, що швидкість виконання запитів значно покращилась на Postgres.
Коли я кажу "помітили", я маю на увазі, що, як кінцеві користувачі, деякі операції стали швидшими. Ми відчули, що досвід користувача покращився. Але це було відчуття, а, як відомо, відчуття не завжди добре продаються.
Щоб краще переконати нашого клієнта (і себе), ми вирішили налаштувати систему для створення статистики. Після того, як ми скопіювали дані з MySQL/MariaDB в Postgres (це тема для іншої статті), ми створили команду управління, яка запитує обидві бази даних з точно однаковим набором даних і вимірює результати.
Налаштування
В іншому доказі концепції ми створили функцію, яка в рамках Django називається командою управління. Команда управління генерує дані та графіки на веб-сторінці — веб-сторінка, бо ми хочемо щось презентувати IT-менеджеру нашого клієнта.
Дані надають нам середній час, який займає запит на кількох циклах, а графік показує, що робить кожен запит, і ми можемо швидко побачити аномалії.
І, звісно, команда управління робить цей тест повторюваним, що дуже важливо для нашої аргументації.
Команда управління налаштована наступним чином:
- Модель бази даних для запиту
- Операція для тестування: читання, запис, пошук
- Кількість циклів
- Інтервал часу між запитами
Нижче наведено приклад конфігурації тесту (деякі елементи анонімізовані)
DBTIMER_ARGS = {
"dbs": ["default", "newcomer"],
"operations": ["read", "write", "search"],
"models": [
{"name": "*****", "conf": ("*****", "******"), "attr": "*****", "search": {"customer__name": "Someone"}},
{"name": "*****", "conf": ("*****", "*****"), "attr": "name", "search": {"name": "something"}},
{"name": "customer", "conf": ("clients", "customer"), "attr": "last_name", "search": {"name": "something"}},
],
"cycles": 100,
"sleep": 0.01,
}
Результати
Результати — це результат кількох запусків.
Деталі кожного запуску розділені на наступні пункти:
- Виведення: виведення команди, з наступними даними:
- Назва бази даних
- Середня швидкість запитів за кількість циклів з заданим інтервалом
- Виключення: список виключень, які сталися під час виконання запитів, для кожної бази даних
- Ідентифікатори: список всіх ідентифікаторів об'єктів, що були оброблені
Приклад результату
Зазвичай веб-сторінка, яка містить результати, занадто довга, щоб її можна було адекватно показати, і, звісно, я не хочу показувати конкретні дані про клієнта в публічній статті. Але давайте поглянемо (це справжній wow-ефект).
Висновок
Хоча більшість порівнянь не дають такого значного відмінності, як у наведеному вище прикладі (більшість знаходяться в межах одиничних або подвійних цифр, і іноді MariaDB виграє, хоча й з мінімальною перевагою), я вважаю, що це справді закриває дискусію. І, як не дивно, працівники нашої прикладної компанії скаржилися на повільний час відповіді під час пошуку.
Тож, повертаючись до назви цієї статті, хоча ми, як компанія, що надає програмні послуги, не можемо зробити когось по-справжньому щасливим, ми можемо зробити свій внесок у переконання нашого клієнта перейти на Postgres, щоб хоча б повільні часи відповіді під час пошуку не додавали їм зайвих турбот.
PS: Команду управління, яку ми створили, називається DBTimer і незабаром буде доступна як пакет. Коментуйте, якщо зацікавлені!
Перекладено з: Moving From MariaDB To PostgreSQL Will Make Employees Happier But How To Prove It?