Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Теги: mysql, реляционные бд, база данных, clickhouse, key-value хранилища, кластерные решения, postgres

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

3 <h2>Основные технологии</h2>

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

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

6 <h2>Функциональные особенности выбора</h2>

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

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

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

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

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