Как выбрать правильную базу данных для вашего приложения

Введение

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

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

Потратив время на осознанный выбор технологии базы данных заранее, вы можете принять ценное решение на раннем этапе для вашего приложения.

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

Каждая технология баз данных имеет свои преимущества и недостатки. Облачные провайдеры, такие как Amazon, предлагают различные варианты баз данных и хранилищ, что усложняет задачу выбора подходящей.

Реляционные базы данных долгое время были основным механизмом хранения данных. Нереляционные базы данных существуют с 1960-х годов, но недавно получили распространение благодаря таким популярным вариантам, как MongoDB.

В этой статье мы рассмотрим факторы, которые следует учитывать при выборе любой базы данных.

Язык определяет базу данных

Прежде всего. Язык или технология, которую вы собираетесь использовать, никогда не определяют базу данных ❌.

Мы привыкли к таким технологическим стекам, как MERN (MongoDB, Express, React, Node.js) и LAMP (Linux, Apache, MySQL, PHP).

Существуют определенные причины, по которым эти стеки развивались. Но не думайте, что это правила. Вы можете использовать базу данных MongoDB в своем Java-проекте. Вы можете использовать MySQL в своем Node.js. Возможно, вы найдете не так много руководств, но именно ваши требования должны определять тип базы данных & а не язык.

Понимание компромисса

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

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

Согласованность означает, что любой запрос на чтение вернет последнюю запись.

Доступность означает, что все (безотказные) узлы доступны для запросов и должны отвечать в разумные сроки.

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

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

Структура данных

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

Например, допустим, мы создаем приложение для управления студентами, где нам нужно хранить информацию об определенных курсах, и каждый курс должен быть пройден одним или несколькими студентами. В этом случае мы можем создать 2 таблицы (Students и Courses), где значение в столбце Student ID внутри таблицы Courses указывает на строки в таблице Students по значению их столбца ID.

Кроме того, если вы хотите, чтобы ваша БД соответствовала стандарту ACID, например, в случаях, когда вы обрабатываете платежи и транзакции в вашем приложении, то и в этом случае вам следует предпочесть базы данных на основе SQL, поскольку аналог, т.е. база данных NoSQL, обеспечивает слабую согласованность.

Соответствие стандарту ACID защищает целостность ваших данных, точно определяя, что такое транзакция и как она взаимодействует с вашей базой данных. Это позволяет избежать рассинхронизации таблиц базы данных, что очень важно для финансовых операций. Соответствие ACID гарантирует достоверность транзакций даже в условиях ошибок, технологических сбоев, катастрофических событий и т.д.

С другой стороны, если ваши требования к данным неясны или если ваши данные неструктурированы, лучшим выбором может стать NoSQL.

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

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

Базовая доступность

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

Мягкое состояние

Состояние базы данных может меняться с течением времени.

Эвентуальная согласованность

База данных в конечном итоге станет согласованной, и данные будут распространяться повсеместно в какой-то момент в будущем.

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

Шаблоны запросов

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

Нужен ли вам поиск по одному ключу или по различным другим параметрам? Нужен ли вам нечеткий поиск по данным?

• Используйте нереляционные базы данных Если вы собираетесь получать данные по ключу, то все, что вам нужно, — это хранилище ключевых значений (например, DynamoDB).

• С другой стороны, если вам нужно запрашивать множество различных полей, вы можете выбрать как реляционную БД (например, MySQL), так и документальную БД (например, MongoDB).

• Если вам нужны нечеткие поисковые запросы (свободный поиск текста), то лучше всего подойдут поисковые системы типа Elasticsearch (которая также относится к NoSQL DBs).

• Но если ваши данные хорошо структурированы и организованы, то очень эффективно запрашивать их с помощью базы данных SQL.

SQL — это популярный язык запросов, который существует уже более 50 лет, поэтому он очень развит и хорошо известен. Он эффективно выполняет запросы и поиск с использованием JOINов и быстро редактирует данные. Он очень легкий и декларативный.

