На какие части разделяется sql

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

SQL основывается на реляционной алгебре.

Язык SQL делится на четыре части:

* операторы определения данных (Data Definition Language, DDL);

* операторы манипуляции данными (Data Manipulation Language, DML);

* операторы определения доступа к данным (Data Control Language, DCL);

* операторы управления транзакциями (Transaction Control Language, TCL).

Независимость от конкретной СУБД

Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально закладывались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle, так и с Microsoft SQL Server и IBM DB2). Естественно, что при применении некоторых специфичных для реализации возможностей такой переносимости добиться уже очень трудно. Наличие стандартов

Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка. Правда, стоит обратить внимание, что сам по себе стандарт местами чересчур формализован и раздут в размерах, например, Core-часть стандарта SQL:2003 представляет собой более 1300 страниц текста. Декларативность

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

Приложение D. Соответствие стандарту SQL

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

Формально стандарт SQL называется ISO/IEC 9075 «Язык баз данных SQL» . Время от времени выпускается обновлённая версия стандарта; последняя версия стандарта вышла в 2011 г. Эта версия получила обозначение ISO/IEC 9075:2011, или просто SQL:2011. До этого были выпущены версии SQL:2008, SQL:2003, SQL:1999 и SQL-92. Каждая следующая версия заменяет предыдущую, так что утверждение о совместимости с предыдущими версиями не имеет большой ценности. Разработчики PostgreSQL стремятся обеспечить совместимость с последней официальной версией стандарта, оставаясь при этом в рамках традиционной функциональности и здравого смысла. PostgreSQL реализует большую часть требуемой стандартом функциональности, хотя иногда с немного другими функциями или синтаксисом. Можно ожидать, что со временем степень совместимости будет увеличиваться.

SQL-92 определяет три уровня функциональной совместимости: начальный (Entry), промежуточный (Intermediate) и полный (Full). Большинство СУБД заявляют о совместимости со стандартом SQL только на начальном уровне, так как полный набор возможностей на промежуточном и полном уровнях либо слишком велик, либо конфликтует с ранее принятым поведением.

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

Описание стандарта, начиная с версии SQL:2003 , также разделяется на несколько частей. Каждая такая часть имеет короткое имя и номер. Заметьте, что нумерация этих частей непоследовательная.

ISO/IEC 9075-1 Структура (SQL/Framework)

ISO/IEC 9075-2 Основа (SQL/Foundation)

ISO/IEC 9075-3 Интерфейс уровня вызовов (SQL/CLI)

ISO/IEC 9075-4 Модули постоянного хранения (SQL/PSM)

ISO/IEC 9075-9 Управление внешними данными (SQL/MED)

ISO/IEC 9075-10 Привязки объектных языков (SQL/OLB)

ISO/IEC 9075-11 Схемы информации и определений (SQL/Schemata)

ISO/IEC 9075-13 Программы и типы, использующие язык Java (SQL/JRT)

Ядро PostgreSQL реализует части 1, 2, 9, 11 и 14. Часть 3 реализуется драйвером ODBC, а часть 13 — подключаемым расширением PL/Java, но точное соответствие этих компонентов стандарту на данный момент не проверено. Части 4 и 10 в PostgreSQL в настоящее время не реализованы.

PostgreSQL поддерживает почти все основные возможности стандарта SQL:2011. Из 179 обязательных возможностей, которые требуются для полного соответствия «Основной» функциональности, PostgreSQL обеспечивает совместимость как минимум для 160. Кроме того, он реализует длинный список необязательных возможностей. Следует отметить, что на время написания этой документации ни одна существующая СУБД не заявила о полном соответствии «Основной» функциональности SQL:2011.

В следующих двух разделах мы представляем список возможностей, которые поддерживает PostgreSQL , и список возможностей, определённых в SQL:2011 , которые ещё не поддерживаются в PostgreSQL . Оба эти списка носят приблизительный характер: какая-то возможность, отмеченная как поддерживаемая, может отличаться от стандарта в деталях, и напротив, для какой-то неподдерживаемой возможности могут быть реализованы ключевые компоненты. Наиболее точная информация о том, что работает, а что нет, содержится в основной документации.

