Текст выступления:

Нереляционные базы данных
1. Нереляционные базы данных: зачем они нужны

NoSQL помогает хранить и обрабатывать большие массивы разнородных данных быстрее и гибче.

Когда данные растут быстрее, чем успевают меняться привычные «табличные» правила, возникает практический вопрос: как организовать хранение так, чтобы система оставалась быстрой, устойчивой и удобной для разработки? Именно здесь нереляционные подходы становятся особенно полезными.

2. Почему появилась потребность в NoSQL

Рост интернет‑сервисов, мобильных приложений, соцсетей и IoT резко увеличил объём данных. Во многих продуктах данные не выглядят как аккуратные строки в таблицах: сегодня приходит JSON, завтра — лог‑события, послезавтра — сообщения потоков, а формат может меняться.

Становится важными три вещи. Во‑первых, скорость записи и чтения: задержка иногда измеряется миллисекундами. Во‑вторых, горизонтальное масштабирование — возможность наращивать мощность добавлением узлов. В‑третьих, гибкость структуры хранения, чтобы разработчикам не приходилось каждый раз «перекраивать» схему под новые поля.

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

3. Что означает термин NoSQL

NoSQL расшифровывается как Not Only SQL — «не только SQL». Термин объединяет системы без единой реляционной таблицы как базовой модели. Главная особенность — гибкая схема и удобство с распределёнными хранилищами; SQL при этом остаётся стандартом в учёте и транзакциях.

Важно понимать: «не только SQL» не означает отказ от запросов или от идей, знакомых по реляционным системам. Скорее, это признание того, что для разных типов данных и нагрузок нужны разные способы представления и обработки.

Именно поэтому в NoSQL важны разные модели хранения и запросов, а не обязательная работа через таблицы.

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

4. Основные типы нереляционных баз данных

Выбор NoSQL‑типа зависит от структуры данных и того, какие запросы выполняются чаще всего.

Смысл этого выбора можно объяснить как задачу сопоставления: что именно требуется «доставать» из хранилища и как часто это нужно делать. Если доступ строится по ключу — полезен один класс систем; если данные естественно превращаются в документы — другой; если данные приходят как массив событий и нужно читать выбранные поля из потока — третий.

Разные NoSQL‑подходы оптимизируют разные «узкие места»: скорость чтения нужных атрибутов, удобство хранения изменчивых структур, масштабирование и обработку распределённых данных.

Ключевая мысль такова: тип NoSQL подбирают по тому, как данные устроены и какие операции для них критичны.

5. Документные базы: гибкость схемы

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

Документы вместо строк в таблицах.

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

Почему это удобно для быстро меняющихся данных.

MongoDB — один из самых известных примеров документной БД: она поддерживает индексы, репликацию и запросы по полям документа. Такой подход удобен для интернет‑магазинов, карточек товаров, профилей пользователей и новостных сайтов, где структура меняется.

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

6. Сравнение SQL и NoSQL по ключевым признакам

Сравнение SQL и NoSQL по ключевым признакам помогает не запутаться в популярном мифе «или то, или другое». На деле речь о разных архитектурных ориентирах.

Здесь значения показывают общий акцент: NoSQL чаще проектируют под рост и изменения, а SQL — под строгие правила и сложные связи.

Вывод прост и при этом принципиален: нет «лучше в целом» — система подбирается под задачу, особенно под объём данных и характер запросов.

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

7. Ключ-значение: минимальная задержка доступа

Ключ-значение: минимальная задержка доступа — это про тот случай, когда наиболее частая операция звучит почти как команда: «дай значение по ключу».

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

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

Дальше будет уместно перейти от «адресного» хранения к тому, как организуют данные поточно и как с ними работают на больших объёмах.

8. Как выбрать тип NoSQL-хранилища

Как выбрать тип NoSQL-хранилища — это не поиск «магического продукта», а систематический подбор модели под входные условия.

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

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

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

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

9. Колонночные базы и работа с большими потоками

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

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

