[БЕЗ_ЗВУКА]
Всем привет.
В прошлых видео мы говорили о реляционных базах данных.
А в этом видео мы поговорим о нереляционных базах данных или,
как их называют, NoSQL.
Поговорим об отличиях реляционных и нереляционных баз данных,
почему появились нереляционные базы данных, зачем они нужны,
являются ли они убийцами реляционных баз данных, и поговорим о принципе BASE,
который является заменой принципа ACID для нереляционных баз данных.
Смотрите.
Тогда как у всех реляционных баз данных есть общие признаки,
то термин NoSQL обозначает по сути все, что не является реляционной базой данных.
И соответственно, NoSQL решения принципиально отличаются друг от друга,
то есть есть много разных NoSQL решений, в то время как реляционные решения,
реляционные базы данных, они похожи друг на друга.
Изначально NoSQL — это был акроним от слов No+SQL.
То есть это как бы что-то, что отрицает SQL, отрицает реляционную парадигму.
А сейчас NoSQL как бы расширился, появилось больше возможностей у NoSQL баз
данных, и поэтому NoSQL теперь расшифровывается,
как Not+Only+SQL — не только то, что может SQL.
Так зачем же появились NoSQL базы данных?
В принципе, реляционные базы данных просто великолепны.
Они очень много что могут, они быстрые, они удобные,
они обеспечивают целостность данных и т.д.
Зачем же нам потребовался NoSQL?
Дело в том, что где-то с 2000 годов объем данных начал
очень лавинообразно расти, интернет этому очень помог.
Появляется термин Big Data, это когда данные очень разнородные, их много,
для их обработки нужны много компьютеров, кластера, параллельные вычисления,
вот это вот все.
А у реляционных баз данных с этим как раз не очень.
Они очень сложны по своему устройству и
поэтому плохо масштабируются на разные сервера.
То есть на одном сервере можно увеличить мощность этого сервера,
чтобы увеличить как бы количество данных, обрабатываемых реляционной базой данных,
но увеличивать ее бесконечно, увеличивать мощность одного сервера бесконечно нельзя.
Проще, и дешевле, и как бы удобнее использовать несколько серверов.
Ну и вот с этим у реляционных баз данных как раз плохо.
К тому же, если вы вспомните,
то все таблицы в реляционных базах данных имеют жесткую структуру.
Это значит, что все записи в них одинаковой структуры.
И когда появляется необходимость в разнородных данных,
их не очень удобно хранить в таких таблицах.
Вот поэтому появился, собственно, NoSQL.
Давайте бегло рассмотрим различия между SQL и NoSQL.
Причем поскольку NoSQL баз данных, как я уже говорил, много разных типов, мы в
основном возьмем свойства нереляционной базы данных типа «ключ-значение».
Итак, реляционная база данных состоит из таблиц,
таблицы состоят из строк и колонок, строки одной таблицы одинаковы по структуре.
В то время как нереляционная база данных может содержать коллекции,
которые содержат записи.
Будем считать, что коллекции — это аналоги таблиц.
А может и не содержать коллекции, может сразу содержать записи.
Записи при этом могут иметь разную структуру.
То есть две записи в одной коллекции могут иметь вообще абсолютно разный набор полей.
Схема данных в реляционных базах определена заранее.
Она строго типизирована, существуют отношения и ограничения,
и все это используется для обеспечения целостности данных.
То есть жесткая структура, определенная заранее,
с определенными типами каждого поля.
В нереляционных, соответственно, нет никакой схемы данных,
ничего заранее не определено, нет никаких ограничений, отношений,
но из-за этого нет и контроля целостности.
И соответственно, у любой записи могут быть абсолютно любые поля.
В SQL данных используется нормализация,
чтобы избежать дублирования одних и тех же данных.
И соответственно, нормализация порождает отношения между таблицами.
То есть данные как бы одной записи хранятся по разным таблицам, разбросаны.
Вот.
А в нереляционных между коллекциями или значениями в одной
коллекции никаких связей нет, никаких отношений нет, данные денормализованы,
и хранятся в записях там опять-таки любые поля.
В реляционной базе данных работа с данными структуры выполняется через SQL запросы,
и SQL почти одинаковый для любой реляционной базы данных,
ну по крайней мере очень похож.
В то время как в NoSQL базах данных, как правило, у каждой свое API,
кто куда хочет, кто в лес, кто по дрова.
В SQL, в реляционных базах данных SQL запрос извлекает
данные из одной или из нескольких таблиц, чтобы получить финальный результат,
используя объединение этих таблиц или оператор join.
Там возможны сложные условия, фильтрация данных сложная, агрегация там,
суммирование и т.д..
В нереляционных нет никаких join,
то есть данные из нескольких ячеек не объединяются.
Условия простые, как правило, поиск по строгому соответствию ключа.
Хотя в некоторых нереляционных базах данных есть возможность агрегации и
вторичные индексы, но возможности их в любом случае гораздо меньше,
чем у реляционных баз данных.
Также в реляционных базах данных данные разбиты по, собственно,
плоским таблицам и хранятся не совсем так, как они хранятся в приложении.
То есть в приложении, как правило, структура данных такая, иерархическая.
А в реляционных базах данных плоские таблицы,
поэтому необходим какой-то мэппинг из таблиц в данные приложений, более сложный,
чем это достигается в нереляционных базах данных, в которых как раз данные могут
храниться примерно в том же виде, в котором они хранятся в приложении.
Итак, вот итоги, в чем основные различия между SQL и NoSQL?
В то время как SQL более универсален и поддерживает целостность данных,
под SQL я имею в виду реляционные базы данных, в это время NoSQL,
они в ущерб вот как раз своей универсальности и согласованности
данных эффективнее масштабируются, могут хранить разнородные данные.
Но возможностей у них меньше.
И вот пока NoSQL все-таки не убил SQL.
SQL все еще лидирует именно за счет того, что его возможности шире.
Но зато все крупные компании имеют свои облачные NoSQL хранилища: Google,
Amazon, Microsoft завязаны на NoSQL базы данных.
Давайте поговорим о принципах BASE.
В то время как в реляционных базах данных есть требования ACID — атомарность,
согласованность, изолированность и устойчивость или надежность,
в NoSQL вместо этого рассматривается набор свойств BASE: базовая доступность
(basic availability), гибкое состояние (soft state),
согласованность в конечном счете (eventual consistency).
Базовая доступность подразумевает, что каждый запрос гарантированно завершается,
удачно или неудачно,
но по крайней мере он действительно завершается с каким-то ответом.
Гибкое состояние подразумевает, что состояние системы с течением времени может
изменяться само по себе, даже без ввода каких-то новых данных со стороны.
Это происходит для достижения согласования данных.
И согласованность в конечном счете подразумевает, что данные в какой-то
момент времени в разных узлах могут быть рассогласованы, но спустя время
они все-таки приходят к согласованному состоянию, данные во всех узлах вот
этой распределенной нереляционной системы становятся одинаковыми.
Системы на основе BASE не могут использоваться в биржевых или банковских
системах, потому что там нужны транзакции, там как раз нужна согласованность данных,
там вот правит ACID.
Но дело в том, что достичь вот этих всех свойств ACID в больших распределенных
системах с какой-то многомиллионной аудиторией практически невозможно,
и поэтому NoSQL системы жертвуют согласованностью данных ради
масштабируемости и увеличения доступности.
Мы поговорили в этом занятии, значит, о нереляционных базах данных, узнали,
что потребность в них возникает, когда у вас есть много данных, и они разнородны,
и нужна скорость их обработки и масштабирование в кластера, облака и т.д.
И как всегда, это не бесплатно.
Масштабируемость и доступность достигаются за счет принесения в ущерб
атомарности и согласованности данных.
Но если ты — соцсеть с миллионами пользователей, то, в общем-то,
выбора у тебя особого и нету.
Дальше мы поговорим об основных типах нереляционных баз данных.
[ЗВУК] [БЕЗ_ЗВУКА]