Базы данных

Опредение БД

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

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

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

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

Совокупность данных, хранимых под управлением СУБД, называется базой данных. Оригинальное английское словосочетание data base дословно переводится как «основание, состоящее из данных». В русском словосочетании «база данных» этот смысл несколько искажается. На самом деле это — фундамент, на котором строятся приложения и который состоит из данных. Действительно, данные (а следовательно, база данных) являются очень существенной частью практически любой информационной системы.

Схема БД

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

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

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

Схема - это стуктура данных

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

Типы БД

Реляционные БД (SQL)

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

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

Таблицы в реляционных БД связанны между собой определенными отношениями.

Данные в реляционной БД должны быть нормализированны.

Для обращения к данным используется специальный язык запросов - SQL

Примеры:

mysql
postgresql

Документо-ориентированные БД

Представляют собой тип баз данных, организованный вокруг хранения и обработки документов, таких как JSON или BSON (бинарная форма JSON). Этот тип баз данных хорошо подходит для хранения и обработки структурированных и неструктурированных данных, таких как текстовые документы, JSON-объекты, XML-данные и др. Хотя ни XML, ни JSON не предполагалось использовать для хранения данных, оба этих формата можно рассматривать как модели данных.

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

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

Примеры:

MongoDB - одна из самых известных документо-ориентированных баз данных. Она использует формат JSON-подобных документов для хранения данных. MongoDB предлагает масштабируемость и гибкость в модели данных, поддерживая различные типы запросов и индексацию.
Couchbase - распределенная база данных с открытым исходным кодом, которая также использует JSON для представления данных. Она обеспечивает высокую производительность, масштабируемость и доступность, поддерживая как кэширование, так и хранение данных.
Amazon DynamoDB - это управляемая NoSQL база данных от Amazon Web Services (AWS). Она предлагает гибкую модель данных и масштабируемость, поддерживая как документо-ориентированные данные, так и ключ-значение

Key-Value DB

Базы данных типа "ключ-значение" , представляют собой простую структуру данных, где каждая запись идентифицируется уникальным ключом и связана с соответствующим значением. Значение может быть любым: например, строкой, документом или картинкой. Хранилище сохраняет значение в двоичном виде, ничего не знает о его структуре и не контролирует его тип. Чтобы получить значение, нужно обязательно знать ключ; выборки значения по каким-либо другим параметрам не поддерживаются. Соответственно, такие системы используются, когда нужен доступ по (единственному) ключу, а другие виды поиска и взаимосвязи между объектами не требуются. Эти базы данных широко используются для различных сценариев, таких как кеширование, управление сессиями, хранение настроек и других приложений, где необходима эффективная работа с парами ключ-значение.

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

Примеры:

Redis: Открытая и высокопроизводительная база данных в памяти, которая поддерживает различные структуры данных, включая строки, списки, хеш-таблицы и другие.
Memcached: Быстрая и простая в использовании система кэширования в памяти, которая также может использоваться в качестве базы данных ключ-значение.
Etcd: Распределенное хранилище конфигураций и служб для обеспечения согласованности данных в распределенных системах.

Колоночно-ориентированные БД

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

Данные хранятся по столбцам, а не по строкам. Каждый столбец содержит значения одного типа данных для всех записей.
Колоночно-ориентированные базы данных оптимизированы для операций агрегации, фильтрации и других аналитических задач.
Поскольку значения в каждом столбце обычно подчиняются одному типу данных, это позволяет применять эффективные методы сжатия, что уменьшает объем хранимых данных.
Колоночные базы данных часто используются для задач онлайн-аналитической обработки (OLAP), таких как формирование отчетов и анализ данных.

Примеры:

Apache Cassandra - это распределенная база данных с открытым исходным кодом, разработанная для обработки огромных объемов данных и обеспечения высокой доступности и отказоустойчивости. Она хранит данные в виде колонок, что обеспечивает быструю и эффективную обработку запросов на чтение и запись.
ClickHouse - это колоночно-ориентированная база данных с открытым исходным кодом, разработанная для аналитических задач и обработки больших объемов данных. Она обеспечивает высокую производительность при выполнении запросов на агрегацию и аналитику, что делает ее популярным выбором для OLAP (Online Analytical Processing).

Иерархические БД

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

Примеры:

Файловая система, хранит данные в виде иерархии
Реестр Windows устроен иерархически

Сетевые БД

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

CAP-теорема

CAP-теорема - это теорема, которая описывает ограничения в проектировании распределенных систем. Теорема была предложена Эриком Брюэром (Eric Brewer) в 2000 году. CAP представляет собой акроним для трех основных характеристик, которые могут существовать одновременно в распределенной системе: Consistency (Согласованность), Availability (Доступность) и Partition tolerance (Устойчивость к разделению).

Consistency (Согласованность): Все узлы в распределенной системе видят одни и те же данные одновременно. Согласованность означает, что при чтении данных из системы вы получите самые последние изменения. Во всех вычислительных узлах в один момент времени данные не противоречат друг другу
Availability (Доступность): Каждый запрос к системе завершается успешно без ошибок. Доступность означает, что система готова к обработке запросов клиентов. Любой запрос к распределённой системе завершается корректным откликом, однако без гарантии, что ответы всех узлов системы совпадают.
Partition Tolerance (Устойчивость к разделению): Система продолжает функционировать даже в случае разделения (потери связи) между узлами. Устойчивость к разделению означает, что система может продолжать работу, даже если часть узлов не может обмениваться данными.

Сформулированное утверждение CAP-теоремы: "В распределенной системе можно обеспечить любые две из трех характеристик CAP: Consistency, Availability, Partition Tolerance. Однако невозможно обеспечить все три одновременно." То есть, при разделении сети (Partition Tolerance), распределенная система должна выбрать между согласованностью (Consistency) и доступностью (Availability).

Иллюстрация CAP-теоремы:

CA системы (Consistency, Availability): Традиционные реляционные базы данных, где высокая согласованность и доступность важны, но устойчивость к разделению может быть ограниченной.
CP системы (Consistency, Partition Tolerance): Некоторые NoSQL базы данных, где согласованность важнее доступности в условиях разделения.
AP системы (Availability, Partition Tolerance): Распределенные хранилища, где важна доступность в условиях разделения, и согласованность может быть жертвована.

Примеры систем, соответствующих разным моделям:

CA: Традиционные реляционные базы данных (например, MySQL с репликацией без разделения).
CP: MongoDB, Apache HBase.
AP: Couchbase, Amazon DynamoDB.

Ещё о CAP теореме

PACELC-теорема

PACELC-теорема - это расширение CAP-теоремы, предложенное Дэниэлом Абрамсом (Daniel Abadi) в 2010 году. PACELC представляет собой акроним, описывающий шесть возможных состояний распределенной системы: Partition tolerance (Устойчивость к разделению), Availability (Доступность), Consistency (Согласованность), Else (В противном случае), Low latency (Низкая задержка), and High throughput (Высокая пропускная способность).

Определения PACELC-теоремы:

Partition tolerance (Устойчивость к разделению): Это аналогично части P в CAP-теореме. Указывает на то, что система продолжает функционировать, даже если часть сети разделена.
Availability (Доступность): Это аналогично части A в CAP-теореме. Указывает на то, что система должна быть доступна для обработки запросов.
Consistency (Согласованность): Это аналогично части C в CAP-теореме. Указывает на необходимость согласованности данных в распределенной системе.
Else (В противном случае): Это дополнительная часть PACELC, которая представляет собой компромисс между C (Consistency) и A (Availability). В противном случае система может выбрать опцию, которая не является строго согласованной или не доступной.
Low latency (Низкая задержка): Указывает на необходимость минимизации задержек при обработке запросов.
High throughput (Высокая пропускная способность): Указывает на необходимость обеспечения высокой пропускной способности системы.

