Выбор БД в новом проекте
Disclaimer: В статье сделан контекст на выборе БД, и хотя контекст можно расширить до выбора языка, фреймворка и тп, предлагаю сконцентрироваться только на одном аспекте.
При разработке приложения, сервиса, системы и тп возникает один из главных вопросов: как мне хранить данные (какую БД выбрать). В связи с тем, что чаще всего в получите ответ «зависит» (it depends), предлагаю рассмотреть несколько стратегий, которые будут работать почти всегда.
Выбирайте знакомую технологию
При разработке стоит исходить из того, с чем умеет (и умеет хорошо) работать ваша команда, компания, вы сами. Частенько нам хочется опробовать новую технологию. Как известно, лучшее место и время для этого — новый проект. Поэтому напишите pet-проект и проверьте ее там. Если речь идет про коммерческую разработку, то знания технологии ускорит вас и поможет не нарваться на подводные камни.
Исходите из стандартов компании
В крупных компаниях часто (почти всегда) есть определенный скоуп технологий, «поддерживаемых» компанией. В небольших компания такие стандарты могут быть описаны не явно. Выглядят они как «все наши сервисы используют MySQL».
С одной стороны, это может ограничивать вас. С другой, в компании уже набрался пул «экспертов» по этой технологии. «Эксперты» могут помочь, как консультациями, так и предоставлением шаблонов для решения типовых проблем. Очень часто мы не решаете какую-то принципиально новую проблему, а просто адаптируете ее под предметную область.
Всегда ли это работает?
Я считаю, что да. На начальной стадии дизайна надо исходить из текущих условий. Иначе это будет выглядеть как: у нас все Java разработчики, но новый сервис мы будем писать на Erlang.
Но я в облаке!
А будет ли это работать, если использовать AWS, Azure, GCP и тп с модными DBaaS? Да, будет. DBaaS решает проблемы развертывания БД и в какой-то степени решает проблему поддержки. Но проблемы работы с конкретной технологий остаются. К тому же, DBaaS обычно более ограничен в плане гибкости конфигураций.
Но мне точно не подойдет стандартное решение!
Такое и правда может быть. Но лучший вариант, это проверить вашу гипотезу. Реализация двух Proof of Concept со стандартной БД и с узкоспециализированной под ваши задачи. Во-первых, необходимо понять, насколько ваше решение лучше стандартного. Во-вторых, цифры помогут вам аргументировать вашу позицию. И не стоит забывать, что в этом случае необходимо решать вопросы эксплуатации и поддержки новой БД.
Вывод
Исходите из экспертизы
Исходите из общих практик (команды/компании)
Стандартные решения не всегда работают, но это несет новые проблемы
Гибкость и открытость к новым подходам также важны, даже при выборе проверенных и знакомых решений
P.S.: После обсуждений этого поста телеграм канале считаю нужным оставить небольшое дополнение.
Наиболее полный алгоритм выбора такой:
Понять модель данных
Подсчитать объем данных
Понять паттерны доступа к данным (чтения and записи)
Изучить предложения
Сравнить ваши потребности с возможностями Баз Данных
Проверить наличие экспертизы
Выбрать потенциальных кандидатов и провести сравнительный анализ
Оставить простор для будущих миграций
Проведите нагрузочное тестирование
Закрепите выбор
Однако, я бы прибегал к нему только в случае, если стандартное решение для вас точно работать не будет. А стратегией «по умолчанию» стоит использовать подход, описанный в данной статье.