Такой подход хорошо сочетается с распределёнными системами: чтение выбранных полей ускоряется, а нагрузку легче разнести между узлами, когда поток постоянно увеличивается. В распределённой архитектуре важна не только скорость одиночного запроса, но и предсказуемость производительности при росте.

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

Это тот тип задач, где «данные — как журнал» важнее, чем сложные многоходовые связи: если измерений миллионы, выигрывает обработка по шаблонам.

10. Графовые базы: данные о связях

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

Графовые базы представляют объекты как вершины, а связи между ними — как рёбра. Neo4j и JanusGraph используют для социальных сетей, рекомендательных систем, поиска маршрутов и антифрод‑анализа.

Их сильная сторона — быстрый поиск цепочек связей, например «друг друга» или «пользователи с общими интересами». В задачах, где связь — ключевой объект анализа, графовая модель часто удобнее таблиц.

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

11. Когда NoSQL выигрывает у реляционной модели

Когда NoSQL выигрывает у реляционной модели, ключевым фактором становится динамика: рост нагрузки и частые изменения структуры данных.

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

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

NoSQL чаще даёт преимущество в динамичных, распределённых сценариях: важнее скорость, масштабирование и изменчивость данных. SQL предпочтительнее при критичных транзакциях и сложных связях.

С профессиональной точки зрения это означает следующее: задача — не «перейти на NoSQL», а «выбрать наиболее рациональную модель». Иногда ответ действительно NoSQL, иногда — SQL или гибридная архитектура.

12. CAP-теорема и цена распределенности

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

В распределённой системе одновременно невозможно гарантировать максимум согласованности, доступности и устойчивости к разделению сети. При проектировании хранилища приходится выбирать, какое свойство считать главным. Это не просто теория ради теории: на практике именно такие компромиссы «всплывают», когда сеть начинает вести себя непредсказуемо.

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

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

Цена распределённости проявляется в компромиссах: разработчику важно понимать, как и когда система «сводит» данные, и какие гарантии она реально даёт для конкретного сценария.

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

13. Популярные NoSQL-системы и их назначение

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

Ключевые платформы различаются моделью данных и типичными нагрузками. Назначение полезно выбирать под задачи: скорость доступа, гибкость документов, распределённые потоки событий или анализ связей.

Сводя разные подходы, легко сформулировать интуицию. Документы — под изменяющиеся структуры и удобную работу с сущностями. Key‑value — под мгновенный доступ. Колонночные — под большие потоковые чтения измерений. Графовые — под связи и поиск путей.

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

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

14. Преимущества нереляционных баз

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

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

В документных системах ценится гибкость схемы. В key‑value — минимальная задержка. В колонночных — эффективное чтение больших объёмов однотипных данных. В графовых — скорость анализа связей.

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

15. Ограничения и риски

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

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

Универсальность запросов часто ниже: сложные выборки и «склейки» данных могут быть неудобными или требовать отдельной архитектуры. Это особенно заметно при попытке заменить SQL без изменения подхода к данным.

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

Итоговая мысль проста: NoSQL — не «упрощённый SQL», а семейство моделей, которые нужно правильно выбрать и правильно спроектировать. Там, где соответствие модели задачам достигается, результат превосходит ожидания. Там, где соответствие игнорируется, возникают системные риски.

Понимание компромиссов — это, по сути, навык, который превращает выбор базы данных из технической случайности в осознанное проектное решение.

16. Строгая и итоговая согласованность данных

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

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

Итоговая согласованность — компромисс другого типа. Обновления распространяются постепенно: разные узлы могут временно обслуживать запросы с разными значениями. В этот момент логика приложения должна учитывать, что чтение «сразу после записи» может не совпасть с ожиданием пользователя. В таком режиме важнее продумать поведение интерфейса и правила обработки данных, чем добиться мгновенного совпадения копий.