Замечание: Коды возможностей, содержащие знак минус, обозначают подчинённые возможности. При этом, если какая-либо одна подчинённая возможность не поддерживается, основная возможность так же не будет поддерживаться, даже если реализованы все остальные на подуровне.

Пред.	Начало	След.
Ключевые слова SQL	Уровень выше	Поддерживаемые возможности

SQL-Ex blog

Изменения языка T-SQL в SQL Server 2022: часть 3

Добавил Sergey Moiseenko on Среда, 19 апреля. 2023

В первой статье рассматривались DISTINCT FROM, DATE_BUCKET, GENERATE_SERIES, GREATEST/LEAST, STRING_SPLIT, and DATETRUNC. В второй — APPROX_PERCENTILE_CONT, APPROX_PERCENTILE_DISC, функции побитовых операций, а также изменения в FIRST_VALUE, LAST_VALUE и LTRIM/RTRIM/TRIM. В этой статье рассматриваются возможности JSON.

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

Возможности JSON

JSON_PATH_EXISTS()
JSON_OBJECT()
JSON_ARRAY()

JSON_OBJECT()

Функция JSON_OBJECT() является новой для SQL Server 2022 и предназначена для конструирования текста объекта JSON из нуля или большего числа выражений. Существенно то, что эта функция построит валидный документ JSON с внешними фигурными скобками и различными парами ключ-значение внутри. Вместо использования конкатенации строк для сборки документа JSON, вы можете с помощью этой функции собрать вместе предоставленный список пар ключ-значение.

Эта функция принимает произвольное число аргументов. Каждый из этих аргументов представлен как пара с выражениями ключа в форме «строка1 : строка2». Каждые две строки или переменных разделяются двоеточием. Затем каждая пара аргументов разделяется запятой. Это подразумевает, что значение единственного ключа должно передаваться таким образом:

select JSON_OBJECT(@s1 : @s2)

Если требуется передать две пары вместе, то используется такая конструкция:

select JSON_OBJECT(@s1 : @s2, @s3 : @s4)

Последующие пары должны следовать тому же формату, используя запятую и две строки, разделенные двоеточием. Если передать только один аргумент, возвращается ошибка. Я не вижу ограничения на число параметров. Я успешно тестировал до 5000 пар ключ-значение.

NULL ON NULL
ABSENT ON NULL

Эта функция возвращает строку JSON, которая имеет тип NVARCHAR(MAX).

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

Давайте вызовем со скалярными значениями. Я передам две строк, и посмотрим, что получится. Я буду использовать свое имя в качестве значения с ключом «name». Вот код вызова:

select json_object( 'fname' : 'Frank')

Если не заключить в кавычки ключ (или значение), возникнет ошибка, например (fname без кавычек):

Msg 207, Level 16, State 1, Line 1
Invalid column name ‘fname’.
(Недопустимое имя столбца)

Можно использовать также переменные, например:

declare @s1 varchar(100), 
@s2 varchar(100); 
select @s1 = 'fname' 
select @s2 = 'Frank' 
select JSON_OBJECT(@s1:@s2)

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

declare @s1 varchar(100), 
@s2 varchar(100); 
select @s1 = 'name' 
select @s2 = 'Frank' 
selectJSON_OBJECT(@s1:@s2) 
declare @s3 varchar(100), 
@s4 varchar(100); 
select @s3 = 'language' 
select @s4 = 'PowerShell' 
select JSON_OBJECT(@s1 : @s2, @s3 : @s4)

Результат будет таким:

Насколько это полезно? И полезно ли вообще?

Ну, сообщение об ошибке выше дает ключ к тому, как можно это использовать. Функция ожидала столбец, поэтому попробуем это. У меня есть таблица SalesOrders (из предыдущей статьи), которая выглядит так:

