NoSQL

NoSQL — это зонтичный термин для систем баз данных, которые не используют традиционную реляционную модель (таблицы и строки, запросы на SQL), обычно жертвуя частью строгого обеспечения схемы и возможностей join реляционных баз данных ради гибкости схемы, более лёгкого горизонтального масштабирования и — в зависимости от конкретной системы — иных характеристик производительности для конкретных паттернов доступа. Он делится на несколько отдельных семейств, которые объединяют под одним ярлыком, хотя ведут они себя совершенно по-разному: документо-ориентированные хранилища (MongoDB, Firestore — хранят полуструктурированные документы в стиле JSON, хорошо подходят для вложенных данных переменной формы); хранилища «ключ-значение» (Redis, DynamoDB — чрезвычайно быстрый простой поиск по ключу, минимальная гибкость запросов); ширококолоночные хранилища (Cassandra, HBase — созданы для огромной пропускной способности записи и горизонтального масштабирования на множестве узлов); и графовые базы данных (Neo4j — оптимизированы для эффективного обхода связей, например «друзья друзей»). Почему это важно для разработчиков AI/SaaS-продуктов: базы данных NoSQL появляются в AI-продуктах именно там, где данные действительно плохо укладываются в фиксированную реляционную схему — хранение произвольных, постоянно меняющихся полезных нагрузок вызовов инструментов (tool-call) LLM, гибких объектов конфигурации для каждого клиента или истории переписки в чате, где структура сообщений варьируется, — либо там, где конкретный паттерн доступа (чрезвычайно высокая пропускная способность записи, простые поиски по ключу в огромном масштабе) перевешивает преимущества join'ов и строгой схемы. Стоит отметить, что векторные базы данных технически являются специализированной формой NoSQL-базы, а современные «мультимодельные» базы данных (MongoDB с векторным поиском, Postgres с `jsonb` и pgvector) значительно стёрли историческую границу между SQL и NoSQL — команде больше не обязательно строго выбирать одну парадигму исключительно. Как это работает: большинство систем NoSQL ослабляют одну или несколько гарантий ACID, которые обеспечивают реляционные базы данных, обычно отдавая предпочтение «eventual consistency» (согласованность в конечном счёте — гарантируется, что запись со временем распространится на все реплики/узлы, но не обязательно мгновенно) в обмен на более высокую доступность и более лёгкое горизонтальное масштабирование на множестве обычных серверов — компромисс, формализованный CAP-теоремой, которая утверждает, что распределённая система может полностью гарантировать только два свойства из трёх: Consistency (согласованность), Availability (доступность) и Partition tolerance (устойчивость к сетевым разделениям). Практический пример: AI-чат-бот SaaS хранит транскрипты переписки — где структура сообщений варьируется (некоторые сообщения — простой текст, некоторые содержат вызовы инструментов, некоторые — сгенерированные изображения с метаданными) — в MongoDB в виде гибких JSON-документов, вместо того чтобы втискивать каждую возможную форму сообщения в жёсткий набор реляционных колонок, при этом храня биллинг, пользователей и подписки в Postgres, где гарантии ACID и структурированные join действительно важны. Такая осознанная «полиглотная персистентность» — выбор разной технологии базы данных под каждый тип данных исходя из его реального паттерна доступа, вместо того чтобы втискивать все виды данных в одну систему ради операционной простоты — становится всё более нормой именно для AI-продуктов, поскольку значительная часть данных, смежных с AI (история чатов, эмбеддинги, полезные нагрузки вызовов инструментов), действительно не так естественно укладывается в реляционную модель, как запись о подписке.