Варианты состояний PACELC:

P/A (Устойчивость к разделению / Доступность): Система устойчива к разделению, и доступность имеет более высокий приоритет, чем согласованность.
P/C (Устойчивость к разделению / Согласованность): Система устойчива к разделению, и согласованность имеет более высокий приоритет, чем доступность.
P/EL (Устойчивость к разделению / В противном случае и Низкая задержка): Система устойчива к разделению, и в противном случае она может выбрать компромисс между согласованностью и доступностью, с минимизацией задержек.
P/EC (Устойчивость к разделению / В противном случае и Согласованность): Система устойчива к разделению, и в противном случае она может выбрать компромисс между согласованностью и доступностью, с более высоким приоритетом согласованности.

ACID / BASE

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

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

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

Atomicity (Атомарность): Операции в базе данных должны быть атомарными, то есть они должны выполняться целиком или вообще не выполняться. Если одна часть транзакции не удается, то вся транзакция откатывается (отменяется), и база данных остается в непротиворечивом состоянии.
Consistency (Согласованность): Транзакция должна переводить базу данных из одного согласованного состояния в другое. Это гарантирует, что база данных не останется в некотором непротиворечивом состоянии после завершения транзакции.
Isolation (Изолированность): Каждая транзакция должна выполняться изолированно от других транзакций. Это означает, что изменения, внесенные одной транзакцией, не видны другим транзакциям до тех пор, пока первая не завершится.
Durability (Устойчивость): После успешного завершения транзакции ее результаты должны быть устойчивыми и сохраняться даже в случае сбоя системы. Данные, сохраненные в базе данных, должны быть постоянными.

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

BASE - это альтернативный набор принципов для проектирования и обслуживания распределенных систем, в отличие от традиционных ACID-свойств.

Термин BASE является акронимом, представляющим собой следующие основные принципы:

Basically Available (Основная доступность): Система всегда должна быть доступной для выполнения запросов, даже в условиях сбоев. Это означает, что система может возвращать частичные или устаревшие результаты вместо отказа в обслуживании. Деградация части узлов ведет к деградации части сессий, исключая полную деградацию системы. Система отвечает на любой запрос, но в ответе могут быть неверные данные.
Soft state (Мягкое состояние): Состояние системы может меняться с течением времени даже без внешних воздействий. Это означает, что система может временно нарушать согласованность данных, но с течением времени снова приходит в согласованное состояние.
Eventually consistent (В конечном итоге согласованность): Система в конечном итоге приходит в согласованное состояние после выполнения всех операций и обработки всех асинхронных обновлений. Это допускает временные задержки в согласованности данных в распределенной системе.

Могут ли в одной системе сочетаться принципы BASE и ACID?

Реализация любой распределенной БД - это всегда компромис между ACID и BASE. Полностью изолированные транзакции можно реализовать только в ACID-базе, но в распределенной среде такая БД не будет обладать свойством базовой доступности, присущей BASE-системам. Многие NoSQL БД отказываются от гарантии изоляции и предлагают «согласованность в конечном счёте» (eventual consistency), согласно которой мы в конце концов увидим действительные данные, но есть вероятность, что наш запрос прочитает недействительные значения – то есть, временные, или частично обновлённые, или устаревшие. Так же в BASE-системах сложно реализовать свойство полноценной стойкости (durability), поскольку для увеличения скорости многие BASE-СУБД осуществляют операции с данными в оперативной памяти и сбрасывают конечные состояния на диск с определенной переодичностью. Если говорить категорично, то принципы ACID противоречать BASE-подходу и любая система, реализующая "базовую доступность" в распределенной среде, не сможет гарантировать строгую изоляцию и согласованность каждой проводимой пользователем транзакции.