Материал переведен. Ссылка на оригинал

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

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

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

Базы данных SQL и NoSQL

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

Базы данных SQL

Реляционная база данных — это набор таблиц, между которыми установлены определенные взаимосвязи. Для обслуживания реляционной базы данных и создания запросов к ней система управления базой данных использует язык структурированных запросов (Structured Query Language, SQL) — обычное пользовательское приложение, предоставляющее простой интерфейс программирования для взаимодействия с базой данных. 

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

Преимущества баз данных SQL

Реляционная база данных идеально подходит для хранения структурированных данных (почтовых кодов, номеров кредитных карточек, дат, идентификационных номеров). SQL — испытанная технология: она хорошо задокументирована, имеет прекрасную поддержку и отлично работает с большинством современных структур и библиотек. Наиболее яркими примерами баз данных SQL служат PostgreSQL и MySQL. Обе зарекомендовали себя как стабильные и безопасные.

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

Использование системы управления реляционными базами данных (РСУБД) защищает данные от потери и повреждения благодаря четырем свойствам ACID: атомарности, согласованности, изолированности и прочности. Чтобы лучше понять, что это значит, предположим, что две покупательницы одновременно пытаются купить красное платье одинакового размера. При соблюдении принципов ACID эти транзакции гарантированно друг друга не перекроют. 

• Атомарность означает, что каждая транзакция (последовательность из одной или нескольких операций SQL) рассматривается как единое целое. Она может завершиться удачно или неудачно только целиком: если одна из операций завершается неудачно, вся транзакция завершается неудачно. Когда пользователь покупает товар, деньги снимаются с его счета и переводятся на счет продавца. Атомарность гарантирует, что, если транзакция для пополнения счета заканчивается неудачно, операция снятия средств не выполняется. 

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

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

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

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

Недостатки реляционных баз данных

У реляционных баз данных есть и недостатки. 

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

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

• Реляционные базы данных работают только на одном сервере. Следовательно, чтобы ваша СУБД справлялась с еще большим объемом данных, вам придется потратиться на дорогостоящее физическое оборудование. 

Эти недостатки вынудили разработчиков искать альтернативы реляционным базам данных. В результате появились базы данных NoSQL и NewSQL. 

Базы данных NoSQL

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

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

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

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

Базы данных NoSQL можно разделить на четыре типа.

• Хранилища типа «ключ-значение»

Это база данных NoSQL простейшего типа, в которой могут храниться только пары «ключ-значение» и предлагаются базовые функции для получения значения, связанного с ключом. Хранилище типа «ключ-значение» — отличный вариант, если вы хотите быстро найти информацию с помощью ключа. Наиболее яркими примерами хранилищ такого типа являются базы данных Amazon DynamoDB и Redis. 

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

Вот почему хранилища типа «ключ-значение» используют поставщики услуг хостинга типа ScaleGrid, Compose и Redis Labs. Разработчики часто используют хранилища такого типа для кэширования данных. Эти хранилища также хорошо подходят для хранения комментариев в блогах, обзоров продукции, профилей пользователей и различных настроек. 

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

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

В большинстве случаев хранилища типа «ключ-значение» используются в сочетании с базой данных другого типа. В приложениях Healthfully и KPMG мы использовали хранилище Redis типа «ключ-значение» вместе с системой управления реляционными базами данных PostgreSQL. 

• Документные хранилища

В документно-ориентированных базах данных вся информация, относящаяся к определенному объекту, хранится в одном файле формата BSON, JSON или XML. Однотипные документы могут быть сгруппированы в так называемые коллекции или списки. Эти базы данных позволяют разработчикам не беспокоиться о типах данных и надежных связях. 

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

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

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

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

• Столбцовое хранилище

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

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

• Графовое хранилище

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

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

Графовые базы данных оптимизированы для проектов с графовыми структурами данных, таких как социальные сети и семантическая паутина. Neo4J и Datastax Enterprise — лучшие образцы графовых баз данных. 

NewSQL — объединение преимуществ баз данных SQL и NoSQL

Особого внимания заслуживает NewSQL — класс реляционных баз данных, сочетающий в себе возможности баз данных SQL и NoSQL. 

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

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

Наиболее популярные базы данных NewSQL: ClustrixDB, CockroachDB, NuoDB, MemSQL и VoltDB. 

Что нужно учитывать при выборе базы данных?

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

• Тип данных 

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

• Масштабируемость 

По мере развития вашего веб-продукта должна расти и его база данных. На выбор базы данных может повлиять предпочитаемый вами тип масштабирования: горизонтальное или вертикальное. Нереляционные базы данных с их хранилищами типа «ключ-значение» оптимизированы для горизонтального масштабирования, а реляционные базы данных — для вертикального.

• Безопасность

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

• Интеграция

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

Например, ArangoDB показывает отличную производительность, но библиотеки для этой СУБД появились относительно недавно и пока не имеют поддержки. Использовать ArangoDB в сочетании с другими инструментами рискованно, поэтому сообщество не рекомендует применять ArangoDB для сложных проектов. 

Читайте также: Облачные решения для разработки веб-приложений: что и как выбрать?

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

Хотите знать, какие базы данных самые популярные в 2021 году? Взгляните на базы данных из следующего списка.

OracleDB

OracleDB — РСУБД, созданная в 1977 году и по сей день остающаяся самым известным и надежным решением. Она занимает первое место в рейтинге DB-Engines. Рассмотрим подробнее причины популярности OracleDB. 

• Ее поддерживает компания Oracle, поэтому она надежна. Разработчики отмечают, что OracleDB редко выходит из строя и получает регулярные обновления. 

