Эмерджентный блог en ru
Эссе о разработке игр, мышлении и книгах

Как новичку выбрать базу данных

На днях спросили у меня такую штуку и я написал страничку ответа. Потом подумал, дописал и вот готовый пост.

Рассказ нацелен на новичков. Его главная задача — сократить время растерянности и направить с правильными запросами в гугл и документацию баз. Советы, надеюсь, помогут быстро выбрать базу для хобби проекта или ненагруженного рабочего проекта.

Никакой полноты изложения. Никаких крайних случаев. Никакого хайлоада. Господа профи, поберегите, пожалуйста, пуканы :-D

Базы бывают очень разные

База, в некотором роде — центральная часть проекта. На ней сходятся вопросы безопасности, надёжности, производительности, etc. Поэтому совершенствованием и оптимизацией баз данных занято большое количество специалистов.

Поскольку проекты и задачи встречаются разнообразные, то и критерии для оптимизации баз тоже сильно отличаются. Отсюда естественным путём происходит разнообразие самих баз данных.

Новичку всё это разнообразие не нужно. Ему важно быстрее запустить проект и меньше думать о базах — и так проблем хватает. Конечно, если не стоит задача изучить именно работу с базами.

Поэтому первым делом расскажу о нетехнических эвристиках для выбора базы.

И только вторым делом — о технических.

Эвристики здравого смысла

Без сортировки.

Используйте только популярные базы

В недрах любой БД творится лютая чёрная магия, которая обеспечивает работу сложных алгоритмов поверх нескольких слоёв железа.

Если разработчики БД уверяют, что именно их БД не надо настраивать и она гарантировано работает из коробки, то они врут. Есть исключения — облака, о них позже.

Если вы возьмёте в работу БД с малым количеством документации, с малым сообществом, то в какой-то момент вы рискуете остаться один на один с проблемой, которая убивает ваш проект и которую вы не можете решить самостоятельно с разумной тратой ресурсов.

Поэтому всегда смотрим на популярность БД. Оценить её можно разными способами:

  • количество вопросов на stackoverflow.com;
  • графики на trends.google.com/trends;
  • звёздочки на github.com;
  • размер страницы на wikipedia.org;
  • в конце поста приведу очень краткий список, на случай если надо было выбрать вчера.

Используйте знакомые базы

Обычно задача разработки не звучит «создать проект с использованием БД X». Главное создать проект, а что внутри — важно чуть менее.

При этом, топовые базы по ключевым возможностям не сильно отличаются друг от друга: умеют хранить данные, умеют в какую-то надёжность, etc.

Поэтому, при прочих равных и при отсутствии необходимости выжать максимум из софта, хорошей стратегией будет брать базу с которой вы уже умеете работать. Это сэкономит много ресурсов.

Убедитесь, что база уже не выбрана

По аналогии с предыдущей эвристикой.

База данных, как и любой другой софт, может использоваться не только вашим проектом.

В вашей компании уже могут использовать какие-то базы. Или вы уже выбрали другой софт, который требуют конкретную базу для своей работы.

В этом случае хорошим ходом станет решение не разводить зоопарк.

Спросите профессионалов

Спрашивать не зазорно. Профи любят отвечать на вопросы, если те хорошо сформулированы и их автор не капает на мозг.

Опишите проект (дальше будут подсказки как это сделать) и задайте вопрос знакомому или отправьте его в интернеты.

Купите консультацию

Тоже не зазорно. Особенно, если с деньгами нет проблем.

Не надейтесь на авось.

Особенно, если от работоспособности проекта зависит что-то существенное: жизни людей, работа дорогого оборудования, ваша карьера :-)

Если от вашего решения зависят жизни людей и вы недостаточно компетентны для его принятия, заплатите тому, кто компетентен.

Используйте Open Source решения

Если у вас нет огромных бюджетов. Есть исключения —  облака, о них позже.

База — не то, что легко поменять на полдороги. Особенно когда вы завязались на специфические штуки конкретной реализации.

Бизнес корпоративного ПО почти всегда работает по принципу «подсадить и доить». Если в начале разработки вас устраивает текущий план оплаты, убедитесь что вас будет устраивать и 2-3 его следующих ступени.

Масштабировать железо для open source базы может оказаться значительно дешевле, чем для корпоративной.

Ну и в целом, поддерживайте open souce — это наша защита от антиутопического будущего.

Если есть деньги, идите в облака

Если убрать стоимость конфигурации, то облачная инфраструктура, навскидку, в 3-5 раз дороже чем хостинг на выделенном сервере. По крайней мере в неумелых руках.

Но большим плюсом облаков является множество стандартизированных масштабируемых решений. Если вы боитесь ошибиться в конфигурации БД, то облачная база может существенно сократить риск проблем с производительностью. За деньги, конечно.

Это как раз тот случай, когда можно поверить разработчикам БД, что та не требует настройки. Как и можно не сильно бояться завязаться на вендора — на текущий момент облачные решения близки по фунциональности к своим open source родителям.

Но помните: чтобы не завязаться жёстко на конкретное облако, тоже думать надо и архитектуру под это прорабатывать.

Технические эвристики

Тоже без сортировки. Считайте это списком вопросов, на которые надо обязательно ответить перед выбором базы данных. Равно как и перед задаванием вопросов профессионалам.

Очень-очень упрощённо.

Обладают ли ваши данные специфическими свойствами?

Есть типы данных, которые очень отличаются от других и, по сути, определяют какие типы баз для них нужны. Например:

