Точный механизм истечения TTL и исключения на основе RocksDB

Redis

Эта статья подготовлена ​​технической командой OPPO Internet.Если вам необходимо перепечатать, пожалуйста, укажите источник и автора. Добро пожаловать в наш публичный аккаунт: OPPO_tech

Parker — распределенная система хранения KV на базе RocksDB, разработанная OPPO Internet.Это Redis-подобная система хранения.В основном она решает проблему переполнения памяти и времени восстановления, с которой сталкиваются пользователи, использующие Redis, а также стоимость одного главного и нескольких подчиненных устройств. , Большое, дорогое оборудование, не способное хранить большие объемы данных и другие проблемы.

1. Знакомство с Паркером

Паркер имеет следующие особенности:

  • Поддержка массового хранилища: емкость хранилища одного кластера может достигать сотен ТБ, а пиковое значение TPS одного кластера в режиме онлайн может достигать миллионов.

  • Поддержка горизонтального расширения: емкость хранилища, производительность чтения и записи могут быть горизонтально расширены за счет добавления машин. Благодаря сегментированию данных (слоту) разные сегменты распределяются по разным узлам, чтобы обеспечить масштабируемость емкости хранилища и производительность чтения и записи.

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

  • Совместимость с некоторыми протоколами Redis: внешний коммуникационный протокол Parker совместим с протоколом Reids Cluster, поддерживает типы String и Hash и соответствующие рабочие функции, то есть пользователи могут читать данные в Parker через клиент Redis.

  • Поддержка функции TTL: после записи фрагмента данных, если он превышает отметку времени, указанную TTL, срок его действия истечет, он будет удален и не будет виден пользователям. Это требует от Parker своевременного удаления данных с истекшим сроком действия и освобождения места на диске, занятого данными с истекшим сроком действия.

2. Проблемы

Мы развернули 8 экземпляров Parker на сервере хранения емкостью 5 ТБ, и срок действия записанных данных истекает через 3 дня. Ожидается, что при балансировке скорости записи данных и скорости перезапуска с истекшим сроком один экземпляр объем памяти 300 Гб.

На самом деле, Паркер обнаружил, что использование диска продолжало расти после пяти дней работы.В первые три дня записи использование диска резко возросло, а затем, хотя скорость роста замедлилась, общая скорость роста все еще оставалась относительно низкой. быстро, что серьезно отклонялось от ожидаемого эффекта. Хотя данные не могут быть прочитаны после истечения TTL, дисковое пространство не освобождается вовремя, что приводит к высокой загрузке диска.

3. Анализ причин

3.1 Принцип работы RocksDB

Базовый механизм хранения Parker использует RocksDB, а базовым хранилищем данных RocksDB является архитектура LSM. Данные разделены на разные слои, по умолчанию — 7 слоев, а стили уплотнения по умолчанию выбирают сжатие по уровням. Как показано ниже:

Когда пользователи записывают данные в RocksDB, они сначала записывают данные в Memtable, а когда Memtable заполнена, она становится неизменной. RocksDB сбросит Memtable на диск через поток сброса в фоновом режиме, сгенерирует файл Sorted String Table (SST) и поместит его на уровень 0. Когда количество файлов SST на уровне 0 превышает пороговое значение, они будут объединены с уровнем 1 с помощью стратегии уплотнения и т. д.

Если сжатия нет, то запись идет очень быстро, но это снизит производительность чтения, а также вызовет серьезные проблемы с увеличением пространства. Чтобы сбалансировать отношения между записью, чтением и пространством, RocksDB будет выполнять сжатие в фоновом режиме для объединения SST разных уровней.

3.2 Принцип реализации ТТЛ

В RocksDB есть функция CompactionFilter, что означает, что RocksDB будет вызывать функцию фильтра при сжатии каждого фрагмента данных Это функция-ловушка, которую пользователь может настроить. Метод реализации TTL заключается в реализации логики удаления TTL с истекшим сроком действия в функции фильтра Конкретная реализация выглядит следующим образом:

  1. При записи данных в Parker мы добавляем четырехбайтный TTL в конец значения данных, взяв за пример тип String, конкретный формат кодирования данных показан на следующем рисунке:

  1. В функции Filter мы реализуем следующую логику: вытаскиваем TTL в конце данных и сравниваем с текущим временем, если TTL меньше, чем данные на текущий момент, данные считаются просроченными и не будет объединен в следующий файл, чтобы достичь цели удаления данных.

3.3 Анализ проблемы

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

Тщательно разберитесь с принципом сжатия RocksDB: Условием запуска RocksDB поуровневого сжатия является то, что размер или количество файлов на этом уровне превышает верхний предел.Например, если общий размер файлов уровня 2 превышает 10 ГБ, уплотнение будет срабатывает, и будет вызван фильтр сжатия для фильтрации данных с просроченным TTL.