Давайте попробуем использовать столбец в этой функции. Я буду использовать сначала SaleDate, так:

select JSON_OBJECT('SaleDate':SaleDate) 
from SalesOrder 
go

Это даст мне следующие значения:

Уже интересно. Я также могу использовать несколько столбцов. Допустим мне нужны SaleID, SaleDate и CustomerID. Можно использовать такой код:

select JSON_OBJECT('SaleID' : SaleID ,'SaleDate':SaleDate, 'CustomerID': CustomerID) 
from SalesOrder 
go

Это дает мне набор документов:

Интересно то, что я могу использовать также вложенную функцию. Это даст мне более сложный документ. Предположим мне нужен документ с тремя парами ключ-значение: SaleID, CustomerID и OrderDetails. OrderDetails содержит свой собственный документ, который имеет дату, количество и цену. Я могу выполнить такой код:

select JSON_OBJECT('SaleID' : SaleID ,'CustomerID': CustomerID, 'OrderDetails': JSON_OBJECT('SaleDate':SaleDate,'Qty': Qty, 'Price':Price)) 
from SalesOrder 
go

А вот результаты:

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

Но прежде, чем я сделаю это, как насчет предложения NULL? Давайте его протестируем. Я создам новую таблицу с тремя строками, которая выглядит так:

appttime title
———- ———-
Mon 10am Standup
Tue 10am Standup
Fri 4pm NULL

Если мне нужны эти документы, я могу использовать следующий код с предложением NULL ON NULL:

select json_object( 'Appt' : appttime, 'title':title NULL ON NULL) 
from schedule

Если я выберу другой вариант, то увижу следующее (результаты после пунктирной линии):

select json_object( ‘Appt’ : appttime, ‘title’:title ABSENT ON NULL)
from schedule
——

Как видно, я могу либо включить JSON NULL, либо просто отбросить пару ключ-значение.

JSON_ARRAY()

Это еще одна новая функция. JSON_ARRAY() предназначена для конструирования валидного массива JSON из входных параметров. Как и предыдущая функция, она может использовать переменное число аргументов для построения массива. Массив JSON представляет собой набор значений в квадратных скобках, разделенных запятыми. Также имеется необязательное предложение JSON NULL.

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

select JSON_ARRAY() 
--------- 
[]

Если использовать набор значений, они образуют массив:

select json_array(1,2,3,4)

А если использовать столбец с числами. Я выберу его из таблицы dbo.SalesOrder:

select top 5 json_array(CustomerID) 
from SalesOrder 
GO

Результаты не те, что я ожидал:

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

select top 5 json_array(productid, qty,price) 
from SalesOrder 
GO

Результаты более интересны.

[50,1,100.0000]
[51,10,50.0000]
[52,5,10.0000]
[53,10,6.0000]
[54,6,6.0000]

А полезны? Я не уверен. Как узнать, что эти значения в массиве представляют собой? Я подозреваю, что большинство JSON не так чтобы документированы, но это кажется еще хуже, если у нас не содержатся одни и те же по смыслу данные в нескольких столбцах, что было бы нарушением требований нормализации при проектировании. Опять таки, множество баз данных плохо нормализованы. Как разработчику, мне может понравится работать с подобной структурой.

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

with cteString (Customers) 
as 
(SELECT DISTINCT 
STUFF((SELECT 
',' + cast( c2.CustomerID as varchar(10)) as Customers 
FROM 
SalesOrder c2 
FOR XML PATH(''), TYPE).value('.', 'varchar(max)'), 1, 1, '') 
FROM SalesOrder c1 
) 
select json_array(Customers) 
from cteString 
- - - - - 
["1,1,4,6,6,6,7,1,1,1"]

Это неважно работает. Не уверен, что я буду использовать эту функцию, но она может понадобиться вам.

JSON_PATH_EXISTS()

NULL, если передается NULL
1 — путь существует
0 — в противном случае

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

