NoSQL

NoSQL #

1. NoSQL типы БД #

ТипПримерОсобенностиКогда использовать
ДокументныеMongoDBJSON-документы, гибкая структураДинамические, неструктурированные данные
Ключ-значениеRedis, DynamoDBМаксимально быстрый доступКэш, данные с уникальными ключами
Колонко-ориентированныеCassandraХранение по колонкамАналитика, обработка больших данных
ГрафовыеNeo4jУзлы и связиМоделирование сложных связей между данными

2. Для чего используется Redis? #

Redis — это высокопроизводительная NoSQL база данных, которая работает в оперативной памяти (in-memory), обеспечивая минимальные задержки. Основное назначение Redis — хранение данных в виде ключ-значение.


3. Что такое Кэш? #

Кэш — это временное хранилище данных, созданное для ускорения повторного доступа к ним.

Преимущества:

  • Ускорение: Данные быстрее извлекаются из кэша, чем из основного хранилища.
  • Экономия ресурсов: Уменьшение нагрузки на сервер базы данных.
  • Снижение задержек: Быстрый доступ к часто используемым данным.

Пример:

  • Кэширование результата SQL-запроса:
    1. Пользователь делает запрос к базе данных.
    2. Результат сохраняется в Redis.
    3. Повторный запрос возвращает данные из кэша Redis.

Подходы к настройке инвалидации кэша

Инвалидация кэша необходима для обеспечения актуальности данных в кэше. Существует несколько основных подходов:

  1. Time-to-Live (TTL)
  • Описание: Устанавливается время жизни данных в кэше. После истечения этого времени данные удаляются автоматически.

  • Преимущества: Простота настройки, минимальная нагрузка на систему.

  • Недостатки: Возможна работа с устаревшими данными до истечения TTL.

  • Пример:

    redis.set(key, value, 60); // Удаление через 60 секунд
    

  1. Manual Invalidation
  • Описание: Инвалидация данных выполняется вручную, например, при обновлении данных в основной базе данных.

  • Преимущества: Полный контроль над процессом.

  • Недостатки: Возможен человеческий фактор — забыть удалить данные из кэша.

  • Пример: Удаление ключа после изменения записи в базе.

    redis.del("user:123");
    

  1. Write-Through
  • Описание: Данные сначала записываются в кэш, а затем в основное хранилище.

  • Преимущества: Актуальность данных в кэше всегда гарантирована.

  • Недостатки: Запись медленнее из-за двойной операции (кэш + база).

  • Пример: Обновление данных пользователя.

    redis.set("user:123", updatedData);
    database.update(user);
    

  1. Read-Through
  • Описание: Если данных нет в кэше, они автоматически загружаются из базы данных и сохраняются в кэш.

  • Преимущества: Удобство и минимизация кэш-промахов.

  • Недостатки: Первая загрузка данных занимает больше времени.

  • Пример: Ленивое заполнение кэша.

    String value = redis.get(key);
    if (value == null) {
        value = database.query(key);
        redis.set(key, value);
    }
    

  1. Cache-Aside
  • Описание: Приложение сначала проверяет кэш. Если данных нет, оно загружает их из базы, обновляет кэш и возвращает данные.

  • Преимущества: Гибкий и широко используемый подход.

  • Недостатки: Требуется ручное управление данными в кэше и их синхронизация.

  • Пример:

    String value = redis.get(key);
    if (value == null) {
        value = database.query(key);
        redis.set(key, value);
    }
    

  1. Event-Driven Invalidation
  • Описание: Кэш автоматически обновляется при изменении данных в основной базе с помощью событий (например, через очередь сообщений).

  • Преимущества: Данные в кэше всегда актуальны.

  • Недостатки: Сложность реализации, необходимость обработки событий.

  • Пример: Отправка события при обновлении базы.

    eventBus.publish("userUpdated", userId);
    

Локальный vs распределенный кэш

КритерийЛокальный кэшРаспределенный кэш
РасположениеВ памяти одного узла (сервер/процесс).Общий для нескольких узлов.
Пример реализацииConcurrentHashMap, Guava Cache.Redis, Memcached.
ПроизводительностьВысокая (минимальная задержка).Зависит от сети и задержек доступа.
МасштабируемостьОграничена памятью одного узла.Масштабируется для распределенных систем.
ДоступностьТолько для локального узла.Доступен для всех участников системы.
СложностьПрост в реализации.Требует настройки и управления сетью.
Инвалидация данныхУникальна для каждого узла.Единая для всех узлов.
ПрименениеПодходит для одиночных серверов.Идеален для микросервисов и кластеров.