Основываясь на проблемах, с которыми мы столкнулись, включая принципы анализа RocksDB, мы обнаружили, что: В нашем сценарии около 380 ГБ данных попадут на уровень 4, хотя срок действия большей части этих данных истек, но из-за этого уровня данных уровня нет. не удалось достичь верхнего предела емкости 1 ТБ, поэтому не запускать фильтр уплотнения, в результате чего устаревшие данные не удаляются, дисковое пространство не может быть восстановлено.

4. Решения

Простое изменение конфигурации RocksDB для уменьшения верхнего предела емкости хранилища каждого уровня может решить вышеуказанные проблемы, но это решение не является универсальным. Разные сценарии использования, разный объем хранимых данных, при изменении объема хранимых данных необходимо перезапускать сервис для изменения конфигурации RocksDB, что неприемлемо для бизнеса.

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

  • Бизнес реализует логику удаления с истекшим сроком действия и активно удаляет просроченные данные.
  • Благодаря механизму сжатия RocksDB данные с истекшим сроком действия удаляются при запуске сжатия.

Чтобы быстро освободить место на диске и удалить устаревшие данные, мы объединили принципы RocksDB, чтобы найти следующие решения:

4.1 Логика удаления бизнес-реализации

Активно удаляйте просроченные данные с помощью собственной логики Parker. Промышленность высоко оценила KV, который использует аналогичную схему. Конкретный метод заключается в том, чтобы сохранить существующее семейство столбцов хранилища без изменений, добавить другое семейство столбцов для специального хранения TTL ключа, а затем использовать горутину для удаления данных с истекшим сроком действия в соответствии с текущей меткой времени в соответствии с триггером синхронизации, например 1 утра или триггер каждый раз и т. д. Правила кодирования ключей в этом семействе столбцов следующие:

  • ключ: метка времени + тип ключа + значение ключа

  • значение: хранить байт, представляющий разные типы данных

Преимущество этого решения в том, что скорость восстановления высокая, а время восстановления управляемо, но недостаток в том, что реализация сложна, и в крайних случаях TPS будет снижена на 50%.

4.2 Схема OpenDbWithTTL

Это схема истечения срока действия и удаления данных, поддерживаемая самой RocksDB. Схема заключается в том, чтобы открыть БД через определенный API и следовать политике истечения срока действия TTL для всех ключей, записанных в БД. Например, если TTL составляет 3 дня, то данные, записанные в БД. Срок действия ключа автоматически истечет через три дня после его записи. Нижний слой схемы также реализуется через фильтр уплотнения, что означает, что хотя просроченные данные невидимы для пользователей, но место на диске не будет вовремя восстановлено, кроме того, схема негибкая и не может устанавливать TTL для каждого ключа.

4.3 Активно активировать уплотнение RocksDB

Основная причина, по которой пространство не может быть быстро восстановлено в настоящее время, заключается в том, что данные накапливаются в определенном слое, и этот слой не запускает уплотнение, тогда мы можем вручную вызвать функцию CompactionRange RocksDB, чтобы вызвать фильтр уплотнения для достижения цели. быстрого освобождения места на диске. Однако активный вызов CompactionRange приведет к приостановке собственного уплотнения RocksDB, что вызовет остановку записи и приведет к очень серьезным последствиям.Все такие решения не идеальны.

4.4 Periodic compaction + dynamic compaction

Основной принцип периодического сжатия заключается в добавлении параметра Period_compaction_seconds и записи времени создания каждого файла SST. Каждую секунду Period_compaction_seconds файл SST активно сжимается для восстановления проседающего файла SST, а динамическое уплотнение задается установкой для параметра level_compaction_dynamic_level_bytes значения true для выполнять динамическое слияние вместо слияния на следующий уровень в порядке уровней, что делает уплотнение более частым. Это решение реализовано элегантно, не требует изменения существующей структуры кода, а требует лишь изменения некоторых конфигураций.

По сравнению с вышеприведенными схемами схема 4 более совершенна, а изменения в логике реализации небольшие, поэтому мы провели экспериментальную проверку на схеме 4.

5. Экспериментальная проверка

5.1 Конфигурация машины

CPU ОЗУ диск
64 ядра 188GB 5.9TB Nvme-SSD

5.2 Новая конфигурация RocksDB

  • Версия RocksDB: 6.4.6
  • level_compaction_dynamic_level_bytes = истина;
  • Periodic_compaction_seconds=3600;

5.3 Результаты испытаний

Мы записываем строковые данные в хранилище Parker KV: общее количество записей: 30000000000 (три миллиарда) фрагментов данных, один фрагмент данных составляет около 170 байт. Срок действия каждого фрагмента данных составляет 10800 с после времени записи, то есть он истекает через 3 часа записи, скорость записи составляет 51 МБ/с, а общий объем записи оценивается в 5,32 Тб. Использование диска на машине выглядит следующим образом:

