Как новичку выбрать базу данных
На днях спросили у меня такую штуку и я написал страничку ответа. Потом подумал, дописал и вот готовый пост.
Рассказ нацелен на новичков. Его главная задача — сократить время растерянности и направить с правильными запросами в гугл и документацию баз. Советы, надеюсь, помогут быстро выбрать базу для хобби проекта или ненагруженного рабочего проекта.
Никакой полноты изложения. Никаких крайних случаев. Никакого хайлоада. Господа профи, поберегите, пожалуйста, пуканы :-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 родителям.
Но помните: чтобы не завязаться жёстко на конкретное облако, тоже думать надо и архитектуру под это прорабатывать.
Технические эвристики
Тоже без сортировки. Считайте это списком вопросов, на которые надо обязательно ответить перед выбором базы данных. Равно как и перед задаванием вопросов профессионалам.
Очень-очень упрощённо.
Обладают ли ваши данные специфическими свойствами?
Есть типы данных, которые очень отличаются от других и, по сути, определяют какие типы баз для них нужны. Например:
- С графами лучше работают графовые базы данных.
- С временными рядами лучше работают базы для временных рядов.
- Для данных аналитики тоже есть свой тип баз (см. OLAP куб, например).
- etc.
Если вы точно уверены в специфичном характере данных, берите такую же специфичную БД.
В остальных случаях ваш выбор с большой вероятностью будет происходить между реляционными и документо-ориентированными базами данных.
Объекты с какой структурой будут храниться в БД?
Если структура объектов фиксирована и известна, то скорее всего удобнее будет использовать реляционные БД.
Если структура объектов сложная, может часто меняться, не известна полностью, то может быть удобнее использовать документо-ориентированные БД.
Если между объектами предполагаются сложные связи, если информация о связях не должна разрушаться, должна быть надёжной, то с большей вероятностью вам подойдёт реляцонная БД. Если наоборот — документо-ориентированная.
Также обратите внимание, что некоторые базы требуют описывать схему данных заранее, а некоторые умеют определять её на ходу. Это сильно повлияет на то, как вы будете вносить изменения в код.
Насколько сложные запросы предполагаются?
Чем больше коллекций объектов и связей между объектами предполагается включать в один запрос к базе, тем с большей вероятностью лучше будет взять реляционную БД.
Или графовую базу, если всё совсем плохо и не формализировано.
Какие гарантии надёжности нужны?
Если для вас это основной критерий, платите эксперту.
Чем взрослее БД, тем она надёжнее —взрослые БД больше отлаживали, больше ошибок в них исправлено.
Реляционные базы обычно более надёжны. За ними стоит хорошая математическая теория, которая сама по себе обеспечивает дополнительную надёжность.
Какие гарантии ACID нужны?
План такой:
- Читаете статью на вики про ACID.
- Смотрите как на эти понятия ложится ваш проект.
- Читаете документацию базы и смотрите подходят ли её гарантии для вашего случая.
Какой объём данных будет храниться?
Если небольшой или средний (допустим, до терабайта), то обычно это не главный критерий.
Если больше, надо смотреть и тестировать конкретные use cases с конкретными базами.
Какая нагрузка на базу ожидается?
Опять таки, если небольшая, то это не основной критерий для выбора базы.
Проблема в том, что определить уровень нагрузки сложно — очень зависит от проекта, свойств данных, их количества, железа.
Могу предложить два подхода к оценке:
- Если становится страшно, когда думаете о нагрузке, значит она большая :-D
- Поставьте эксперимент: разверните базу, наполните данными, эмулируйте нагрузку и посмотрите как грузится железо и как быстро отвечает база.
Если ожидается большая нагрузка, то либо ставьте эскперементы с каждой базой-кандидатом, либо платите эксперту.
Какой тип доступа к данным предполагается?
Как продолжение предыдущего вопроса.
Чего будет больше: чтения или записи?
Есть базы заточенные на чтение данных и медленную запись. Есть, наоборот, на быструю запись и медленное чтение. Есть те, что можно оптимизировать в обе стороны.
Обращение ко всем данным будет с равной вероятностью или будут данные, с которыми будут работать значительно больше, чем с остальными?
Достаточно ли будет запустить базу на одной машине?
Или нужен кластер. Если нужен кластер, то надо через документацию и эксперименты проверять пригодность базы для распределённой работы. Не забываем про облака.
Ответ на этот вопрос, по сути, зависит от ответов на все вопросы о данных и нагрузке.
Какие средства есть для организации миграций?
Подробно про миграции я писал:
Ставьте эксперименты
Если сомневаетесь в определении пригодности базы по какому-либо критерию и считаете его важным для проекта — ставьте эксперименты.
Лучше потратить неделю на проверку решения, чем выкинуть полгода работы.
Не выбирайте встраиваемые базы данных
Если не уверены на 100% в том, что делаете.
Есть класс баз данных, ориентированных не встраивание в другое ПО (и на очень простые веб проекты). Это отличные базы, но если вы используете их для веба, то можете столкнуться с большими сложностями в масштабировании. Например, не сможете поднять второй процесс веб-сервера для ускорения обработки запросов.
Особо выделю SQLite. Это отличная база, её часто и справедливо рекомендуют для обучения. Но то, что удобно для обучения, далеко не всегда удобно для практики.
Если сомневаетесь, берите реляционную БД
Если до конца не ясно что выгоднее: документо-ориентированная или реляционная БД, берите реляционную.
Популярные реляционные БД давно неплохо умеют работать с документами, обычно в формате JSON, поэтому поверх их всегда можно сделать хранилище документов нормального качества. Обратное про документо-ориентированные базы, к сожалению, сказать нельзя.
Подумайте насколько удобно вам будет работать с базой
Ничто не даётся бесплатно. Чем больше может база, тем сложнее с ней может быть работать: делать запросы, мигрировать данные и схемы.
Вы можете выиграть в надёжности, но сильно потерять в скорости разработки.
Обычно, реляционные БД сложнее в обращении, чем документо-ориентированные.
Очень краткий алгоритм выбора базы
- Если от проекта зависят жизни или большие деньги, нанимаем эксперта.
- Если что-то уже используется, в первую очередь рассматриваем это.
- Если команда умеет работать с конкретной базой, в первую очередь рассматриваем её.
- Если данные специфические, ищем популярную специфическую базу.
- Если структура данных не формализирована и часто меняется, берём популярную документо-ориентированную базу.
- Если структура данных формализирована, редко меняется или работа с данными требует повышенных гарантий, используем популярную реляционную БД.
Краткий список популярных баз
Хороших баз много и лучше выбрать самому, но если очень горит, то вот:
- Реляционные: PostgreSQL, MariaDB
- Докуменнто-ориентированные: MongoDB
- Графовые: Neo4j
Читать далее
- Как завалить собес у меня
- Модная типизация в Python
- Генерация подземелий — от простого к сложному
- О проектировании миров
- Бесконечность схем данных
- Как я делал и делал бы поддержку GDPR
- Автоматический генератор квестов
- Считаем бизнес-план для игры в Steam
- Миграции backend на практике
- О миграциях backend