Какие факторы влияют на то «тянет» простая БД аналитику или уже нет

Первое, число пользователей. 6 аналитиков создают нагрузку х2 по сравнению с 3. Каждый новый аналитик привносит с собой датасеты и процессы, которые надо обслуживать в смысле ETL, Data Quality.

Во-вторых, объем данных. Даже если набор датасетов фиксированный, то каждый день подливаются новые данные. Отдельный фактор – история изменений в SCD1,2. Больше данных процессим – больше читаем с диска и больше расходуем ресурсов сервера.

В-третьих, сложность производимых с данными манипуляций. Новые датасеты это новый ETL, новые проверки качества данных. Новые джойны старых данных с новыми. В старых датасетах собираются «низковисяцие фрукты», усложняются вопросы, задаваемые бизнесом. Это сразу же тянет замысловатые и «перекрученные» запросы от аналитиков. А вот те пользователи, которые приходили по промо акции, но не купили – с какой вероятностью они купят потом, когда скидки кончатся?

Допустим в точке старта мини-КХД у нас:
– 3 аналитика
– 500 ТБ данных
– Фактор сложности 1

После первого роста команды – точка 2:
– 6 аналитиков (фактор х2)
– 2 ТБ данных (фактор х4)
– Фактор сложности 2 (х2)
Итого рост нагрузки х16 (!)

В точке 3:
– 20 аналитиков (х3.33)
– 5 ТБ данных (х2.5)
– Фактор сложности 3 (х1,5)
Итого рост нагрузки x12.5 (!) от прежней

Каждый раз мы растем на порядок! Причем эти точки роста случаются быстрее, чем мы предполагаем.

И самое плохое в этой истории, что мы внезапно понимаем, что наша инсталляция больше не тянет. Случается это в период высокой нагрузки – а когда же еще? И в момент когда нам надо заниматься содержательной работой (высокий сезон, закрытие квартала и тд) мы вынуждены решать проблему низкой производительности или переезда на «настоящую» аналитическую БД с колоночным хранением и MPP архитектурой.
Поэтому надо все же подумать, куда мы хотим, можем, рискуем вырасти. И учитывать рост не только в данных, но и в других факторах. В нашем примере при росте данных в 10 раз мы выросли по нагрузке аж в 200.