5.4 Анализ результатов

  1. В первые 3 часа, поскольку срок действия записанных данных не истек, скорость использования диска увеличивается почти линейно, примерно на 51 МБ/с (то есть примерно на 180 ГБ/ч), т.к. сама RocksDB сжимает данные, Таким образом, диск вырос примерно на 520 ГБ.

  2. Начиная с 4-го часа данные начали устаревать, но поскольку SST-файлов, запускающих периодическое уплотнение, не так много, а dynamic_level включен, само уплотнение происходит относительно часто, а SST-файлы, которые не обновлялись более 1h относительно немного, и даже если запущено периодическое сжатие и меньше ключей для удаления, скорость роста диска значительно снизилась за этот час, но общее использование диска все еще растет, а записанный диск пространство больше, чем восстановленное пространство.

  3. С 4-го по 5-й час число ключей с истекшим сроком действия стало увеличиваться, а также увеличилось количество SST-файлов, вызывающих периодическое уплотнение.В это время записываемое дисковое пространство и удаляемое дисковое пространство примерно уравновешивались.Темп роста значительно снизился, приблизившись к нулю.

  4. В идеале после 5-го часа скорость использования диска должна колебаться вокруг некоторой горизонтальной линии, конечно, с 5-го по 9-й час этот интервал в основном соответствует идеальной ситуации.

  5. Как видно из рисунка, в 20:00 девятого часа скорость использования диска резко упала.Просмотрев анализ логов RocksDB, было обнаружено, что большое количество файлов SST запускало периодическое уплотнение в этот период, а затем все было удалено. , количество файлов SST на уровне 6 резко сократилось почти на 500. Поскольку в это время срок действия ключей большинства файлов истек, и все они перезапускаются после запуска сжатия, поэтому перезапись диска в этот период превышает объем записанных данных.

  6. После того, как использование диска резко упадет, файлы SST, которые запускают периодическое уплотнение, также будут относительно уменьшаться, что приведет к небольшому увеличению использования диска.Из рисунка видно увеличение использования диска в 10-й и 11-й часы.Количество увеличилось опять таки.

  7. В течение длительного периода времени после этого коэффициент использования диска оставался в основном сбалансированным. В течение этого периода можно считать, что есть 3 часа записи тома, срок действия которого не истек, этот неистекший объем составляет около 600 ГБ, а использование диска в это время достигло 900 ГБ, что означает, что пространство увеличено почти в 1,5 раза. .

  8. В период с 11:00 до 13:00 7 ноября мы замедлили скорость записи, и общая пропускная способность упала с 58 МБ/с до 10 МБ/с. в течение этого времени.Уменьшение, то есть скорость записи уменьшается, количество истечения срока действия не уменьшается, скорость повторного использования диска остается неизменной, скорость повторного использования больше, чем скорость записи, и скорость использования диска уменьшается. .

  9. Остановить запись данных в 11:50 7 ноября, пропускная способность записи Parker падает до 0, и в это время в Parker все еще много данных с истекшим сроком действия.В это время использование диска явно снижается, и оно упало до определенный уровень.

  10. Согласно самой идеальной ситуации, он должен быть восстановлен до горизонтальной линии, написанной в начале, но идеал может быть только идеальным, в итоге показатель использования диска стабилен на уровне 10,239%, что на 3,622% больше, чем у исходное 6,617%, то есть на диске 218гб.Оно не было восстановлено, эта часть данных будет восстановлена ​​при перезапуске записи.

6. Резюме

В настоящее время возможно восстановить дисковое пространство через периодическое уплотнение + TTL, и мы суммируем следующие правила:

В ходе мониторинга установлено, что периодическое уплотнение оказывает определенное влияние на загрузку ЦП, то есть чем меньше время Period_compaction_seconds, тем выше загрузка ЦП. На самом деле это легко понять: RocksDB более активно сжимает SST-файлы, которые неизбежно потребляют больше ресурсов процессора, поэтому рекомендуется настроить этот параметр на 12 часов.

Теоретически предполагается, что восстановление данных с истекшим сроком действия будет происходить с задержкой примерно в Period_Compaction_seconds во всей RocksDB, что приведет к некоторому увеличению пространства, поэтому во время развертывания необходимо зарезервировать определенное количество свободного места на диске. рекомендуется резервировать 30% избыточного пространства хранения.

7. Ссылки

1.GitHub.com/Facebook/RO…

2.Специальность Youzan.com/yes-use-cards…

3.MySQL.taobao.org/monthly/201…

4.GitHub.com/Facebook/RO…

5.Специальности.Meituan.com/2018/11/22/…

6.www.cockroachchina.cn/?p=1282

Категории