declare @d varchar(max) = ' "book": "isbn":"9781593279509", 
"title":"Eloquent JavaScript, Third Edition", 
"author":"Marijn Haverbeke", 
"website":"http://eloquentjavascript.net/" 
>, 
"magazines": [ 
 "title":"SQL Server Pro", 
"publisher":"Zinio" 
>, 
 "title":"SQL Server Geeks", 
"publisher":"DPS" 
> 
], 
"websites": [ "title":"SQL Server Central", 
"url":"https://www.sqlservercentral.com" 
>, 
 "title":"SQL Blog", 
"URL":"https://sqlblog.org/" 
> 
] 
>'

Путь JSON имеет конкретный формат. Он начинается с $ в качестве корня, а затем точка (период) разделяет имя каждого ключа. Посмотрите примеры:

select JSON_PATH_EXISTS(@d, '$.book') 
-- возвращает 1

Путь — от корня к book, который является первым ключом. Если мне требуется websites, я бы использовал:

select JSON_PATH_EXISTS(@d, '$.websites') 
-- возвращает 1

Если заглянуть под books, то можно увидеть внутри этого ключа другие ключи. Например, isbn является ключом ниже ключа book. Его путем является:

select JSON_PATH_EXISTS(@d, '$.book.isbn') 
-- возвращает 1

Описки имеют значение, включая регистр. Примеры — ниже:

-- оба возвращают 0 
select JSON_PATH_EXISTS(@d, '$.book.isnb') 
select JSON_PATH_EXISTS(@d, '$.book.ISBN')

Как насчет URL веб-сайтов? Я не могу выполнить это.

select JSON_PATH_EXISTS(@d, '$.websites.title') 
-- возвращает 0

На самом деле я могу это сделать. Не возвращает ошибок, помните? Этот запрос возвращает 0, поскольку нет пути от ключа websites к ключу title. Вместо этого мне нужен индекс массива. Индексация в JSON начнается с нуля, поэтому фактическим путем является websites[0].title. Этот код возвращает 1.

select JSON_PATH_EXISTS(@d, '$.websites[0].title') 
-- возвращает 1

Однако и здесь регистр имеет значение. Взгляните на документ. Два адреса в websites имеют различный регистр. Это означает, что следующий код вернет 1 и 0.

select JSON_PATH_EXISTS(@d, '$.websites[0].url'), 
JSON_PATH_EXISTS(@d, '$.websites[1].url') 
-- возвращает 1 и 0

Если я в обоих запросах использую верхний регистр, то получу 0 и 1.

select JSON_PATH_EXISTS(@d, '$.websites[0].URL'), 
JSON_PATH_EXISTS(@d, '$.websites[1].URL') 
-- возвращает 0 и 1

Я проверил проблему с ошибкой, и это неправильно. Следующее вызывает ошибку:

select JSON_PATH_EXISTS(@d, 'dfgdfgfdgd')

В SSMS выводится:

Unexpected character ‘d’ is found at position 0.
(Неожиданный символ ‘d’ обнаружен в позиции 0.)

Если я передам документ NULL, то получу NULL.

declare @d varchar(max) 
select JSON_PATH_EXISTS(@d, '$.book') 
go 
-- возвращает NULL

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

ISJSON()

Функция ISJSON() существовала и до SQL Server 2022, но она была улучшена в этой версии. Теперь мы можем указать тип ожидаемого выражения JSON и проверить, что он имеется. До SQL Server 2022 имелся только один параметр, которым было строковое выражение. Мы имели это в SQL Server 2017 (который часто используется):

DECLARE @d VARCHAR(1000) = ' 
 < "book":1
>' 
SELECT ISJSON(@d) 
-- возвращает 1 
SELECT @d = '"book":1' 
SELECT ISJSON(@d) 
-- возвращает 0

