Из чего состоят нереляционные БД

Нереляционные БД (NoSQL) — структура и устройство

Что такое нереляционные БД?

Нереляционные БД (NoSQL — "Not Only SQL") — это системы управления данными, которые НЕ используют таблицы с строками и столбцами. Вместо этого они хранят данные в других форматах: документы, ключ-значение, графы, временные ряды.

Основные типы нереляционных БД

1. Документные БД (Document Databases)

Данные хранятся как документы в формате JSON/BSON.

Примеры: MongoDB, CouchDB, Firestore

Структура:

Database
  └─ Collection (users)
       ├─ Document {
       │   "_id": "507f1f77bcf86cd799439011",
       │   "name": "John Doe",
       │   "email": "john@example.com",
       │   "age": 30,
       │   "address": {
       │     "street": "123 Main St",
       │     "city": "New York"
       │   },
       │   "hobbies": ["reading", "gaming"]
       │ }
       └─ Document {
           "_id": "507f1f77bcf86cd799439012",
           "name": "Jane Smith",
           "age": 28
         }

Особенности:

• Каждый документ может иметь разные поля (гибкая схема)
• John имеет поле address, Jane его не имеет — это OK
• Документы могут содержать вложенные объекты и массивы
• Быстрый поиск по полям документа

Что я тестирую как QA:

• Документы сохраняются с корректной структурой
• Вложенные объекты сохраняются правильно
• Поиск по полям документа работает
• Обновление части документа (не всего целиком) работает

2. Ключ-значение БД (Key-Value Stores)

Самая простая структура: ключ → значение.

Примеры: Redis, Memcached, DynamoDB

Структура:

Key          | Value
─────────────────────────
"user:123"   | {"name": "John", "age": 30}
"cart:456"   | ["item1", "item2", "item3"]
"session:789" | {"user_id": 123, "exp": 1704070800}
"page_views" | 1523  (просто число)

Особенности:

• Очень быстрый доступ (O(1) — константное время)
• Часто используется для кеша
• Redis может хранить также списки, множества, хеши
• Идеально для сессий, кеширования, real-time данных

Что я тестирую как QA:

• Значение правильно сохраняется при ключе
• Быстрота доступа (должно быть < 1ms)
• TTL (время жизни) работает — ключ удаляется после истечения
• Нет утечки памяти при большом количестве ключей

Пример Redis команд:

SET user:123 '{"name": "John"}'
GET user:123
DEL user:123
EXPIRE user:123 3600  (удаль через час)

3. Поисковые БД (Search Engines)

Оптимизированы для полнотекстового поиска больших объемов данных.

Примеры: Elasticsearch, Solr

Структура:

Index (books)
  └─ Type/Mapping (определяет структуру)
       ├─ Document {
       │   "_id": "1",
       │   "title": "The Great Gatsby",
       │   "author": "F. Scott Fitzgerald",
       │   "text": "In my younger...", (весь текст книги)
       │   "year": 1925,
       │   "rating": 4.8
       │ }

Особенности:

• Полнотекстовый поиск по всему содержимому
• Быстрый поиск даже в миллиардах документов
• Анализ текста (stemming, lemmatization)
• Фасеты (фильтры) по полям

Что я тестирую как QA:

• Поиск находит правильные результаты
• Поиск "Gatsby" находит книгу "The Great Gatsby"
• Поиск работает для разных языков
• Фасеты работают (фильтр по году, рейтингу)
• Индекс обновляется в реальном времени

Пример Elasticsearch запроса:

GET /books/_search
{
  "query": {
    "match": {
      "title": "Gatsby"
    }
  },
  "aggs": {
    "by_year": {
      "terms": {"field": "year"}
    }
  }
}

4. Граф БД (Graph Databases)

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

Примеры: Neo4j, ArangoDB

Структура:

Nodes (вершины):
- User (John) {id: 1, name: "John"}
- User (Jane) {id: 2, name: "Jane"}
- Post (P1) {id: 101, title: "Hello"}
- Post (P2) {id: 102, title: "World"}

Edges (ребра/связи):
- John --FOLLOWS--> Jane
- John --CREATED--> P1
- Jane --CREATED--> P2
- John --LIKES--> P2