Если вы точно уверены в специфичном характере данных, берите такую же специфичную БД.

В остальных случаях ваш выбор с большой вероятностью будет происходить между реляционными и документо-ориентированными базами данных.

Объекты с какой структурой будут храниться в БД?

Если структура объектов фиксирована и известна, то скорее всего удобнее будет использовать реляционные БД.

Если структура объектов сложная, может часто меняться, не известна полностью, то может быть удобнее использовать документо-ориентированные БД.

Если между объектами предполагаются сложные связи, если информация о связях не должна разрушаться, должна быть надёжной, то с большей вероятностью вам подойдёт реляцонная БД. Если наоборот — документо-ориентированная.

Также обратите внимание, что некоторые базы требуют описывать схему данных заранее, а некоторые умеют определять её на ходу. Это сильно повлияет на то, как вы будете вносить изменения в код.

Насколько сложные запросы предполагаются?

Чем больше коллекций объектов и связей между объектами предполагается включать в один запрос к базе, тем с большей вероятностью лучше будет взять реляционную БД.

Или графовую базу, если всё совсем плохо и не формализировано.

Какие гарантии надёжности нужны?

Если для вас это основной критерий, платите эксперту.

Чем взрослее БД, тем она надёжнее —взрослые БД больше отлаживали, больше ошибок в них исправлено.

Реляционные базы обычно более надёжны. За ними стоит хорошая математическая теория, которая сама по себе обеспечивает дополнительную надёжность.

Какие гарантии ACID нужны?

План такой:

  1. Читаете статью на вики про ACID.
  2. Смотрите как на эти понятия ложится ваш проект.
  3. Читаете документацию базы и смотрите подходят ли её гарантии для вашего случая.

Какой объём данных будет храниться?

Если небольшой или средний (допустим, до терабайта), то обычно это не главный критерий.

Если больше, надо смотреть и тестировать конкретные use cases с конкретными базами.

Какая нагрузка на базу ожидается?

Опять таки, если небольшая, то это не основной критерий для выбора базы.

Проблема в том, что определить уровень нагрузки сложно — очень зависит от проекта, свойств данных, их количества, железа.

Могу предложить два подхода к оценке:

  • Если становится страшно, когда думаете о нагрузке, значит она большая :-D
  • Поставьте эксперимент: разверните базу, наполните данными, эмулируйте нагрузку и посмотрите как грузится железо и как быстро отвечает база.

Если ожидается большая нагрузка, то либо ставьте эскперементы с каждой базой-кандидатом, либо платите эксперту.

Какой тип доступа к данным предполагается?

Как продолжение предыдущего вопроса.

Чего будет больше: чтения или записи?

Есть базы заточенные на чтение данных и медленную запись. Есть, наоборот, на быструю запись и медленное чтение. Есть те, что можно оптимизировать в обе стороны.

Обращение ко всем данным будет с равной вероятностью или будут данные, с которыми будут работать значительно больше, чем с остальными?

Достаточно ли будет запустить базу на одной машине?

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

Ответ на этот вопрос, по сути, зависит от ответов на все вопросы о данных и нагрузке.

Какие средства есть для организации миграций?

Подробно про миграции я писал:

Ставьте эксперименты

Если сомневаетесь в определении пригодности базы по какому-либо критерию и считаете его важным для проекта — ставьте эксперименты.

Лучше потратить неделю на проверку решения, чем выкинуть полгода работы.

Не выбирайте встраиваемые базы данных

Если не уверены на 100% в том, что делаете.

Есть класс баз данных, ориентированных не встраивание в другое ПО (и на очень простые веб проекты). Это отличные базы, но если вы используете их для веба, то можете столкнуться с большими сложностями в масштабировании. Например, не сможете поднять второй процесс веб-сервера для ускорения обработки запросов.

Особо выделю SQLite. Это отличная база, её часто и справедливо рекомендуют для обучения. Но то, что удобно для обучения, далеко не всегда удобно для практики.

Если сомневаетесь, берите реляционную БД

Если до конца не ясно что выгоднее: документо-ориентированная или реляционная БД, берите реляционную.

Популярные реляционные БД давно неплохо умеют работать с документами, обычно в формате JSON, поэтому поверх их всегда можно сделать хранилище документов нормального качества. Обратное про документо-ориентированные базы, к сожалению, сказать нельзя.

Подумайте насколько удобно вам будет работать с базой

Ничто не даётся бесплатно. Чем больше может база, тем сложнее с ней может быть работать: делать запросы, мигрировать данные и схемы.

Вы можете выиграть в надёжности, но сильно потерять в скорости разработки.

Обычно, реляционные БД сложнее в обращении, чем документо-ориентированные.

Очень краткий алгоритм выбора базы

  1. Если от проекта зависят жизни или большие деньги, нанимаем эксперта.
  2. Если что-то уже используется, в первую очередь рассматриваем это.
  3. Если команда умеет работать с конкретной базой, в первую очередь рассматриваем её.
  4. Если данные специфические, ищем популярную специфическую базу.
  5. Если структура данных не формализирована и часто меняется, берём популярную документо-ориентированную базу.
  6. Если структура данных формализирована, редко меняется или работа с данными требует повышенных гарантий, используем популярную реляционную БД.

Краткий список популярных баз

Хороших баз много и лучше выбрать самому, но если очень горит, то вот:

Читать далее

2022-06-19
бэкенд, интересные посты, практика, разработка, теория