NoSQL - это не одна конкретная база данных, а семейство разных подходов к хранению данных. Когда новички слышат это слово, они часто думают что-то вроде "это база без SQL". Это слишком грубо. На практике смысл в другом: NoSQL-системы выбирают не потому, что кто-то "не любит таблицы", а потому что у продукта другие требования к масштабированию, модели данных, скорости записи, доступности или паттернам чтения.
Для QA эта тема важна по простой причине: поведение данных в NoSQL часто отличается от того, к чему привыкли люди после реляционных баз. Если тестировщик продолжает ожидать жёсткую схему, привычные join и одинаковую консистентность везде, он легко делает неверные выводы о системе.
Какие бывают NoSQL-системы
Под зонтиком NoSQL обычно живут несколько разных классов решений:
- →document databases
- →key-value stores
- →wide-column stores
- →graph databases
Document databases хранят данные документами, часто в JSON-подобной форме. Это удобно, когда сущность естественно выглядит как вложенный объект.
Key-value stores работают по простой модели: есть ключ и значение. Их часто используют для кэша, сессий, feature flags, быстрых lookup и временных данных.
Wide-column stores выбирают там, где важны масштабирование и работа с очень большими объёмами данных.
Graph databases нужны в системах, где главную роль играют связи между объектами: граф друзей, зависимости, маршруты, рекомендации.
Для QA здесь важен один базовый вывод: NoSQL - это не "ещё одна база", а разные модели хранения с разными рисками.
Чем NoSQL отличается от реляционной базы
- →схема данных часто менее жёсткая
- →связи между сущностями могут храниться иначе
- →join либо ограничены, либо вообще не являются нормальным способом работы
- →данные чаще денормализуются
- →гарантии консистентности и транзакционности могут быть другими
- →структура хранения сильнее подчинена реальным access patterns
Для QA это означает, что нельзя автоматически переносить привычки из SQL-мышления на любую NoSQL-систему.
Например, в document database вполне нормально хранить часть данных вложенно в один документ, а не раскладывать их по многим таблицам. Это может быть очень удобно для чтения, но создаёт другие риски: дублирование данных, рассинхронизацию копий, тяжёлые обновления вложенных структур.
Что особенно важно QA
При тестировании NoSQL-систем QA особенно полезно смотреть на такие вещи:
- →как выглядит фактическая структура данных
- →какие поля обязательны, а какие реально плавают между документами
- →нет ли неожиданных различий в схеме между записями одного типа
- →как система ведёт себя при частичном обновлении документа
- →не разъезжаются ли денормализованные данные
- →есть ли eventual consistency и как она влияет на сценарий
- →как работают индексы на реальных данных
- →как система ведёт себя при ретраях и конкурентных изменениях
Особенно важно понимать, что "данные не сразу одинаковые везде" не всегда означает баг. В некоторых NoSQL-системах это часть модели. Но тогда QA должен уметь отличать допустимую eventual consistency от настоящей потери данных или неконсистентного состояния.
Где чаще всего ломается
- →у документов одного типа разная структура
- →обязательное поле отсутствует только в части записей
- →одна копия денормализованных данных обновилась, а другая нет
- →после retry появились дубли
- →часть данных читается из одного узла, а часть ещё не успела синхронизироваться
- →индекс не покрывает реальный запрос, и система начинает вести себя плохо на объёме
- →логика обновления вложенных объектов затёрла соседние поля
- →consumer ожидает строгую схему, а получает вариативную
Это не значит, что NoSQL хуже. Это значит, что риски другие, и QA должен их видеть.
Document model и денормализация
Для QA один из самых важных практических моментов в NoSQL - это денормализация.
В реляционной базе естественно хранить одну сущность в одной таблице, а связанные данные отдельно. В document-oriented мире часть связанных данных могут намеренно копироваться в несколько мест ради быстрого чтения.
Например, имя пользователя может лежать не только в профиле, но и внутри документов заказов, комментариев или событий. Это ускоряет чтение, но создаёт риск рассинхронизации. Если профиль обновился, а вложенные копии имени в связанных документах остались старыми, формально каждая запись "есть", но продукт уже отдаёт несогласованные данные.
Для QA это важный класс проверок: не только "записались ли данные", но и "обновились ли все нужные представления этих данных".
Практический пример
Представь систему заказов на document database.
Один заказ хранится как документ, внутри которого есть:
- →данные пользователя
- →список товаров
- →суммы
- →статус
- →история изменений
Это удобно: одним запросом можно получить почти всё, что нужно экрану.
Но теперь представь, что пользователь поменял email, а часть заказов всё ещё хранит старую копию этого email внутри документов. Или обновление одного товара в массиве затёрло соседние элементы. Или после retry создались два почти одинаковых документа заказа.
Снаружи это может выглядеть как "странный баг на списке заказов". На самом деле проблема сидит в модели хранения и обновления данных.
Что должен вынести QA из этой темы
- →NoSQL - это семейство разных подходов, а не одна база "без SQL".
- →У document, key-value, wide-column и graph систем разные свойства и разные риски.
- →Главные зоны внимания QA здесь - схема данных, денормализация, консистентность, ретраи и конкурентные обновления.
- →Не все странности в NoSQL - это баг, но QA должен понимать, где заканчивается допустимая модель и начинается настоящая поломка.
- →Для проверки NoSQL важно мыслить не таблицами, а реальными паттернами хранения и чтения данных.
Что ещё почитать
- →Внутри базы: Database testing
- →Внутри базы: SQL для QA
- →Внешний материал: MongoDB data model intro