Как выбрать базу данных?
Часто перед руководителем разработки стоит вопрос о выборе технологии из уже существующих и доступных на рынке. И одно из самых сложных решений — подходящая база данных. Языки программирования, как правило, похожи друг на друга. Вопрос выбора языка — дело вкуса. Неправильный же выбор базы данных может оказаться губительным для проекта. Я расскажу о том, на какие аспекты я обращаю внимание при выборе СУБД.
Основные технологии
Помните, что вам не придётся ограничиваться одной технологией. Каждый сервис, в идеале, должен иметь свою собственную базу, и вы можете выбирать подходящие технологии. Старайтесь найти компромисс между использованием неподходящей технологии во всех подсистемах и созданием зоопарка технологий. Универсального рецепта нет, но я бы рекомендовал составить список одобренных технологий на каждую из следующих задач: ● реляционная база данных для 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-транзакций для финансовых подсистем — точно не самая лучшая идея.
Наконец, последнее, но не менее важное, — учитывайте экспертизу своей команды. Изучение новой технологии всегда занимает время, а без опыта люди будут допускать типичные ошибки. Часто самым лучшим решением будет взять самую знакомую технологию.