„тобы пон€ть NoSQL, нужно разобратьс€, что такое SQL и почему мы говорим ему No.

»так, SQL (structured query language) расшифровываетс€ как Ђ€зык структурированных запросовї, и это €зык запросов дл€ управлени€ данными в так называемых рел€ционных базах данных, или просто Ѕƒ

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

¬ этих таблицах есть строки и столбцы. ¬ столбце таблицы хранитс€ определенный тип данных, а в каждой €чейке Ц значение.

–ел€ционные Ѕƒ

—трока же получаетс€ как набор св€занных значений, которые относ€тс€ к одному объекту - мы видим что у крыла типа чайка длина 25 метров.

ID

Ќу и кажда€ строка в таблице может быть помечена каким то уникальным идентификатором, который называетс€ первичным ключом (primary key). ј затем при помощи него мы можем св€зать данные из нескольких таблиц, например в отдельной таблице, где он станет внешним ключом (foreign key).

—в€зь таблиц

¬ общем, как таблица в экселе, только данные могут быть св€заны.

„то еще важно знать: рел€ционные Ѕƒ требуют так называемую схему (schema) - описание структуры таблицы ее полей и ограничений. “о есть если нам например нужно добавить или убрать столбец в таблице, то это изменение коснетс€ всех данных внутри нее.

“акже Ѕƒ этого типа соответствуют так называемым принципам ACID (Atomicity Ч јтомарность, Consistency Ч —огласованность, Isolation Ч »золированность, Durability Ч ЌадЄжность), что вкратце означает, что при работе с базой, целостность и согласованность данных гарантирована, даже если возникли проблемы с сетью или железом, что полезно при работе с финансами, например.

¬ качестве примеров таких баз назовем: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL.

–азобрались. “еперь вернемс€ к NoSQL. Ёто тип баз данных, которые хран€т данные в отличном от рел€ционных таблиц формате. ќни узкоспециализированны дл€ конкретных задач и нужны дл€ улучшени€ производительности, масштабируемости и удобства в работе.


Ѕазы данных "ключ-значение" (key-value)

—уть в том, что мы храним данные в таком виде: у нас есть уникальный ключ, который указывает на какое-то значение. ј сама база - это совокупность этих пар. ¬от так просто! ѕричем эти данные могут быть чем угодно, числом, строкой или даже другой парой ключ-значение потому что в отличии от рел€ционных баз данных они не имеют предопределенной структуры данных.

key-value

ћногие Ѕƒ такого типа хран€т данные в пам€ти (RAM), в отличии от других баз, которые хран€т данные на диске, что хоть и может ограничивать объем хранимых данных (хот€ они требуют гораздо меньше пам€ти), но это обеспечивают просто неверо€тную скорость. Ќу и раз это NoSQL то никаких сложных запросов, никаких св€зей друг с другом - мы просто записываем ключ и его значение, и получаем значение по ключу.

√де их использовать? ќни отлично подход€т дл€ хранени€ кэша или пользовательских сессий. ј в качестве самого простого примера можно назвать корзину в интернет магазине - где мы храним идентификатор пользовател€, и сколько товаров он положил в корзину.

—амые попул€рные хранилки по типу Уключ - значениеФ это Redis, Memcached и DynamoDB.


Wide-column (columnstore базы данных, Ѕƒ с широкими столбцами или колоночные Ѕƒ)

¬се также просто - берем key-value Ѕƒ, и делаем так чтобы в значении мы могли хранить несколько столбцов сразу. Ёто позвол€ет удобно хранить св€занную информацию. ѕохоже на рел€ционную Ѕƒ, но только в отличии от нее, тут у нас нет схемы, поэтому мы можем хранить разные неструктурированные данные.

Wide-column

“акой тип Ѕƒ подойдет дл€ хранени€ логов, данных с умных холодильников и чайников, а также различных аналитических приложений, где данные хран€тс€ в большом объеме. Netflix, например, хранит в таких таблицах историю просмотров пользовател€.

¬ качестве примеров таких баз назовем Cassandra, Hbase и ClickHouse.