В SQL Server 2022 мы получили необязательный второй параметр, который может принимать одно из четырех значений: VALUE, SCALAR, OBJECT, ARRAY. Каждое из этих значений соответствует типу структуры JSON. Вот их определения (из документации):

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

DECLARE @JSON VARCHAR(1000) = ' 
 < "book":1
>' 
select isjson(@JSON, VALUE) as JSONValue, 
isjson(@JSON, SCALAR) as JSONSCALAR, 
isjson(@JSON, ARRAY) as JSONARRAY, 
isjson(@JSON, OBJECT) as JSONOBJECT 
-- возвращает 
-- JSONValue JSONSCALAR JSONARRAY JSONOBJECT 
-- 1 0 0 0

А что со вторым кодом? Это только ключ и значение. Это не должно быть чем-то. Это невалидный JSON, и не значение или скаляр. Это не массив и не объект, т.к. не имеет скобок.

SELECT @JSON = '"book:1"' 
select isjson(@JSON, VALUE) as JSONValue, 
isjson(@JSON, SCALAR) as JSONSCALAR, 
isjson(@JSON, ARRAY) as JSONARRAY, 
isjson(@JSON, OBJECT) as JSONOBJECT 
-- возвращает 
-- JSONValue JSONSCALAR JSONARRAY JSONOBJECT 
-- 0 0 0 0

Давайте проверим кое-что другое. Я включу значение JSON в качестве первого результата, а затем эти четыре результата. Считайте, что этот код был передан в функцию ISJSON().

Читать:

Как напомнить о себе в телеграмме

Интересный тест, и он сочетает возможность тестирования документа JSON с его фрагментом, например, массивом. Я не считаю эти дополнительные элементы очень ценными, но полагаю полезной возможностью проверить, не является ли нечто объектом JSON или часть строки — массивом. Вам потребовалась бы функция SUBSTRING() для вырезания части массива, но это не так трудно. Утомительно, но не трудно.

Заключение

В этой статье рассматриваются улучшения обработки JSON в T-SQL. Мы обсудили функции JSON_OBJECT() и JSON_ARRAY(), которые возвращают документы JSON на основе входных параметров, функции JSON_PATH_EXISTS() и ISJSON() для тестирования документов JSON или их частей.

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

Ссылки по теме

OPENJSON и CROSS APPLY
JSON_PATH_EXISTS дает вам больше власти над документами JSON в SQL Server
Парсинг данных типа JSON в SQL Server
JSON для SQL Server. Часть 1

Что такое NoSQL?

NoSQL – это технология баз данных, позволяющая хранить данные в гибких схемах, которые легко масштабируются. На протяжении десятилетий доминирующей моделью данных при разработке приложений была реляционная модель данных, в которой данные хранились в таблицах, состоящих из строк и столбцов. Для создания и редактирования этих реляционных таблиц использовался структурированный язык запросов (SQL). Но в середине – конце 2000‑х годов стали широко использоваться и другие гибкие модели данных. Для обозначения появившихся классов баз и моделей данных был введен термин «NoSQL». NoSQL означает «не только SQL» или «не SQL». Часто NoSQL используется в качестве синонима к термину «нереляционный».

В чем преимущества баз данных NoSQL?

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

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

Гибкость

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

Возможности масштабирования

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

Высокая производительность

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

Широкие функциональные возможности

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

Каковы варианты использования баз данных NoSQL?

Вы можете использовать базы данных NoSQL для создания широкого спектра высокопроизводительных мобильных приложений, приложений Интернета вещей (IoT), игр и веб-приложений, которые обеспечивают отличное взаимодействие с пользователем в любом масштабе. Диапазон баз данных NoSQL и варианты их использования очень разнообразны. Хотя представить репрезентативный набор вариантов использования сложно, ниже мы приведем несколько наглядных примеров, которые заставят вас задуматься. Мы призываем вас узнать больше о каждой базе данных NoSQL и соответствующих вариантах использования.

Управление данными в реальном времени

