Как выбрать базу данных? | OTUS
🔥 Начинаем BLACK FRIDAY!
Максимальная скидка -25% на всё. Успейте начать обучение по самой выгодной цене.
Выбрать курс

Курсы

Программирование
iOS Developer. Basic
-25%
Python Developer. Professional
-25%
Разработчик на Spring Framework
-25%
Golang Developer. Professional
-25%
Python Developer. Basic
-25%
iOS Developer. Professional
-25%
Highload Architect
-25%
JavaScript Developer. Basic
-25%
Kotlin Backend Developer
-25%
JavaScript Developer. Professional
-25%
Android Developer. Basic
-25%
Unity Game Developer. Basic
-25%
Разработчик C#
-25%
Программист С Web-разработчик на Python Алгоритмы и структуры данных Framework Laravel PostgreSQL Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Flutter Mobile Developer Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer Супер-интенсив "Azure для разработчиков"
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-25%
DevOps практики и инструменты
-25%
Архитектор сетей
-25%
Инфраструктурная платформа на основе Kubernetes
-25%
Супер-интенсив «ELK»
-16%
Супер-интенсив «IaC Ansible»
-16%
Супер-интенсив "SQL для анализа данных"
-16%
Базы данных Сетевой инженер AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT IoT-разработчик Супер-интенсив «СУБД в высоконагруженных системах»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Как выбрать базу данных?

HL_Deep_3.9-5020-900a92.png

Часто перед руководителем разработки стоит вопрос о выборе технологии из уже существующих и доступных на рынке. И одно из самых сложных решений — подходящая база данных. Языки программирования, как правило, похожи друг на друга. Вопрос выбора языка — дело вкуса. Неправильный же выбор базы данных может оказаться губительным для проекта. Я расскажу о том, на какие аспекты я обращаю внимание при выборе СУБД.

Основные технологии

Помните, что вам не придётся ограничиваться одной технологией. Каждый сервис, в идеале, должен иметь свою собственную базу, и вы можете выбирать подходящие технологии. Старайтесь найти компромисс между использованием неподходящей технологии во всех подсистемах и созданием зоопарка технологий. Универсального рецепта нет, но я бы рекомендовал составить список одобренных технологий на каждую из следующих задач: ● реляционная база данных для OLTP (mysql, postgres); ● реляционная база данных для OLAP (clickhouse); ● кеш (redis, memcache, tarantool); ● Key-value хранилища (redis, memcache, rocksdb, riak); ● кластерные решения (cassandra, mongodb);

Список выше достаточно условен. К примеру, я часто использую tarantool не как кеш, а как первичный источник данных. MySQL может быть кластерным решением. Но такое разделение позволит хотя бы сориентироваться в технологиях.

Функциональные особенности выбора

Следующим важным фактором в выборе будет набор функциональных требований к СУБД. Если вы делаете систему полнотекстового поиска, то лучше делать её не на основе redis, mongodb и т. д., а взять специализированные решения: sphinx, elasticsearch. Если вам нужен сервис, который работает с геоданными, убедитесь, что база данных поддерживает географические индексы.

Учтите возможность и простоту горизонтального масштабирования хранилища. Mongodb, например, масштабируется намного проще, чем mysql. Но масштабирование нужно не всегда. Не переусложняйте. Если ваш проект имеет небольшую целевую аудиторию и не будет расти, возьмите самое простое и надёжное решение. Это сэкономит вам время на запуск.

Отказоустойчивость также очень важный фактор. Любые сервера выходят из строя. И чем больше серверов в вашей системе, тем выше вероятность отказа какого-либо из них. Старайтесь избегать создания единых точек отказа, хотя бы в критичных подсистемах. Изучите возможности отказоустойчивости систем. Некоторые решения, такие как cassandra, устойчивы даже к отказу целого дата-центра. Не забывайте, что чуда не случится. Во-первых, проводите учения, чтобы убедиться, что вы всё верно сконфигурировали. Во-вторых, ценой отказоустойчивости будет являться потеря скорости.

Обязательно учитывайте надёжность базы данных. К примеру, mongodb до середины 2018 года не поддерживала ACID-транзакции. Оценивайте, критична ли надёжность данного сервиса, или всё же вам больше требуется производительность. Для систем логирования, скорее всего, скорость будет предпочтительнее. Но использование систем без ACID-транзакций для финансовых подсистем — точно не самая лучшая идея.

Наконец, последнее, но не менее важное, — учитывайте экспертизу своей команды. Изучение новой технологии всегда занимает время, а без опыта люди будут допускать типичные ошибки. Часто самым лучшим решением будет взять самую знакомую технологию.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
🎁 Максимальная скидка!
Черная пятница уже в OTUS! Скидка -25% на всё!