Ѕазы данных документов или документориентированные Ѕƒ (Document DB)

ѕодробнее про них можно прочитать в нашей отдельной статье.

≈сли предыдущие типы NoSQL Ѕƒ обычно используютс€ дл€ специфических задач, то эти базы уже более универсальны, и могут стать основным местом хранени€ информации.

«десь мы храним документы. ƒокумент это набор нескольких пар ключ-значение, о которых мы говорили раньше, и раз это не SQL, то они неструктурированны и не требуют схему. Ёто значит, что мы можем легко добавл€ть и удал€ть пол€ в документе, в отличие от рел€ционных Ѕƒ, где изменени€ затронули бы всю таблицу. ƒокументы даже могут быть вложенными, и содержать в себе другие документы.

Document DB

ƒанные хран€тс€ в стандартных форматах, таких как XML, YAML и JSON. “ака€ форма хранени€ идеально подходит к объектам, которые используютс€ в приложени€х. ћы буквально сразу получаем полный объект который нам нужен, а в SQL нужно сначала приложить усили€ и даже сделать несколько запросов и все собрать в необходимый вид.

ƒокументы можно группировать друг с другом собира€ их в коллекции, которые можно собирать в логическую иерархию, получа€ что-то по типу рел€ционных Ѕƒ.

Ёто как шкаф на работе - в один €щик мы можем положить трудовые договоры, в другой - договоры с партнерами, а в третий договоры аренды.

Ќичто нам не мешает сложить всЄ в одну кучу, но так удобнее. » вот эти €щики как раз и будут коллекци€ми в нашем случае. ј отсутствие схемы позвол€ет нам положить в один €щик договоры, которые схожи логически, но имеют разную структуру внутри. Ќапример, долгосрочный договор с сотрудником и договор с компанией.  оллекции есть не у всех Ѕƒ такого типа, некоторые системы используют теги или древовидные иерархии.

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

—амые попул€рные Ѕƒ такого типа - MongoDB, Amazon DynamoDB, CouchDB.


√рафовые Ѕƒ (Graph DB)

“ут мы больше значени€ удел€ем тому как данные св€заны друг с другом, и эта Ѕƒ лучше всего обрабатывает такие данные.

“ут у нас есть узлы, которые представл€ют данные и ребра (или соединени€), которые описывают св€зь между этими данными. ѕомните как в рел€ционных базах мы записывали св€зь в отдельной таблице? “ут мы можем обойтись без нее, просто показав св€зь.

Graph DB

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

—амые попул€рные графовые базы: Neo4j и DGraph


ѕоисковые Ѕƒ (Search-engine database)

ќни, как пон€тно из названи€, нужны дл€ поиска данных из большого количества источников.

–аботают они примерно также как и базы данных документов - мы добавл€ем документы с текстом внутри, а Ѕƒ проанализирует весь текст в этих документах и создаст индексы дл€ этого текста.

Search-engine database

ѕо сути это работает как указатели, которые ты видел в конце книги, где указываетс€ какой-то термин и страница на которой он встречаетс€.

» когда пользователь выполн€ет поиск, то сканируютс€ только эти индексы, а не все документы в базе.

Ќу и очевидно что они используютс€ в качестве полнотекстового поиска, а также дл€ хранени€ и анализа логов. ѕримеры - Elasticsearch, Solr, Algolia


Ѕазы данных временных р€дов (Time series database)

Ёто базы данных, оптимизированные дл€ данных с отметками времени. “акое используетс€, дл€ мониторинга систем, где мы храним значение времени и данные в этот момент. Ќапример, загрузка сервера или количество подключений.

Time series database

ѕримеры - InfluxDB и Prometheus


ћногомодульные Ѕƒ (multi-model)

“акже существуют так называемые много-модульные Ѕƒ (multi-model), которые поддерживают несколько моделей данных.

Ќапример тот же рredis умеет и в ключ-значение, и документы с графами и даже временные данные обработает.


—кидки 50% в Merion Academy

¬ыбрать курс