Какая структура данных в нереляционных БД?

Структуры данных в NoSQL базах данных

Структура данных в нереляционных (NoSQL) базах данных кардинально отличается от реляционной модели и варьируется в зависимости от типа самой БД. Основные категории NoSQL БД и их структуры данных:

1. Документоориентированные базы данных (например, MongoDB, CouchDB)

• Основная единица хранения: Документ — самодостаточная структура данных, обычно в форматах JSON, BSON или XML.
• Внутренняя структура: Вложенные пары "ключ-значение" или массивы.
• Особенность: Схема не фиксирована (schemaless), документы в одной коллекции могут иметь разную структуру.
• Пример документа в MongoDB (JSON):

{
  "_id": ObjectId("507f191e810c19729de860ea"),
  "username": "johndoe",
  "email": "john@example.com",
  "address": {
    "street": "123 Main St",
    "city": "Springfield"
  },
  "orders": [
    { "order_id": "A123", "amount": 50.75 },
    { "order_id": "B456", "amount": 30.20 }
  ]
}

2. Базы данных "ключ-значение" (например, Redis, DynamoDB)

• Самая простая структура: Каждая запись — это пара ключ (уникальный идентификатор, строка) и значение (данные любого типа: строка, число, список, хеш-таблица, бинарные данные).
• Преимущество: Высокая скорость операций чтения/записи за счет прямого доступа по ключу, как в хеш-таблице.
• Пример в Redis CLI:

> SET user:1001 "{ 'name': 'Alice', 'age': 30 }"
OK
> GET user:1001
"{ 'name': 'Alice', 'age': 30 }"
> HSET product:5501 price 299.99 category "Electronics"
(integer) weight 1.5

3. Колоночные (или ширококолоночные) базы данных (например, Cassandra, HBase)

• Структура: Напоминает таблицы в RDBMS, но более гибкая.
• Основные элементы:

    *   **Ключ строки** (Row Key): Уникальный идентификатор строки.
    *   **Семейство столбцов** (Column Family): Логическая группа колонок.
    *   **Колонки**: Каждая строка может содержать разное количество колонок, и они хранятся отсортированными по имени.

• Модель данных: Разреженная, распределенная, многомерная карта (sorted map of maps).
• Упрощенная логическая схема (Cassandra):

Таблица: Users
Row Key: user_id | Колонки: name | email        | address:city | address:street
-------------------------------------------------------------------------------
1001             | John         | john@mail.com | NY           | 5th Ave
1002             | Jane         | jane@mail.com |              | (адрес может отсутствовать)

4. Графовые базы данных (например, Neo4j, Amazon Neptune)

• Структура: Состоит из узлов (сущностей, аналог записей), связей (ребер, отношений между узлами) и свойств (атрибутов узлов и связей).
• Специализация: Для хранения и запросов сильно связанных данных.
• Пример Cypher-запроса (Neo4j):

// Создание узлов и связи
CREATE (alice:Person {name: 'Alice', age: 30})
CREATE (bob:Person {name: 'Bob', age: 35})
CREATE (alice)-[:KNOWS {since: 2020}]->(bob)

Важные общие принципы структур NoSQL

• Горизонтальная масштабируемость (sharding): Данные распределяются по множеству серверов через партиционирование (например, по диапазону ключей или хешу).
• Отсутствие JOIN'ов: Связи между данными обычно моделируются через денормализацию (вложенные документы, ссылки) или на уровне приложения. В графовых БД связи — это объекты первого класса.
• Схема на уровне приложения: Схема часто не контролируется БД, а валидируется в коде приложения, что дает гибкость, но требует дисциплины.
• Оптимизация под конкретную нагрузку: Структура выбирается под паттерны доступа (чтение/запись). Например, в документных БД все связанные данные часто вкладывают в один документ для быстрого чтения.

С точки зрения QA Engineer

Понимание этих структур критически важно для:

1. Проектирования тестов: Понимание, как данные организованы, помогает создавать тестовые сценарии на CRUD-операции, граничные случаи и миграции данных.
2. Валидации данных: Проверка целостности вложенных структур, соответствия ожидаемым форматам (JSON-схемы) в условиях отсутствия строгой схемы БД.
3. Тестирования производительности: Знание партиционирования и индексации (например, вторичные индексы в MongoDB или SAI в Cassandra) позволяет оценивать скорость запросов по разным ключам.
4. Работа с eventual consistency: Во многих распределенных NoSQL БД (кап-теорема, PACELC) данные между репликами синхронизируются не мгновенно. Нужно тестировать поведение системы в условиях такой согласованности.

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

инженер должен не только понимать эти модели, но и знать специфику работы выбранной СУБД (например, язык запросов, особенности индексов, настройки согласованности).