Пол Букхейт: Секрет полегшення роботи: уникайте важких проблем

Це може здатися очевидним, але, на мій досвід, більшість інженерів вважають за краще зосередитися на важких проблемах. Робота над важкими проблемами вражає інших інженерів, але це не найкращий спосіб створення успішних продуктів. Насправді, це одна з кількох причин, чому YouTube переміг Google Video: Google витратив багато часу на вирішення технічно складних проблем, у той час як YouTube створив продукт, яким люди дійсно користувалися (використовуючи PHP та MySQL, що, я думаю, зовсім не вражає технічно).

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

Я згадав про це, відповідаючи на коментарі на news.yc у відповідь на мій пост про диски та бази даних. Щоразу, коли хтось згадує про можливість не використовувати звичайну базу даних, багато людей відразу ж відповідають, що бази даних вирішують безліч дуже складних проблем, і що не варто докладати багато зусиль, щоб винаходити колесо. Ці люди, звичайно, мають рацію.

Але річ у тому, що багато цих складних проблем неактуальні для 99% продуктів. Наприклад, "справжні" бази даних можуть обробляти транзакції, які надто великі, щоб поміститися у пам'яті. Можливо, 1980 року це було справді важливою особливістю. Сьогодні ви можете купити комп'ютер із 32 ГБ пам'яті приблизно за $5000. Як ви вважаєте, скільки транзакцій обсягом у ГБ виконує Twitter? Моє припущення – нуль. Я підозрюю, що середній розмір транзакції ближчий до 0,0000002 ГБ (повідомлення обмежено 140 символами).

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

1. Зрозуміти проблему
2. Усунути проблему

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

Хочете приклад «‎простого, але менш надійного»? Ось один з них (в один або два простих кроки):

1. Всі оновлення надходять до Memcached, але не до бази даних.
2. (опціонально) Фоновий процес періодично копіює записи з memcached до бази даних. Без цього значення будуть повністю втрачені при перезапуску Memcached.