Курсы

Курсы в разработке Подготовительные курсы
Работа в компаниях Компаниям Блог +7 499 110-61-65

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

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 комментариев
Для комментирования необходимо авторизоваться