Перейти к основному содержимому
Версия: 2.0.x

Кэш данных (Data Cache)

Начиная с версий v1.5.2, Selena представила Data Cache для ускорения запросов в cluster с разделяемыми данными (shared-data), заменив File Cache в более ранних версиях. Data Cache загружает данные из удалённого хранилища блоками (порядка МБ) по мере необходимости, тогда как File Cache загружает целые файлы данных каждый раз в фоновом режиме, независимо от того, сколько строк данных фактически требуется.

По сравнению с File Cache, Data Cache имеет следующие преимущества:

  • Меньше чтений из объектного хранилища, что означает меньшую стоимость доступа к объектному хранилищу (если ваше объектное хранилище взимает плату на основе частоты доступа).
  • Меньше нагрузки на запись на локальные диски и использование CPU, следовательно, меньше влияния на другие задачи загрузки или запросов (поскольку фоновые потоки загрузки больше не нужны).
  • Оптимизированная эффективность кэша (поскольку File Cache может загружать менее часто используемые данные в файле).
  • Оптимизированный контроль над кэшированными данными, что позволяет избежать переполнения локальных дисков из-за избыточных данных, которые не удалось вытеснить File Cache.

Включение Data Cache

Начиная с версии v1.5.2, Selena использует единый экземпляр Data Cache для запросов к внешним catalog и облачным нативным таблицам (в cluster с разделяемыми данными).

Настройка Data Cache

Вы можете настроить Data Cache, используя следующие параметры конфигурации CN(BE):

Каталог кэша

  • storage_root_path (В cluster с разделяемыми данными этот параметр используется для указания корневого пути, где хранятся кэшированные данные.)

Размер диска кэша

Размер диска кэша в cluster с разделяемыми данными принимает большее значение между datacache_disk_size и starlet_star_cache_disk_size_percent.

Просмотр статуса Data Cache

  • Выполните следующий оператор для просмотра корневого пути, где хранятся кэшированные данные:

    SELECT * FROM information_schema.be_configs
    WHERE NAME LIKE "%storage_root_path%";

    Обычно кэшированные данные хранятся в подкаталоге datacache/ вашего storage_root_path.

  • Выполните следующий оператор для просмотра максимального процента хранилища, который может использовать Data Cache:

    SELECT * FROM information_schema.be_configs
    WHERE NAME LIKE "%starlet_star_cache_disk_size_percent% or %datacache_disk_size%";

Мониторинг Data Cache

Selena предоставляет различные метрики для мониторинга Data Cache.

Шаблоны панелей мониторинга

Вы можете скачать следующие шаблоны Grafana Dashboard в зависимости от вашей среды Selena:

Важные метрики

fslib read io_latency

Записывает задержку чтения Data Cache.

fslib write io_latency

Записывает задержку записи Data Cache.

fslib star cache meta memory size

Записывает приблизительное использование памяти Data Cache.

fslib star cache data disk size

Записывает фактическое использование диска Data Cache.

Отключение Data Cache

Чтобы отключить Data Cache, вам нужно добавить следующую конфигурацию в файл конфигурации CN cn.conf и перезапустить узлы CN:

datacache_enable = false
storage_root_path =

Очистка кэшированных данных

Вы можете очистить кэшированные данные в экстренных случаях. Это не повлияет на исходные данные в вашем удалённом хранилище.

Следуйте этим шагам для очистки кэшированных данных на узле CN:

  1. Удалите подкаталог, в котором хранятся данные.

    Пример:

    # Предположим, что `storage_root_path = /data/disk1;/data/disk2`
    rm -rf /data/disk1/datacache/
    rm -rf /data/disk2/datacache/
  2. Перезапустите узел CN.

Примечания по использованию

  • Если свойство datacache.enable установлено в false для облачной нативной таблицы, Data Cache не будет включён для этой таблицы.
  • Если свойство datacache.partition_duration установлено на определённый временной диапазон, данные за пределами этого временного диапазона не будут кэшироваться.
  • После понижения версии cluster с разделяемыми данными с v1.5.2 и более ранних версий, если вы хотите повторно использовать кэшированные данные в Data Cache, вам нужно вручную переименовать Blockfile в каталоге starlet_cache, изменив формат имени файла с blockfile_{n}.{version} на blockfile_{n}, то есть удалить суффикс с информацией о версии. Более поздние версии совместимы с форматом имени файла, поэтому вам не нужно выполнять эту операцию вручную. Вы можете изменить имя, запустив следующий shell-скрипт:
#!/bin/bash

# Замените <starlet_cache_path> на каталог Data Cache вашего cluster, например, /usr/be/storage/starlet_cache.
starlet_cache_path="<starlet_cache_path>"

for blockfile in ${starlet_cache_path}/blockfile_*; do
if [ -f "$blockfile" ]; then
new_blockfile=$(echo "$blockfile" | cut -d'.' -f1)
mv "$blockfile" "$new_blockfile"
fi
done

Известные проблемы

Высокое использование памяти

  • Описание: Когда cluster работает в условиях низкой нагрузки, общее использование памяти узла CN значительно превышает сумму использования памяти каждого модуля.
  • Идентификация: Если сумма fslib star cache meta memory size и fslib star cache data memory size занимает значительную долю от общего использования памяти узла CN, это может указывать на эту проблему.
  • Затронутые версии: v1.5.2 и более ранние патч-версии, и v1.5.2 и более ранние патч-версии
  • Исправленные версии: v1.5.2
  • Решения:
    • Обновите cluster до исправленных версий.
    • Если вы не хотите обновлять cluster, вы можете очистить каталог ${storage_root_path}/starlet_cache/star_cache/meta узлов CN и перезапустить узлы.

Вопросы и ответы

В1: Почему каталог Data Cache занимает гораздо больше места на диске (наблюдаемого через команды du и ls), чем фактический размер кэшированных данных?

Дисковое пространство, занимаемое Data Cache, представляет историческое пиковое использование и не связано с текущим фактическим размером кэшированных данных. Например, если кэшировано 100 ГБ данных, размер данных станет 200 ГБ после compaction. Затем, после сборки мусора (GC), размер данных был уменьшен до 100 ГБ. Однако дисковое пространство, занимаемое Data Cache, останется на пиковом уровне 200 ГБ, хотя фактические кэшированные данные внутри составляют 100 ГБ.

В2: Автоматически ли Data Cache вытесняет данные?

Нет. Data Cache вытесняет данные только при достижении лимита использования диска (80% дискового пространства по умолчанию). Процесс вытеснения не удаляет данные; он просто помечает дисковое пространство, хранящее старый кэш, как пустое. Новый кэш затем перезапишет старый кэш. Поэтому, даже если происходит вытеснение, использование диска не уменьшится и не повлияет на фактическое использование.

В3: Почему использование диска остаётся на настроенном максимальном уровне и не уменьшается?

См. В2. Механизм вытеснения Data Cache не удаляет кэшированные данные, а помечает старые данные как перезаписываемые. Следовательно, использование диска не уменьшится.

В4: Почему использование диска Data Cache остаётся на том же уровне после того, как я удалил таблицу и файлы таблицы удалены из удалённого хранилища?

Удаление таблицы не запускает удаление данных в Data Cache. Кэш удалённой таблицы будет постепенно вытеснен со временем на основе логики LRU (Least Recently Used) Data Cache, и это не влияет на фактическое использование.

В5: Почему фактическое использование диска достигает 90% или более, хотя настроено 80% ёмкости диска?

Использование диска Data Cache точное и не превысит настроенный лимит. Избыточное использование диска может быть вызвано:

  • Файлами журналов, генерируемыми во время работы.
  • Core-файлами, генерируемыми при сбоях CN.
  • Постоянными индексами таблиц Primary Key (хранятся в ${storage_root_path}/persist/).
  • Смешанными развёртываниями экземпляров BE/CN/FE, использующих один и тот же диск.
  • Проблемами с диском, например, используется файловая система ext3.

Вы можете выполнить du -h . -d 1 в корневом каталоге диска или подкаталогах, чтобы проверить конкретные каталоги, занимающие пространство, а затем удалить неожиданные части. Вы также можете уменьшить лимит ёмкости диска Data Cache, настроив starlet_star_cache_disk_size_percent.

В6: Почему существует значительная разница в использовании диска Data Cache между узлами?

Невозможно обеспечить согласованное использование кэша между узлами из-за врождённых ограничений одноузлового кэширования. Пока это не влияет на задержку запросов, различия в использовании кэша допустимы. Это расхождение может быть вызвано:

  • Различным временем добавления узлов в cluster.
  • Различиями в количестве tablet, принадлежащих разным узлам.
  • Различиями в размере данных, принадлежащих разным tablet.
  • Различиями в ситуациях compaction и GC между узлами.
  • Узлами, испытывающими сбои или проблемы нехватки памяти (OOM).

В итоге, различия в использовании кэша зависят от множества факторов.