CNCF спонсировал этот пост.
TiKV — это распределенная транзакционная база данных «ключ-значение» с открытым исходным кодом. Растущие приложения требуют стабильной производительности, а неожиданные скачки задержки записи, особенно во время приема файлов таблицы сортированных строк (SST), ухудшали предсказуемость в TiKV. Тем не менее, мы нашли основную причину и внесли два усовершенствования, которые практически устраняют эти задержки, сохраняя при этом корректность. Эти улучшения повышают производительность TiKV при высокой нагрузке, интенсивном перемещении данных или прерывистой записи.
В чем была проблема?
Когда TiKV принимает внешние файлы SST (через IngestExternalFile), ему иногда приходится блокировать запись на переднем плане. Это связано с тем, что при приеме SST необходимо сохранять глобальный порядок последовательности данных в MemTables и принимаемых данных. Если диапазоны ключей SST перекрывают данные в MemTable, TiKV запускает очистку MemTable, что приводит к остановке записи. Поскольку один экземпляр RocksDB — базовое хранилище для TiKV — охватывает все регионы узла TiKV, проблема в одном регионе может ухудшить задержку записи на всем узле.
Рисунок 1. На каждом узле TiKV размещено несколько регионов, все из которых поддерживаются одним экземпляром RocksDB. Во время приема SST остановка записи в одном регионе влияет на все остальные на том же узле.
Что мы сделали: два основных исправления
Два улучшения TiKV были сделаны для уменьшения задержки записи.
1. Меньше смывайте, меньше глохните
Во-первых, мы изменили способ обработки перекрытия MemTable при приеме:
- Сначала попытайтесь принять данные с помощью параметраallow_blocking_flush = false.
- Если это не помогло, выполните сброс за пределами критического пути остановки записи.
- Затем повторите попытку приема с помощью параметраallow_blocking_flush = true.
Благодаря этой оптимизации (см. TiKV#3775) многие операции записи, которые раньше останавливались, теперь выполняются нормально. В ходе испытаний время простоя сократилось до 100 раз в худших сценариях с перекрытием.
2. Устранение задержек с помощью скоординированного проглатывания плюс безопасность
Чтобы пойти дальше, мы разрешили продолжать прием SST, при этом запись по-прежнему разрешена (даже если может произойти перекрытие) в сочетании с механизмами безопасности:
- Разрешите прием с помощью параметраallow_write = true, поэтому запись на переднем плане больше не должна останавливаться.
- Чтобы обеспечить безопасность (отсутствие конфликта между одновременной записью и сборкой мусора/приемом мусора), мы добавили блокировки диапазона для затронутых диапазонов ключей. Это гарантирует, что не будут обрабатываться перекрывающиеся записи, которые могут нарушить порядок последовательности. (Реализовано через TiKV#18096.)
Благодаря этому запись в большинстве случаев вообще не останавливается во время приема.
Измеримые результаты
Как вы можете видеть ниже, мы увидели значительные улучшения в задержках и производительности записи.
1. Время ожидания потока записи P9999 уменьшено с 25 миллисекунд до 2 мс.
Рисунок 2. Устранение задержек записи значительно сократило время ожидания P9999 в худшем случае более чем на 90 % для потоков записи.
2. Задержка записи P99 уменьшена с 2-4 мс до 1 мс.
Рисунок 3. После оптимизации задержка записи P99 стала стабильно низкой и предсказуемой.
Что это означает на практике: операции записи становятся гораздо более предсказуемыми под нагрузкой, даже во время таких операций, как разделение регионов, ребалансировка или очистка GC. Эта стабильность имеет большое значение в производственных системах, где скачки микрозадержек перерастают в видимые пользователем задержки.
Почему RocksDB имеет значение
RocksDB, как базовое хранилище для TiKV, обеспечивает гарантию согласованности, увеличивая глобальные порядковые номера даже для данных в разных компонентах хранилища (MemTables, уровни SST, внешние SST). Без тщательного обращения перекрывающиеся диапазоны ключей во время приема SST приводят к принудительному сбросу MemTable, что приводит к зависаниям. Наши оптимизации соблюдают те же гарантии, изменяя, когда и как происходят сбросы, или вообще избегая их, когда это возможно.
Что это значит для вас
Если у вас есть опасения по поводу задержки хвоста (P99/P999/P9999) по следующим причинам:
- частый прием данных (ребалансировка, миграция, пакетная загрузка)
- внезапные всплески записи
… тогда эти изменения в TiKV обеспечивают значительные преимущества: меньшее время ожидания в худшем случае, более стабильная задержка записи и меньшее количество неожиданностей в рабочей среде.
То, что казалось узкой проблемой — задержки записи во время приема SST — на самом деле оказалось мощным рычагом для улучшения, поскольку мы уменьшали или удаляли задержки в TiKV почти во всех ситуациях.
KubeCon + CloudNativeCon North America 2025 пройдет 10–13 ноября в Атланте, штат Джорджия. Зарегистрируйтесь сейчас.
Фонд Cloud Native Computing Foundation (CNCF) размещает критически важные компоненты глобальной технологической инфраструктуры, включая Kubernetes, Prometheus и Envoy. CNCF — это нейтральная площадка для сотрудничества, объединяющая ведущих разработчиков отрасли, конечных пользователей и поставщиков. Узнайте больше Последние новости от CNCF TRENDING STORIES YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Цзиньпэн Чжан — главный инженер PingCAP, сопровождающий и коммиттер TiKV, участник RocksDB и автор книги «Принципы и реализация MariaDB». В основном он занимается проектированием и разработкой облачных крупномасштабных распределенных систем хранения данных. Подробнее от Цзиньпэн Чжан