Согласованность

Требуется ли строгая согласованность (чтение после записи) или можно обойтись обычной согласованностью?

Если вам необходимо читать данные сразу после записи (т.е. сильная согласованность), то реляционная база данных (например, MySQL) обычно подходит больше, чем нереляционная база данных (например, MongoDB).

Производительность и масштабирование

Производительность всех баз данных снижается по мере увеличения объема трафика чтения/записи. Именно в это время в дело вступают такие средства оптимизации, как индексирование данных и масштабирование БД.

Производительность зависит от различных факторов, но общая производительность в значительной степени зависит от выбора правильной реализации для вашего случая использования.

Базы данных SQL и NoSQL масштабируются по-разному, поэтому вам придется подумать о том, как будет расти ваш набор данных в будущем.

Базы данных SQL масштабируются вертикально, то есть для масштабирования базы данных вам потребуется увеличить мощность одного сервера (увеличить количество CPU, RAM или SSD). Базы данных SQL были разработаны для поддержания целостности данных, поэтому их лучше всего запускать на одном сервере, поэтому их нелегко масштабировать.

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

Эта несложная природа горизонтального масштабирования нереляционных баз данных делает их лучше реляционных баз данных в плане доступности.

Способность баз данных NoSQL к горизонтальному масштабированию связана с отсутствием структуры данных. Поскольку NoSQL требует гораздо меньше структуры, чем SQL, каждый хранимый объект является практически самодостаточным. Таким образом, объекты могут легко храниться на нескольких серверах без необходимости связывания. Это не относится к SQL, где каждая строка таблицы и столбец должны быть связаны.

Это также является проблемой производительности, и здесь SQL не справляется с масштабированием. По мере роста размера и количества баз данных, RDBMS, как мы уже видели, требует решений по вертикальному масштабированию. Однако за это приходится платить немалые деньги. Хотя многие коммерческие продукты RDBMS предлагают горизонтальное масштабирование, они также могут быть очень дорогими и даже сложными в реализации.

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

Заключение

В этой статье мы рассмотрели множество факторов, которые следует учитывать при выборе типа базы данных. Вкратце, базы данных SQL обеспечивают большие преимущества для транзакционных данных, структура которых меняется нечасто (или вообще не меняется) и где целостность данных имеет первостепенное значение. Они также лучше всего подходят для быстрых аналитических запросов. Базы данных NoSQL обеспечивают большую гибкость и масштабируемость, что делает их полезными для быстрой или итерационной разработки.

Вот небольшое резюме того, что мы обсудили выше:

Причины использовать базу данных SQL

• Когда вам нужна поддержка ACID
• Ваше приложение требует большого количества транзакций
• Целостность данных очень важна
• Вы не ожидаете большого количества изменений в схеме.

Причины для использования базы данных NoSQL

• Вы хотите хранить большие объемы данных без структуры
• Вы постоянно получаете несвязанные, неопределенные или изменяющиеся требования к данным
• Скорость и масштабируемость имеют решающее значение
• Когда целостность данных не является вашей главной целью, и вы беспокоитесь о доступности (& конечная согласованность будет достаточно хороша для вашего случая использования)

Надеюсь, это поможет вам понять, о чем нужно думать при выборе базы данных. О каких дополнительных вопросах вы думаете при выборе базы данных? Дайте мне знать о своих мыслях в комментариях.

---

Начинаете заниматься веб-разработкой? 💻

Ознакомьтесь с ▶ HTML To React: The Ultimate Guide

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

Она содержит 👇

✅ Прямые и понятные объяснения

✅ Простые примеры кода

✅ 50+ интересных идей проектов

✅ 3 списка секретных ресурсов

✅ Бонусная подготовка к интервью

Вы даже можете взять бесплатный образец из этой книги

и вот ссылка с 60% скидкой от первоначальной цены на полный комплект книг ⬇