Обычно выбор базы данных предопределен тем, что использовали ранее или уже применяли в смежных проектах. Но иногда выпадает счастливый билет выбрать что-то для совершенно нового проекта. И правильный выбор базы данных становится одним из самых важных решений. От этого зависит, в первую очередь, количество усилий, которые нужно приложить для решения той или иной задачи. А это влияет на срок и бюджет проекта, как и стоимость специалистов, которые владеют навыками работы с той или иной СУБД.
От базы данных во многом зависит производительность всего решения и его надежность. Водораздел обычно проходит по базовой технологии работы с БД — брать классическую SQL-базу или же NoSQL? У обеих категорий свои преимущества и недостатки, и стоит в них разобраться детальнее, чтобы провести сравнительный анализ и принять информированное решение.
В статье мы обсудим, их архитектурные принципы, оптимальные варианты использования, а также плюсы и минусы каждой технологии. Мы оценим, как эти базы данных справляются с вопросами производительности, масштабируемости, консистентности, гибкости схемы, безопасности и стоимости.
Описание основных различий между SQL и NoSQL
SQL-базы данных или реляционные БД работают по структурированному принципу хранения информации, представленной в виде таблиц с четко определенными взаимосвязями и ограничениями, которые накладывают на языком, БД SQL оперируют таблицами данных данные. Говоря простыми процедурами их обработки, связанными с таблицами, используя для этого специальный Structured Query Language (SQL).
Производители SQL-баз данных о едином стандарте (ANSI SQL) договорились, но вот использовать его не стали: практически каждый производитель изобрел свой диалект. И если вы разбираетесь в PostgreSQL, это совсем не значит, что вы можете свободно перейти на Oracle при необходимости. Для вас «перейти» будет означать «переписать большую часть кода базы данных и скорее всего уже другими специалистами». То есть это может стоить очень дорого.
Важная особенность реляционных баз данных — работа по принципу ACID (Atomicity/Consistency/Isolation/Durability). Его реализация обеспечивает целостность (корректность) информации. Сегодня на рынке представлен целый ряд хороших систем, в которых используется этот принцип.
Базы данных NoSQL нереляционные и отказываются от четкой структуры данных в пользу полуструктурированных. И каждый из производителей решил эту задачу по-своему. Поэтому NoSQL-базы данных могут быть документоориентированными, графовыми, колоночными или использовать ассоциативные массивы (ключ/значение) как хранилища. В NoSQL базах данных выбраны очень разные принципы построения своих систем, а потому нет и общности языка управления данными в них. Зато эти БД обычно хорошо реализуют горизонтальную масштабируемость, позволяют работать с различными типами данных. А еще структура информации в NoSQL-базе может изменяться динамически, прямо по ходу работы приложения. За счет этих свойств NoSQL-базы подходят для обработки больших объемов данных и построения приложений с высокой производительностью. Примеры популярных NoSQL-БД включают MongoDB (ориентированная на документы), Cassandra (колоночная), Redis (ключ/значение) и Neo4j (графовая).
Когда использовать SQL-базы данных
Реляционные БД предлагают ряд преимуществ, включая консистентность данных и поддержку транзакций. Эти системы реализуют упомянутый выше принцип ACID. Давайте посмотрим на него подробнее:
- Атомарность (Atomicity). Все операции в транзакции выполняют как единое целое. Применяют либо все изменения, либо ни одно из входивших в операцию.
- Консистентность (Consistency). Транзакция переводит базу данных из одного согласованного состояния в другое. Целостность информации при этом ни в коем случае не нарушают. SQL-базы данных позволяют накладывать ограничения на значения, которые записывают в таблицу и гарантируют их соблюдение до и после транзакции. Например, если какое-то поле объявили как обязательно содержащее значение (NOT NULL), то транзакцию отклонят, если в ней есть инструкция записать NULL в защищенный столбец. Таким же образом проверяют взаимные ссылки между данными.
- Изолированность (Isolation). Одновременные транзакции не влияют друг на друга. Промежуточные результаты одной операции невидимы для других до ее завершения.
- Долговечность (Durability). Если транзакцию завершили, то сохранность ее результата гарантируют. Как и то, что данные не перезапишут, если даже если с оборудованием, на котором работает база данных, возникнут серьезные проблемы, такие, как, например, полная потеря питания или связи с клиентом.
Поэтому SQL-базы данных подходят для задач, где нужна строгая определенность поведения с возможностью контроля целостности и согласованности данных как при их изменении, так и при любых нештатных ситуациях: начиная от подачи неверных данных на вход транзакции и заканчивая техническими проблемами с оборудованием.
Когда использовать NoSQL-базы данных
NoSQL — это базы, которые создавали под развитие разнообразных сервисов: от социальных сетей до IoT и анализа «больших данных». Поэтому их основной чертой стала возможность быстро обрабатывать большие объемы слабо структурированных данных. NoSQL-базы данных можно использовать, когда нужна высокая масштабируемость, гибкость схемы и производительность. Причем производительность можно рассматривать двух видов: скорость вставки новых данных или быстроту поиска и доставки тех, что уже сохранены.
Например, в социальной сети вам надо гораздо чаще показывать контент, чем сохранять его, поэтому вам нужна БД, которая умеет быстро обслуживать запросы на чтение. А вот в условной системе мониторинга устройств интернета вещей (IoT) гораздо чаще происходит вставка похожих по структуре сведений, чем их доставка пользователю или аналитику. Поэтому для полной реализации потенциала NoSQL-базы данных нужно делать выбор под конкретную задачу.
Например, в MongoDB может подойти для хранения информации о товарах в онлайн-магазине. Дело в том, что категории товаров постоянно появляются и исчезают, как и их параметры. Хранить их в жесткой структуре реляционных СУБД не очень удобно, зато полуструктурированные JSON-подобные документы MongoDB в этой ситуации работают хорошо.
Производительность и масштабируемость
SQL и NoSQL-базы данных решают проблему работы в условиях высоких нагрузок разными подходами.
Первые традиционно фокусируются на технике вертикальной масштабируемости. Это означает рост производительности за счет добавления вычислительных ресурсов одного сервера, таких как процессорная мощность, память и дисковое пространство.
Этот метод позволяет улучшить производительность без изменения архитектуры системы, но у него есть свои пределы. И в них разработчики быстро упираются, поскольку в какой-то момент добавление ресурсов не только перестает приносить значительные улучшения, но еще и становится несоразмерно эффекту, который получают. Поэтому для работы в условиях высоких нагрузок SQL-базы данных применяют любые доступные им средства, такие как оптимизация запросов, индексация и кэширование.
Иногда используют шардирование — разделение базы данных на более мелкие части (шарды). Это позволяет распределить нагрузку между несколькими серверами, увеличить производительность и масштабируемость. Репликация данных также играет важную роль, создает копии БД на разных серверах для распределения нагрузки на чтение и обеспечения высокой доступности.
NoSQL-базы данных, в свою очередь, были разработаны с ориентацией в первую очередь на горизонтальное масштабирование. Это означает, что вместо наращивания ресурсов основного сервера в кластер просто добавляют дополнительные узлы. Такой подход позволяет добавлять оптимальные по соотношению стоимость/производительность сервера и тем самым повышать одновременно и емкость, и производительность, и надежность всей системы. Разделение данных (шардирование) в NoSQL-БД распределяет информацию по множеству узлов, помогает обрабатывать запросы параллельно и снижает нагрузку на каждый отдельный сервер. Кроме того, для повышения производительности могут использовать репликацию.
Консистентность, доступность и устойчивость к разделению (CAP-теорема)
CAP-теорему сформулировал Эрик Брюэр в 2000 году и формально доказали Сет Гилберт и Нэнси Линч в 2002 году. Согласно ей, в распределенной системе невозможно одновременно обеспечить три свойства: консистентность (Consistency), доступность (Availability) и устойчивость к разделению (Partition Tolerance). Это означает, что при проектировании распределенной базы данных надо делать выбор в пользу двух из этих свойств и жертвовать третьим.
Консистентность значит, что у всех узлов системы всегда одинаковые данные. Доступность подразумевает, что система всегда отвечает на запросы, даже если некоторые узлы не работают. Устойчивость к разделению — что система продолжает функционировать, даже если некоторые узлы потеряли связь между собой.
SQL-базы данных, такие как MySQL и PostgreSQL, традиционно концентрируются на консистентности и устойчивости к разделению. Они обеспечивают строгую целостность информации, следуют принципам ACID. В условиях высоких нагрузок и сетевых сбоев такие системы могут жертвовать доступностью ради поддержания консистентности.
NoSQL-базы данных, с другой стороны, создавались под задачи, которые традиционные SQL-системы решают хуже, поэтому в зависимости от реализации и цели своего создания выбирают разные комбинации свойств CAP-теоремы. Например, Cassandra и DynamoDB ориентируются на доступность и устойчивость к разделению. Но это означает, что в короткие периоды данные между серверами, которые обслуживают запросы, могут различаться. Это неприемлем, например, для финансовых приложений, но для социальных сетей и IoT это в целом некритичная проблема. MongoDB, ориентированная на документы база данных, предлагает гибкость в выборе между консистентностью и доступностью. Она позволяет настраивать уровни консистентности в зависимости от требований приложения, что делает ее более универсальной для различных типов нагрузок и сценариев использования.
Гибкость схемы и моделирование данных
В этом главная разница между SQL и NoSQL-базами данных. В отличие от SQL-БД, где структура жестко определена, NoSQL позволяют хранить информацию в полуструктурированном (определенном по формату, но не по фактической структуре) виде. Например, MongoDB может в одной коллекции содержать совершенно разные документы, интерпретация сведений в которых ложится на сервисы бизнес-логики. Это особенно полезно в случаях, когда данные могут изменять со временем.
Например, с развитием товаров меняют их свойства, одни теряют свою актуальность, другие выходят на первый план, и онлайн-ритейлеру будет не очень просто хранить это все в традиционной SQL-структуре. Также жесткость SQL-схем замедляет разработку новых продуктов, для которых требования еще до конца не определили. Гораздо проще взять неструктурированную БД и дать возможность времени выковать нужную схему, чтобы, например, при необходимости позже ее на этапе масштабирования переложить в SQL-базу данных.
По мере развития проекта появляется и потребность обновлять структуру базы данных. При накоплении существенных объемов информации модификация БД становится не только затратной по времени операцией, которая снижает на период ее проведения доступность базы. Она еще и может быть сложной с точки зрения тестирования.
В NoSQL-базах данных изменение схемы обычно происходит проще и быстрее. Например, в MongoDB добавление нового поля в документ можно сделать без изменения структуры других документов в коллекции.
Это позволяет разработчикам быстрее адаптироваться к изменяющимся требованиям бизнеса и снижает риски, которые связаны с миграцией данных. Но это же в какой-то момент становится проблемой. Неаккуратное обновление NoSQL-базы данных опасно возникновением хаоса и трудно отлавливаемых ошибок в поведении сервиса, которое связано с неожиданным содержимым документов.
Безопасность и управление данными
И у SQL, и NoSQL-баз данных существуют свои подходы к обеспечению безопасности, управлению доступом и шифрованию информации.
SQL-БД, такие как MySQL и PostgreSQL, традиционно предлагают более развитые механизмы. Они включают в себя аутентификацию пользователей, контроль доступа на уровне строк и столбцов, а также встроенные функции для шифрования данных. Эти механизмы помогают гарантировать, что только авторизованные клиенты могут получать допуск к информации и изменять ее.
NoSQL-базы данных, такие как MongoDB и Cassandra, также предлагают множество возможностей для обеспечения безопасности, но их подходы могут варьировать в зависимости от типа БД. Некоторые NoSQL-системы изначально не проектировали с учетом строгих требований безопасности, но со временем в них внедрили нужные механизмы. Например, современные версии MongoDB включают поддержку аутентификации, шифрования и контроля доступа на основе ролей.
Управление доступом в SQL-базах данных осуществляют через системы ролей и привилегий. Администраторы могут задавать детальные права допуска для пользователей и групп, определяют, кто может читать, изменять или удалять информацию.
В NoSQL-базах данных управление доступом также присутствует, но его реализация может быть менее гранулярной. Например, в MongoDB администраторы могут создавать роли и назначать их пользователям, определять, какие операции те могут выполнять. В Cassandra контроль доступа осуществляют через роли и разрешения, что позволяет управлять допуском к ключевым пространствам и таблицам.
Шифрование данных — еще один важный элемент обеспечения безопасности. В SQL-базах данных сведения могут шифровать как на уровне хранения (на диске), так и отдельных полей и столбцов. Это защищает информацию от несанкционированного доступа в случае компрометации БД или серверов.
NoSQL-базы данных также используют шифрование. Например, MongoDB предлагает его только на уровне хранения и передачи, но не на уровне коллекций и документов.
В целом и для SQL, и для NoSQL-баз данных стоит соблюдать универсальные правила цифровой гигиены:
- проектировать архитектуру безопасности БД, ограничивать права доступа для ролей и пользователей в соответствии с их задачами;
- регулярно просматривать отчеты об уязвимостях и обновлять программное обеспечение;
- применять сильные пароли;
- использовать шифрование данных как для информации в покое, так и в передаче;
- настроить регулярное и безопасное резервное копирование.
Соблюдение этих правил существенно поможет обезопасить информацию в компании.
Стоимость внедрения и эксплуатации
Затраты на использование той или иной базы данных складываются из стоимости:
- лицензий;
- поддержки;
- разработки под конкретную технологию (считаем как время, помноженное на стоимость специалистов по БД);
- оборудования;
- внедрения;
- поддержания инфраструктуры.
Все эти параметры трудно спланировать и просчитать наперед. Однако можно опираться на следующие тезисы:
хранение данных
В целом масштабы затрат намогут значительно различаться. Для некоторых проектов обязательно применение сертифицированных программ, которые в принципе бесплатными не бывают, — и нагрузка, которую создают ваши пользователи. И стоимость управления данными владения сервисомварьируется в очень широком диапазоне, начиная с условного нуля, когда вы пользуетесь бесплатной версией и делаете все сами, до сотен миллионов рублей, когда нужно приобретение лицензий и услуг внедрения/разработки под сервис с высокой нагрузкой.
Заключение
Согласно CAP-теореме невозможно создать базу данных, которая обеспечивает все три свойства одновременно: согласованность данных, устойчивость к разделению и доступность. Поэтому для выбора именно вашей базы данных нужно представлять себе цель и задачи обработки информации, потребности по производительности, уровень подготовки ваших специалистов или бюджетные ограничения для найма сотрудников с рынка, а также требования по уровню безопасности. Более того, если ваш проект только стартует, вы можете выбрать сначала одну систему, ту, на которой вам по каким-то причинам проще и удобнее начинать, и позже ее сменить.
Так или иначе, для выбора надо выписать важные критерии, по которым отличаются базы, отранжировать и попытаться свести их к двум цифрам: стоимости старта и последующего управления вашей системой хранения данных.