С помощью баз данных NoSQL можно предоставлять рекомендации в реальном времени, персонализировать и улучшать взаимодействие с пользователем. Например, Disney+ предоставляет свою обширную библиотеку цифрового контента более чем 150 миллионам подписчиков, используя технологию баз данных NoSQL. Благодаря Amazon DynamoDB этот сервис может масштабировать и поддерживать популярные возможности, такие как «Продолжить просмотр», «Список на просмотр» и «Персонализированные рекомендации».

Безопасность облака

Графовые базы данных можно использовать для быстрого обнаружения сложных взаимосвязей в данных. Например, компания Wiz переосмыслила облачную безопасность в виде графов базы данных с помощью Amazon Neptune. Wiz помогает своим клиентам повысить уровень безопасности, быстро выявляя наиболее критические риски и устраняя их. Они используют модель графовой базы данных Amazon Neptune, чтобы выявить опасные сочетания факторов риска, являющиеся критическими. Механизмы управления рисками Wiz перемещаются по графам и в течение нескольких секунд объединяют ряд взаимосвязанных факторов рисков в графе безопасности.

Приложения с высокой доступностью

Распределенные базы данных NoSQL отлично подходят для создания приложений с высокой доступностью и низкой задержкой для обмена сообщениями и файлами, социальных сетей, а также многого другого. Например,более 290 миллионов пользователей Snapchat ежедневно отправляют миллиарды фотографий и видеосообщений. В этом приложении используются системы баз данных NoSQL для снижения средней задержки отправки сообщений на 20 %.

Как работают базы данных NoSQL?

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

Пример базы данных NoSQL

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

В реляционной базе данных запись о книге часто разделяется на несколько частей (или «нормализуется») и хранится в отдельных таблицах, отношения между которыми определяются ограничениями первичных и внешних ключей. В этом примере в таблице «Книги» имеются столбцы «ISBN», «Название книги» и «Номер издания», в таблице «Авторы» – столбцы «ИД автора» и «Имя автора», а в таблице «Автор–ISBN» – столбцы «Автор» и «ISBN». Реляционная модель создана таким образом, чтобы обеспечить целостность ссылочных данных между таблицами в базе данных. Данные нормализованы для снижения избыточности и в целом оптимизированы для хранения.
В базе данных NoSQL запись о книге обычно хранится как документ. Для каждой книги, или элемента, значения «ISBN», «Название книги», «Номер издания», «Имя автора» и «ИД автора» хранятся в качестве атрибутов в едином документе. В такой модели данные оптимизированы для интуитивно понятной разработки и горизонтальной масштабируемости.

Терминология NoSQL

В таблице ниже сравниваются терминологии некоторых баз данных NoSQL и баз данных SQL.

SQL	MongoDB	DynamoDB	Cassandra	Couchbase
Таблица	Коллекция	Таблица	Таблица	Корзина данных
Ряд	Документ	Элемент	Ряд	Документ
Столбец	Поле	Атрибут	Столбец	Поле
Первичный ключ	ObjectId	Первичный ключ	Первичный ключ	ИД документа
Индекс	Индекс	Вторичный индекс	Индекс	Индекс
Представление	Представление	Глобальный вторичный индекс	Материализованное представление	Представление
Вложенная таблица или объект	Встроенный документ	Карта	Карта	Карта
Массив	Массив	Список	Список	Список

Какие существуют типы баз данных NoSQL?

Существует несколько различных систем баз данных NoSQL в связи с различиями в способах работы и хранения данных без схем. Ниже приводится объяснение некоторых из распространенных типов.

Базы данных «ключ‑значение»

Базы данных «ключ-значение» поддерживают высокую разделяемость и допускают горизонтальное масштабирование на уровне, недоступном для других типов баз данных NoSQL. База данных «ключ‑значение» хранит данные как совокупность пар «ключ‑значение», в которых ключ служит уникальным идентификатором. Ключи и значения могут представлять собой что угодно: от простых до сложных составных объектов. Хорошими примерами использования хранилищ данных «ключ‑значение» являются игровые, рекламные приложения и приложения IoT.