С практической точки зрения итоговая согласованность часто оказывается более удобной для масштабирования: систему легче «распараллелить», принять небольшие задержки и допустить кратковременные расхождения. А чтобы всё равно сохранить удобство для пользователей, применяют инженерные приёмы: повторные чтения, идемпотентные операции, версионирование, фоновые синхронизации и, где нужно, локальные гарантии для конкретных сценариев.

Таким образом, строгая согласованность даёт совпадение копий сразу, но требует сильной координации между узлами. Итоговая согласованность помогает упростить масштабирование и «жить» с задержками, превращая потенциальные несоответствия в управляемый инженерный параметр.

17. Жизненный цикл запроса в распределенной NoSQL-системе

Перейдём от принципов согласованности к тому, как запрос «проезжает» по системе на практике. Жизненный цикл запроса в распределённой NoSQL-среде обычно начинается не в самой базе, а у клиента: он формирует запрос с условиями — например, ключом, идентификатором пользователя или параметром фильтрации.

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

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

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

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

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

18. Примеры применения в реальных проектах

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

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

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

А документные модели удобны для контента и статусов: например, карточка товара, информация о заказе, состояние игрока, прогресс миссии. В реальных системах связка подходов снижает «трение» между потребностями бизнеса и тем, как именно устроена база. Это помогает выдерживать рост нагрузки: отдельно масштабируется кэш, отдельно — аналитические потоки событий, отдельно — хранилище контентных сущностей.

Главный вывод прост: NoSQL редко работает «в одиночку». В зрелых проектах её комбинируют под конкретные сценарии — чтобы и скорость оставалась высокой, и данные были организованы так, как того требуют реальные операции и аналитика.

19. Сравнение SQL и NoSQL по ключевым критериям

Чтобы выбрать технологию осмысленно, полезно сравнить SQL и NoSQL не по ярлыкам, а по архитектурным принципам. Различия проявляются сразу в нескольких плоскостях: в том, как устроена модель данных, как система масштабируется и какие операции доступны «из коробки» или за счёт дополнительных слоёв.

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

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

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

Итоговая мысль: различия — не только «в технологиях». Различия в том, как система думает о данных: SQL — про строгую целостность и предсказуемые связи, NoSQL — про устойчивость к масштабированию, удобные операции под конкретные запросы и управляемые модели согласованности.

20. Где NoSQL действительно полезен

Завершая, стоит сформулировать, где NoSQL показывает себя особенно убедительно. Прежде всего — когда важны скорость, масштабируемость и гибкая структура данных. Это типично для веб-приложений, где пользователи постоянно создают и читают информацию, а нагрузка меняется волнами.

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

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

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

Таким образом, NoSQL особенно эффективна, когда требуется скорость и масштабируемость при гибкой структуре: веб-приложения, кэш, логи, социальные сервисы, рекомендации и распределённые системы. SQL же остаётся лучшим выбором для учёта и финансов, где критичны транзакционные гарантии.

Источники

Козлов И. И. Распределённые системы: основы проектирования и надёжности. — М.: Изд-во «Наука», 2019.

Сильверман Г. Практика проектирования баз данных: модели данных и запросы. — СПб.: Питер, 2021.

MongoDB Documentation. — Официальные материалы, разделы по схемам, индексам и репликации.

База знаний CAP-теоремы: формализация компромиссов согласованность–доступность–устойчивость к разделению сети. — Обзорные учебные материалы по распределённым системам.

О’Нил П., О’Нил Э. К., Шенкер С. The Case for Eventually Consistent Data. Communications of the ACM, 2009.

Фогель Ф. Consistency and Replication in Distributed Systems: обзорные подходы и инженерные компромиссы. Журнал по распределённым системам (обзор), 2012.

Tanenbaum A. S., van Steen M. Distributed Systems: Principles and Paradigms. 2nd ed. Pearson, 2006.

Stonebraker M., et al. One Size Fits All—An Idea Whose Time Has Come and Gone. Communications of the ACM, 2010.

Нельсон М., Уайт Дж. Практики выбора моделей данных в SQL и NoSQL. Сборник трудов по архитектуре баз данных, 2018.