• Она хорошо масштабируется и способна обрабатывать очень большие объемы данных. В настоящее время Oracle переносит все свои продукты и сервисы в облако, что обеспечивает большую гибкость.

• Она безопасна за счет строгого следования всем современным стандартам безопасности (включая совместимость с PCI) и предлагает надежное шифрование конфиденциальных данных.

• Она эффективно управляет памятью и легко справляется со сложными операциями. Кроме того, она эффективно взаимодействует с различными сторонними инструментами.

• Она превосходит другие решения с точки зрения скорости доступа к данным по сети. 

У OracleDB имеются и недостатки.

• OracleDB — самая популярная СУБД, но и одна из самых дорогих. Одна лицензия на процессор для стандартной версии будет стоить 17 500 долл. США.

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

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

MySQL 

MySQL — одна из самых популярных систем управления реляционными базами данных, которая была создана в 1995 году и сейчас находится под управлением Oracle. У этой системы баз данных с открытым исходным кодом имеются огромная пользовательская база и отличная поддержка, и она хорошо работает с большинством структур и библиотек. Предоставляется бесплатно, но предлагаются дополнительные функции по фиксированной цене.

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

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

Uber, Facebook, Tesla, YouTube, Netflix, Spotify, Airbnb и многие другие компании используют в своих сервисах MySQL. Мы тоже используем эту СУБД в наших проектах.

PostgreSQL

Это объектно-реляционная база данных, то есть она похожа на реляционные базы данных, но все данные в ней представлены в виде объектов, а не столбцов и строк.

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

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

Мы перенесли приложение World Cleanup (приложение для управления мероприятием World Cleanup Day) из CouchDB в PostgreSQL. Переход на PostgreSQL позволяет нам не только одновременно выполнять операции ввода и вывода, но и легко справляться с большими нагрузками. 

MongoDB

MongoDB — наиболее популярная база данных NoSQL, которую мы используем в наших проектах. В MongoDB все данные хранятся в документах формата BSON (Binary JSON). Благодаря этому данные можно легко передавать между веб-приложениями и серверами в человекочитаемом формате. 

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

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

Мы используем MongoDB в сочетании с Redis в Boothapp — платформе социальной электронной коммерции для ближневосточного рынка.

Redis 

Redis — это хранилище типа «ключ-значение» с открытым исходным кодом, которое часто используется в качестве кэша для работы с другим решением для хранения данных. Основная причина, по которой разработчики выбирают Redis, — скорость, значительно превосходящая другие системы управления базами данных. И еще ее легко устанавливать, настраивать и использовать. 

Но в Redis отсутствует встроенное шифрование и хранятся данные только пяти типов: списки, наборы, отсортированные наборы, хэши и строки. Redis в первую очередь предназначена для хранения наборов данных без сложной структуры. Поэтому этот инструмент обычно используется в сочетании с системой баз данных другого типа и иногда для микросервисов. Так как Redis — отличное решение для кэширования, мы используем его в этом качестве в большинстве своих проектов, включая приложения KPMG, Half Cost Hotels, Mikitsune и Healthfully. 

Elasticsearch

Elasticsearch — это документно-ориентированная база данных с открытым исходным кодом, в которой хранятся и индексируются данные любого типа (текстовые, числовые или геопространственные) в формате JSON. Тем самым она обеспечивает быстрый поиск и получение данных. Elasticsearch создана на основе Lucene — Java-библиотеки с открытым исходным кодом, реализующей функции хранения и поиска данных.

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

Начиная с версии Elasticsearch 6.7, пользователи могут управлять жизненным циклом данных. Данные можно отнести к категории «горячих», «теплых» или «холодных» в зависимости от количества запросов к ним и хранить в «горячих», «теплых» или «холодных» узлах соответственно. Это позволяет быстрее получать самые актуальные (то есть самые горячие) данные, поскольку в качестве горячих узлов используются твердотельные накопители — устройства хранения более нового и более быстрого типа. Теплым и холодным узлам вполне подходят традиционные жесткие диски, которые работают медленнее.

Netflix, Stack Overflow, LinkedIn и Medium используют базу данных Elasticsearch.

Объединение и совмещение баз данных 

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

Redis часто используется в сочетании с другими базами данных. Мы использовали Redis вместе с PostgreSQL для Healthfully — медицинской платформы для связи пациентов и медицинских работников. Мы выбрали систему Redis для хранения кэша и маркеров (токенов), поскольку она работает быстрее, чем большинство современных баз данных. По той же причине мы использовали Redis вместе с PostgreSQL при разработке приложения для KPMG. Мы часто используем эту пару в наших проектах, поскольку можем легко и быстро делать ссылки из Redis на PostgreSQL. 

Сочетание MongoDB и PostgreSQL — не лучшая идея, потому что эти базы данных равны с точки зрения использования ресурсов и хранения данных. Например, предположим, что у вас есть социальная сеть типа Instagram и вам требуется хранить информацию о сообщениях, лайках, подписчиках и профилях пользователей. Данные о лайках и сообщениях хранятся в MongoDB, а данные о профилях пользователей и подписчиках — в PostgreSQL. Сперва вам нужно взять данные о профилях из PostgreSQL, а затем данные о сообщениях из MongoDB, что затратно по времени и неэффективно.

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

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

Перевод статьи подготовлен в преддверии старта курса "Базы данных".

Напоминаем о том, что завтра пройдет второй день онлайн-интенсива «Бэкапы и репликация PostgreSQL. Практика применения». Цели занятия: настроить бэкапы; восстановить информацию после сбоя.

• ЗАПИСАТЬСЯ НА ИНТЕНСИВ