Disclaimer: В статье сделан контекст на выборе БД, и хотя контекст можно расширить до выбора языка, фреймворка и тп, предлагаю сконцентрироваться только на одном аспекте.
При разработке приложения, сервиса, системы и тп возникает один из главных вопросов: как мне хранить данные (какую БД выбрать). В связи с тем, что чаще всего в получите ответ “зависит” (it depends), предлагаю рассмотреть несколько стратегий, которые будут работать почти всегда.
Выбирайте знакомую технологию
При разработке стоит исходить из того, с чем умеет (и умеет хорошо) работать ваша команда, компания, вы сами. Частенько нам хочется опробовать новую технологию. Как известно, лучшее место и время для этого - новый проект. Поэтому напишите pet-проект и проверьте ее там. Если речь идет про коммерческую разработку, то знания технологии ускорит вас и поможет не нарваться на подводные камни.
Исходите из стандартов компании
В крупных компаниях часто (почти всегда) есть определенный скоуп технологий, “поддерживаемых” компанией. В небольших компания такие стандарты могут быть описаны не явно. Выглядят они как “все наши сервисы используют MySQL”.
С одной стороны, это может ограничивать вас. С другой, в компании уже набрался пул “экспертов” по этой технологии. “Эксперты” могут помочь, как консультациями, так и предоставлением шаблонов для решения типовых проблем. Очень часто мы не решаете какую-то принципиально новую проблему, а просто адаптируете ее под предметную область.
Всегда ли это работает?
Я считаю, что да. На начальной стадии дизайна надо исходить из текущих условий. Иначе это будет выглядеть как: у нас все Java разработчики, но новый сервис мы будем писать на Erlang.
Но я в облаке!
А будет ли это работать, если использовать AWS, Azure, GCP и тп с модными DBaaS? Да, будет. DBaaS решает проблемы развертывания БД и в какой-то степени решает проблему поддержки. Но проблемы работы с конкретной технологий остаются. К тому же, DBaaS обычно более ограничен в плане гибкости конфигураций.
Но мне точно не подойдет стандартное решение!
Такое и правда может быть. Но лучший вариант, это проверить вашу гипотезу. Реализация двух Proof of Concept со стандартной БД и с узкоспециализированной под ваши задачи. Во-первых, необходимо понять, насколько ваше решение лучше стандартного. Во-вторых, цифры помогут вам аргументировать вашу позицию. И не стоит забывать, что в этом случае необходимо решать вопросы эксплуатации и поддержки новой БД.
Вывод
Исходите из экспертизы
Исходите из общих практик (команды/компании)
Стандартные решения не всегда работают, но это несет новые проблемы
Гибкость и открытость к новым подходам также важны, даже при выборе проверенных и знакомых решений
P.S.: После обсуждений этого поста телеграм канале считаю нужным оставить небольшое дополнение.
Наиболее полный алгоритм выбора такой:
Понять модель данных
Подсчитать объем данных
Понять паттерны доступа к данным(чтения and записи)
Изучить предложения
Сравнить ваши потребности с возможностями Баз Данных
Проверить наличие экспертизы
Выбрать потенциальных кандидатов и провести сравнительный анализ
Оставить простор для будущих миграций
Проведите нагрузочное тестирование
Закрепите выбор
Однако, я бы прибегал к нему только в случае, если стандартное решение для вас точно работать не будет. А стратегией "по умолчанию" стоит использовать подход, описанный в данной статье.
Комментарии (12)
tas
05.04.2024 07:311-5 - да, только это обычно делается для привычных БД, по которым экспертиза уже есть.
6 может и не влиять ни на что. Если (к примеру) по требованиям подходит только Ceph, то экспертизу придется нарабатывать.
7 - тут да, вопросов нет. Если проект серьезный, то для всего ПО нужно будет делать обоснование выбора.
gandjustas
05.04.2024 07:31Разве есть сейчас альтернатива postgres для любых транзакционных данных?
vladar107 Автор
05.04.2024 07:31Странно тащить postgres, если в компании везде MySQL.
gandjustas
05.04.2024 07:31Если уже есть какая-то база, то даже не стоит вопрос о выборе. Если конкретной базы нет (а её чаще всего нет), то postgres. MySQL тупо слабее и требует лицензирования для коммерческого использования.
vladar107 Автор
05.04.2024 07:31Речь не про Базу в проекте, а про Базу в компании. Если вся компания сидит на условном MySQL, то зачем тащить Postgres?
На месте MySQL может быть что угодно, это просто пример. Ок, если прям придираться к словам, то MariaDB. Возможно Postgres производительнее, гибче, куча плагинов. Но зачем, если вам это все не надо? Зато надо будет поддерживать Postgres, которого до этого в компании не было?
VanKrock
05.04.2024 07:31И это неплохо, так как когда прибьёт, будут эксперты, которые помогут переехать остальным, миграция с Oracle и MSSQL на PosgreSQL сейчас идёт во многих компаниях. Всё таки аргумернт "у нас везде эта бд" конечно аргумент и весомый, но не единственный. Собственно каждый новый проект - повод задуматься, актуальный ли у вас стек, посмотреть какие ещё варианты и если видите, что технологии и подходы используемые в компании устаревают, то новый проект - хороший вариант, чтобы попробовать что-то новое и в случае чего распространить опыт внутри компании
Batalmv
05.04.2024 07:31Для больших корпоративных и гос. компаний - да. Они часто берут чего подороже либо с спапортом
Я в большим энтерпрайзе вообще не видел, сплошной Oraсle и иногда DB2
Но это было раньше
gandjustas
05.04.2024 07:31В РФ сейчас негде взять "подороже и с саппортом", поэтому Postgres.
Раньше в банках везде был оракл, а кто поменьше - MS SQL, а теперь везде пострегс, или будет постгрес в ближайшее время.
VanKrock
05.04.2024 07:31По своему опыту в большом энтерпрайзе, сейчас либо переезжают с Oracle на PosgreSQL, либо уже переехали. Для аналитики переезжают на ClickHouse
dyadyaSerezha
05.04.2024 07:31+2Попридираюсь к языку, хотя с самим подходом согласен.
В крупных компаниях часто (почти всегда) есть определенный скоуп технологий,
Неправильное использование слова scope. Тогда уж set, но зачем, если можно сказать просто "набор технологий"?
набрался пул “экспертов” по этой технологии. “Эксперты” могут помочь
Почему эксперты в кавычках? Они и не эксперты вовсе, а так себе?
не решаете какую-то принципиально новую проблему, а просто адаптируете ее под предметную область
Автор, вы поняли, что написали? Проблему адаптируете? Проблему чего, какую проблему? Может быть, старое/стандартное решение адаптируете, а не проблему?
Стандартные решения не всегда работают, но это несет новые проблемы
Почему тут "но"? По смыслу должно быть "и". Или что вы хотели сказать?
В общем, тщательнее)
evgensenin
Кратко: что раньше ели, то и кушайте, нефиг выпендриваться
В большинстве своем, проекты в мелком бизнесе однотипны по данным (не все, но очень похожи по данным и структурам), не в счет бигтек и специфичности. Ожидал конечно пункт 9, как вы делаете расследования (сравниваете 3-4 популярных решения БД), развеваете интригу - делаете неоднозначные выводы