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

При выборе базы данных для хранения и уточнения данных не спрашивайте себя «Могу ли я использовать это?», а скорее «Должен ли я?”

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

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

1- Относительный

Системы управления реляционными базами данных (RDBMS) — флагманский пример, который большинство людей представляет себе, рассматривая типы баз данных.

СУРБД используют двумерную таблицу из столбцов и строк для представления атрибутов и объекты соответственно.

Простой способ запомнить их (которые я до сих пор иногда путаю) — думать о колонке как о «лазании», а о строке как о «гребле (горизонтально по воде).

Теория множеств

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

Набор — это набор из нуля или более различных объектов:

{1,2,3}, {кошка, собака, 6}, {}

{1,2,3} == {1,3,2} —порядок не имеет значения. Эти наборы одинаковые. Только элементы множества являются его отличительными факторами.

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

Некоторые реляционные базы данных с открытым исходным кодом: PostgreSQL*, MySQL, SQLite, H2

2-ключ-значение

Хранилище «ключ-значение» (KV) — это простейшая модель, которую я рассмотрю, и описывает сравнительные отношения пар, как в хэше (указатель => цель). ключ — это указатель на значение, подобно тому как путь к файлу — это ключ к содержимому файла (значению). KV могут предоставлять более сложные типы значений, такие как хэши или списки, но это не обязательно.

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

Существует также большое количество вариантов базы данных KV с открытым исходным кодом. Самые популярные варианты включают memcached, Redis, Voldemort и Riak.

3- столбчатый

Прости.. но я чуть не солгал тебе.

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

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

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

/Кроличья нора

Столбчатая из баз данных, ориентированных на столбцы, названа так из-за того, что они предназначены для совместного хранения данных из заданного столбца. СУРБД ориентированы на строки и, напротив, хранят информацию из строк вместе:

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

Три наиболее распространенные СУБД со столбцами – HBase, Cassandra и Hypertable – менее конкурентоспособны, чем хранилища, ориентированные на строки и хранилища типа "ключ-значение".

БД, ориентированные на столбцы, и БД, ориентированные на строки

Реляционный — ориентированный на строки

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

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

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

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

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

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

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

Столбчатый — ориентированный на столбцы

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

4- Документ

Я дам вам догадаться, какие типы объектов хранятся в документно-ориентированных базах данных.

По сути, документ подобен хэшу с полем уникального идентификатора (uID) и значениями, которые могут быть любого типа, включая дополнительные хэши.

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

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

Ключевое (ha) различие между базами данных, ориентированными на документы, и хранилищами "ключ-значение" заключается в способе обработки данных.

KV — в хранилище пар "ключ-значение" данные считаются непрозрачными для базы данных.

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

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

Двумя основными игроками на рынке баз данных документов являются MongoDB и CloudDB.

5- График

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

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

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

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

Neo4J — самая популярная база данных графов на сегодняшний день, но вы также можете рассмотреть FlockFB, AllegroGraph, InfiniteGraph и GraphDB

Полиглот

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

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

Следующий раздел будет (теоретически) намного короче и обсуждает теорему CAP.