Чтобы что-то исправить, нужно сначала понять, что это "что-то" работает не так, как ожидается или требуется. И если требования могут быть зафиксированы на уровне договора между поставщиком и потребителем, то "ожидания" отличаются у разных людей:
- Кому-то достаточно, чтобы не было ошибок, а то что грузится по 10 секунд — не проблема
- Кому-то нужно, чтобы работало быстро (= с той скоростью, чтобы не возникало ощущения тормозов)
- Кому-то не важна скорость и ошибки, главное чтобы не мешало зарабатывать
Поэтому нужно договориться об ожиданиях и зафиксировать их. А в этой статье расскажем, как находить проблемы технического характера. В следующей исправим то, что найдем в этой.
1. Профиль использования БД
- Функциональные требования — это что должно уметь решение (какие функции)
- Нефункциональные — как это эти функции будут работать (с какими характеристиками эти функции будут работать)
И если первые часто жестко фиксируются в техническом задании, то вторые часто остаются на откуп исполнителя и его насмотренность: скорость работы, количество ошибок и прочее. И уже исполнитель "сам" решает, насколько нужно делать систему гибкой, масштабируемой и "нормальной".
Для баз данных это "нормально" может базироваться на переменных:
- Объем данных: сколько записей будет в таблицах через 6 месяцев, 1 год, 3 года
- Профиль работы: соотношение операций чтения/записи (read/write ratio)
- Пиковые нагрузки: максимальное количество одновременных пользователей
- Временные паттерны: когда происходят пиковые нагрузки (утро, вечер, конец месяца)
Часто решение проектируется под 1M пользователей, хотя в нише компании не больше 1000 пользователей
На наш взгляд, объем — это основа. Взяв калькулятор, можно за минуты оценить объем хранения и обработки. Например, на небольшом складе скорее не больше 10к-100к элементов инвентаризации, чем миллионы или даже сотни миллионов. И "случайно" вместо 10к элементов за одну ночь не станет 100к. А значит, нет необходимости вкладывать 80% усилий именно в этот кейс.
Пример переменных для e-commerce проекта (магазин):
- Текущий объем: 100,000 заказов
- Рост: +15% в месяц
- Через год: ~500,000 заказов
- Пиковая нагрузка: 1000 заказов/час в праздники, а также в черную пятницу
- Read/Write ratio: 95/5 (больше чтения)
Иными словами, меньше 1 заказа в секунду, меньше миллиона новых записей в год. Любая современная БД спокойно работает с миллионами записей в таблице. Поэтому достаточно сделать первичную настройку БД, а вот разрабатывать "масштабирование" в первый год-два даже не потребуется.