Базы данных документов

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

Графовые базы данных

Графовые базы данных предназначены для хранения взаимосвязей и навигации в них. В таких базах данных используются узлы для хранения сущностей данных и ребра для хранения взаимосвязей между сущностями. Ребро всегда имеет начальный и конечный узел, тип и направление. Ребра могут описывать взаимосвязи типа «предок‑потомок», действия, права владения и тому подобное. Количество и типы взаимосвязей, которые может иметь узел, неограничены. Графовые базы данных можно использовать для разработки и запуска приложений, работающих с наборами тесно связанных данных. В числе стандартных примеров использования графовой базы данных – социальные сети, сервисы рекомендаций, системы выявления мошенничества и графы знаний.

Базы данных в памяти

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

Поисковые базы данных

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

В чем разница между базами данных NoSQL и SQL?

Базы данных SQL моделируют отношения между данными в виде таблиц. Каждая строка таблицы представляет собой набор связанных значений, относящихся к одному объекту или сущности. Каждый столбец таблицы представляет собой атрибут данных, а в поле (или ячейке таблицы) хранится фактическое значение атрибута. Можно использовать систему управления реляционными базами данных (RDBMS) для доступа к данным различными способами без реорганизации самих таблиц базы данных. Основные различия между реляционными и нереляционными базами данных приведены в таблице ниже.

Реляционные базы данных

Базы данных NoSQL

Подходящие рабочие нагрузки

Реляционные базы данных предназначены для транзакционных и строго непротиворечивых приложений онлайн-обработки транзакций (OLTP). Они также хорошо подходят для аналитической обработки онлайн (OLAP).

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

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

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

Реляционные базы данных обеспечивают набор свойств ACID: атомарность, непротиворечивость, изолированность, надежность.

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

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

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

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

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

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

Запросы на хранение и извлечение данных составляются на языке SQL. Эти запросы анализирует и выполняет реляционная база данных.

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

Когда следует выбирать базы данных NoSQL вместо баз данных SQL?

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

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

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

Как AWS может удовлетворить ваши требования по работе с базой данных NoSQL?

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

Amazon DynamoDB – это бессерверный, полностью управляемый сервис баз данных «ключ-значение», который обеспечивает стабильную производительностью на уровне нескольких миллисекунд на операцию и неограниченную масштабируемость.
Amazon DocumentDB (совместимость с MongoDB) – это полностью управляемая база данных документов с поддержкой JSON, которая делает более выгодной и упрощает эксплуатацию важнейших рабочих нагрузок по обработке документов практически в любых масштабах без необходимости управлять инфраструктурой.
Amazon Neptune – это бессерверный и полностью управляемый сервис графовых баз данных, обеспечивающий превосходную масштабируемость и доступность, а также возможность запрашивать миллиарды связей за считанные секунды.
Amazon MemoryDB для Redis – это надежный сервис баз данных в памяти, который обеспечивает сверхбыструю производительность и отклик на операции чтения и записи за микросекунды.
Amazon ElastiCache – это полностью управляемый сервис кэширования и хранения данных в памяти, совместимый с Redis и Memcached и обеспечивающий оптимизированную по затратам производительность.
Amazon Keyspaces (для Apache Cassandra) – это бессерверная и полностью управляемая база данных с широкими столбцами, обеспечивающая доступность до 99,999 % при мультирегиональной репликации.
Amazon Timestream – это бессерверная и полностью управляемая база данных, которая упрощает хранение и анализ триллионов событий в день, выполняя свою работу в 1000 раз быстрее, чем реляционная база данных.
Amazon OpenSearch Service – это полностью управляемый пакет распределенного поиска и аналитики, который обеспечивает поиск, мониторинг и анализ корпоративных и операционных данных в реальном времени.

Начните работу с NoSQL на AWS, создав бесплатный аккаунт уже сегодня.