Разработка

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

Опубликовано

4 года назад

13.01.2021

Автор:

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

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

Key–Value («ключ-значение»)

В данном случае наша база данных структурирована так же, как объект JSON — каждый ключ уникален, и каждый ключ указывает на какое-то значение.

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

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

За и против

+ Молниеносно быстрая
+ Простая
+ Гибкая

— Не подходит для больших сложных данных.

Когда использовать эту базу

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

Wide Column (база данных с широкими столбцами)

Это похоже на «ключ-значение», но на стероидах. Каждая запись хранит набор столбцов вместо текстовых данных.

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

Поскольку схемы нет, база может обрабатывать неструктурированные данные и работает с языком запросов под названием CQL, который похож на SQL, но менее мощный.

Данные могут поступать непрерывным потоком, например, с IoT-устройств, фондовой биржи, от финансовых транзакций или вашей истории просмотров Netflix.

За и против

+ Нет схемы — гибкость
+ Может обрабатывать большие данные
+ Горизонтальное масштабирование

— Не подходит для сложных запросов

Когда использовать эту базу

Частая запись
Нечастое обновление или чтение

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

Документальная база данных

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

Документы группируются в коллекции, и эти коллекции можно структурировать в логическую иерархию.

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

За и против

+ Нет схемы — гибкость
+ Может выполнять простые запросы
+ Более быстрое чтение

— Невозможно выполнять сложные запросы
— Денормализация данных, что создает свои проблемы

Поскольку наша база данных не может объединять запросы, что нам делать, чтобы получить все связанные данные сразу?

Хранить все вместе! Поощряется денормализация вашей базы данных, а дублирование/несогласованность данных — это компромисс, на который мы готовы пойти.

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

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

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

Реляционная база данных

Все мы слышали об этих базах данных, и самыми популярными из них являются MySQL, Postgres и SQL Server. Они существуют уже давно и до сих пор остаются популярным выбором для многих приложений.

Мы используем язык структурированных запросов (SQL).

Что значит «реляционная»

Представьте себе автомобильный завод, где есть разные отделы, производящие автомобильные детали.

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

Каждой изготовленной детали присвоен уникальный идентификатор.

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

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

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

Недостатки

Подобно тому, как со временем изменение структуры автомобильного завода в соответствии с меняющимися требованиями будет стоить автомобилестроительной компании кучу времени и денег, также происходит и с большими приложениями. При использовании реляционной базы данных обязательно убедитесь, что ваши требования к данным понятны и конечны.
Кроме того, если вы построите завод мощностью 30 автомобилей в месяц, вы не сможете легко масштабировать свой завод, чтобы производить 90 автомобилей в месяц. Точно так же наши реляционные базы данных могут быть трудно масштабируемыми (но есть некоторые исключения, такие как Cockroach DB и PostgreSQL, которые предназначены для масштабируемой работы).

Преимущества

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

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

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

Но что, если нам не нужно создавать схему и мы можем напрямую хранить отношения как данные?

Графовая база данных

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

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

В графах это намного проще, поскольку нам не нужно хранить часть данных, относящуюся к отношениям, отдельно, все происходит инстинктивно.

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

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

Поисковая база данных

Если вы создаете приложение, подобное Google, в котором при поиске по запросу с небольшой строкой вам нужно быстро возвращать все совпадающие записи — вы говорите о системе полнотекстового поиска.

Такие базы данных основаны на проекте Apache Lucene, начатом в 1999 году.

Algolia и MeiliSearch — это системы полнотекстового поиска.

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

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

Самую захватывающую вещь я оставил напоследок.

Мультимодельная база данных

Есть несколько вариантов, но самым популярным из них, кажется, является Fauna.

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

С Fauna нам не нужно беспокоиться о моделировании данных, схемах, масштабировании, репликации или нормализации и просто получить данные JSON. Мы определяем, как мы хотим получить доступ к нашим данным, используя GraphQL.

Возьмем пример работы приложения в стиле Instagram. Мы определим наши правила, используя JSON для User, Post и Query.

Мы только что загрузили нашу GraphQL схему — она автоматически создает коллекцию для хранения данных и индексы для запроса данных.

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

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

Самое приятное — это ACID-совместимый подход, работающий очень быстро.

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

Недостатки

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

За и против

+ Нет схемы
+ ACID-совместимость
+ Чрезвычайно быстрая
+ Облако делает тяжелую работу

— Дорого

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