Некоторые ключевые характеристики баз данных NqSQL:
- Они распределены, могут масштабироваться по горизонтали и могут обрабатывать объемы данных порядка нескольких терабайт или петабайт с низкой задержкой.
- Они имеют менее жесткие схемы, чем традиционные СУБД.
- Они имеют более слабые транзакционные гарантии.
- Как следует из названия, эти базы данных не поддерживают SQL.
- Многие базы данных NoSQL моделируют данные как строки с семействами столбцов, парами значений ключей или документами.
Чтобы понять, что означает нереляционный, было бы полезно вспомнить, что означает реляционный.
Теоретически, реляционные базы данных соответствуют правилам реляционной модели Codds 12. Проще говоря, в СУБД таблица является отношением, а база данных имеет набор таких отношений. В таблице есть строки и столбцы. Каждая таблица имеет ограничения, и база данных обеспечивает ограничения для обеспечения целостности данных. Каждая строка в таблице идентифицируется первичным ключом, а таблицы связаны с использованием внешних ключей. Вы удаляете дубликаты данных в процессе нормализации, перемещая столбцы в отдельные таблицы, но сохраняя связь, используя внешние ключи. Чтобы получить данные из нескольких таблиц, требуется объединение таблиц с использованием внешних ключей. Эта реляционная модель была полезна для моделирования большинства реальных проблем и широко используется в течение последних 20 лет.
Кроме того, поставщики РСУБД приложили большие усилия, чтобы убедиться, что РСУБД отлично справляются с задачей поддержания ACID-свойств (действительных, согласованных, целостных, долговечных) транзакций для хранимых данных. Восстановление поддерживается после непредвиденных сбоев. Это привело к тому, что реляционные базы данных стали стандартом де-факто для хранения корпоративных данных.
Если РСУБД настолько хороши, зачем кому-то нужны базы данных NoSQL?
Даже самые крупные предприятия имеют пользователей только в порядке тысяч, а требования к данным — в несколько террабайт. Но когда ваше приложение находится в Интернете, где вы имеете дело с миллионами пользователей и данными в порядке петабайт, с RDBMS все начинает замедляться. Основные операции с любой базой данных — чтение и запись. Чтения можно масштабировать путем репликации данных на несколько машин и балансировки запросов на чтение. Однако это не работает для записей, потому что необходимо поддерживать согласованность данных. Записи могут быть масштабированы только путем разделения данных. Но это влияет на чтение, поскольку распределенные объединения могут быть медленными и сложными для реализации. Кроме того, для поддержки свойств ACID базы данных должны блокировать данные за счет производительности.
Googles, facebooks, Twitters обнаружили, что ослабление ограничений СУБД и распространение данных дает им лучшую производительность для случаев использования, которые включают
- Большие наборы данных порядка петабайт. Как правило, это необходимо хранить с использованием нескольких машин.
- Приложение делает много записей.
- Чтение требует низкой задержки.
- Данные полуструктурированы.
- Вы должны иметь возможность масштабировать, не попадая в узкое место.
- Приложение знает, что оно ищет. Adhoc запросы не требуются.
Каковы решения NoSQL там?
Есть несколько разных типов.
1. Ключевые магазины стоимости
Они позволяют клиентам читать и записывать значения, используя ключ. Динамо Амазонки — пример магазина значения ключа.
get (key) возвращает объект или список объектов
put (ключ, объект) сохранить объект как BLOB-объект
Динамо использует хеширование для разделения данных между хостами, которые хранят данные. Для обеспечения высокой доступности каждая запись реплицируется на несколько хостов. Хозяева равны и нет хозяина. Преимущество Dynamo состоит в том, что модель ключ-значение проста и доступна для записи.
2. Хранение документов
Пары ключ-значение, составляющие данные, инкапсулируются как документ. Apache CouchDB является примером хранилища документов. В CouchDB документы имеют поля. Каждое поле имеет ключ и значение. Документ может быть
|
1
2
3
4
|
"firstname " : " John ","lastname " : "Doe" ,"street " : "1 main st","city " : "New york" |
В CouchDB распределение и репликация одноранговые. Клиентский интерфейс — это RESTful HTTP, который хорошо интегрируется с существующими решениями балансировки нагрузки HTTP.
3. Колонка на основе магазинов
Чтение и запись выполняются с использованием столбцов, а не строк. Наиболее известные примеры — BigTable от Google и HBase и Cassandra, вдохновленные BigTable. В документе BigTable говорится, что BigTable — это разреженная, распределенная, постоянная, многомерная отсортированная Карта. Хотя это предложение кажется сложным, чтение каждого слова в отдельности дает ясность.
- разреженный — некоторые клетки могут быть пустыми
- распределен — данные распределены по многим хостам
- постоянный — сохраняется на диск
- многомерный — более одного измерения
- Карта — ключ и значение
- отсортировано — карты обычно не отсортированы, но этот
Этот пример может помочь вам визуализировать карту BigTable
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
{row1:{ user:{ name: john id : 123 }, post: { title:This is a post text : xyxyxyxx }}row2:{ user:{ name: joe id : 124 }, post: { title:This is a post text : xyxyxyxx }}row3:{ user:{ name: jill id : 125 }, post: { title:This is a post text : xyxyxyxx }}} |
Внешние клавиши row1, row2, row3 являются аналогами строк. user и post — это так называемые семейства столбцов. Пользователь семейства столбцов имеет имя и идентификатор столбца. сообщение имеет столбцы заголовок и текст.
Columnfamily: column — это то, как вы ссылаетесь на столбец. Например, user: id или post: text. В Hbase при создании таблицы необходимо указывать семейства столбцов. Но столбцы могут быть добавлены на лету. HBase обеспечивает высокую доступность и масштабируемость, используя архитектуру master-slave.
Нужно ли мне магазин NoSQL?
Вам не нужно хранилище NoSQL, если
- Все ваши данные помещаются на 1 машину и не должны быть разделены.
- Вы выполняете OLTP, который требует свойств транзакции ACID и согласованности данных, которые хороши для СУБД.
- Вам нужны специальные запросы с использованием языка, такого как SQL.
- У вас сложные отношения между сущностями в ваших приложениях.
- Выделение данных из приложения важно для вас.
Вы можете начать рассматривать магазины NoSQL, если
- Ваши данные стали настолько большими, что они больше не могут обрабатываться без разделения.
- Ваша СУБД больше не может справляться с нагрузкой.
- Вам нужна очень высокая производительность записи и минимальное время чтения.
- Ваши данные не очень структурированы.
- У вас не может быть единой точки отказа.
- Вы можете терпеть некоторые несоответствия данных.
Суть в том, что магазины NoSql — это новая и сложная технология. Есть много вариантов и нет стандартов. Существуют конкретные варианты использования, для которых NoSql хорошо подходит. Но RDBMS отлично подходит для большинства случаев использования ванили.
Справка: что такое NoSQL? от нашего партнера по JCG Маноджа Хангаонкара из отчета Хангаонкар .