Визуально:

    John ----FOLLOWS---> Jane
     |                     |
     |CREATED             |CREATED
     v                     v
    P1                    P2
     ^                     ^
     |                     |
     +-----LIKES-----------+
        (John likes P2)

Особенности:

• Идеально для социальных сетей
• Быстрый поиск связей (друзья друзей)
• Анализ пути между узлами
• Рекомендации (что нравится друзьям)

Что я тестирую как QA:

• Связи создаются правильно
• Поиск пути между узлами работает
• Удаление узла удаляет и все его связи
• Рекомендации корректны

Пример Neo4j запроса:

MATCH (john:User {name: "John"})
      -[:FOLLOWS]->(friend)
      -[:CREATED]->(post)
RETURN friend.name, post.title

Результат: покажет все посты, написанные людьми, которых следит John.

5. Временные ряды БД (Time Series Databases)

Оптимизированы для хранения данных с меткой времени.

Примеры: InfluxDB, Prometheus, TimescaleDB

Структура:

Measurement: cpu_usage

Timestamp        | Host     | Value
─────────────────────────────────────
2024-01-01 10:00 | server-1 | 45.2
2024-01-01 10:01 | server-1 | 48.5
2024-01-01 10:02 | server-1 | 52.1
2024-01-01 10:00 | server-2 | 62.3
2024-01-01 10:01 | server-2 | 65.1

Особенности:

• Оптимизация для быстрого написания (write-optimized)
• Сжатие данных
• Быстрый поиск по временному диапазону
• Агрегация (среднее, сумма, максимум за период)

Что я тестирую как QA:

• Данные с меткой времени сохраняются
• Поиск по временному диапазону работает
• Агрегация (средний CPU за день) корректна
• Удаление старых данных (retention) работает

6. Колончные БД (Column-Oriented)

Данные хранятся по столбцам, а не по строкам.

Примеры: Apache HBase, Cassandra

Структура (реляционная для примера):

(Традиционное хранение по строкам)
Row 1: id=1, name=John, age=30, city=NYC
Row 2: id=2, name=Jane, age=28, city=LA

(Колончное хранение)
Column id:   [1, 2]
Column name: [John, Jane]
Column age:  [30, 28]
Column city: [NYC, LA]

Особенности:

• Эффективно для аналитики (нужен средний age — только 1 столбец)
• Сжимаются лучше (одинаковые типы)
• Медленнее для случайного доступа к одной строке
• Идеально для big data аналитики

Сравнение нереляционных БД

Как это отличается от реляционной БД?

Реляционная БД (PostgreSQL):

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    age INT,
    email VARCHAR(100)
);
-- Строго определенная схема
-- Все пользователи имеют одинаковые поля

NoSQL документная БД (MongoDB):

{_id: 1, name: "John", age: 30, email: "john@mail.com"}
{_id: 2, name: "Jane", age: 28, hobbies: ["reading"]}
-- Гибкая схема
-- Разные поля у разных документов

Что тестировать в нереляционных БД?

1. Консистентность

• Данные сохраняются правильно
• Читаем то, что писали

2. Масштабируемость

• БД работает при миллиардах записей
• Поиск остается быстрым

3. Надежность

• Дублирование (репликация) работает
• При падении одного узла данные не теряются

4. Производительность

• Запросы выполняются за приемлемое время
• Нет bottleneck'ов

5. Индексы

• Индексы создаются корректно
• Поиск по индексу быстрее чем по всем данным

Практический пример тестирования

# Тест MongoDB
import pymongo

def test_mongodb_insert_and_retrieve():
    client = pymongo.MongoClient()
    db = client['test_db']
    collection = db['users']
    
    # Вставка
    doc = {"name": "John", "age": 30}
    result = collection.insert_one(doc)
    
    # Проверка
    found = collection.find_one({"_id": result.inserted_id})
    assert found["name"] == "John"
    assert found["age"] == 30

Заключение

Нереляционные БД имеют разные структуры в зависимости от задачи:

• Документные — для гибких данных
• Ключ-значение — для кеша и сессий
• Поисковые — для полнотекстового поиска
• Граф — для связей
• Временные ряды — для метрик
• Колончные — для аналитики

Выбор БД влияет на то, как мы её тестируем. Для QA важно понимать структуру БД, чтобы правильно проверить сохранение, поиск и консистентность данных.