← Cloudflare Workers KV / kv / concepts

Как работает KV

KV представляет собой глобальное хранилище данных «ключ-значение» с низкой задержкой. Данные хранятся в небольшом числе централизованных дата-центров, а после обращения кешируются в дата-центрах Cloudflare.

KV поддерживает исключительно высокие объёмы чтения при низкой задержке, что позволяет создавать масштабируемые динамические API благодаря встроенному кешированию и глобальному распределению KV. Запросы, которые не найдены в кеше и требуют обращения к центральным хранилищам, могут выполняться с более высокой задержкой.

Когда вы записываете данные в KV, они сохраняются в центральных хранилищах данных. Данные не отправляются автоматически в кеш каждой точки присутствия.

При первом обращении к данным в определённом месте закешированного значения ещё нет. Данные считываются сначала с ближайшего регионального уровня, затем с центрального уровня, и при по-настоящему холодном глобальном чтении в конечном счёте поступают из центральных хранилищ. Хотя первое обращение медленное в глобальном масштабе, последующие запросы выполняются быстрее, особенно если они сосредоточены в одном регионе.

Частые обращения на чтение из одного и того же места возвращают закешированное значение без обращения к каким-либо другим источникам, что обеспечивает максимально быстрый отклик. KV заранее обновляет закешированные значения в фоновом режиме, подгружая их из кешей более высокого уровня и центральных хранилищ данных, до того как истечёт срок действия кеша.

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

KV оптимизирован для приложений с интенсивным чтением. Данные хранятся централизованно, а для их попадания в кеш используется гибридная модель репликации push/pull. KV подходит для сценариев, где запись выполняется относительно редко, а чтение должно быть быстрым и частым. Редко запрашиваемые значения подгружаются из других дата-центров или из центральных хранилищ, а более популярные значения кешируются именно в тех дата-центрах, откуда их запрашивают.

Чтобы повысить производительность KV, увеличьте cacheTtl параметр относительно значения по умолчанию в 60 секунд.

KV достигает высокой производительности за счёт кэширование ↗ из-за чего согласованность чтения с записью достигается не сразу, а через некоторое время.

Обычно изменения сразу становятся видимыми в той точке глобальной сети Cloudflare, где они были внесены. В остальных точках сети изменения могут стать видимыми через 60 секунд или дольше, пока не истечёт срок действия закэшированных версий данных.

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

KV достигает высокой производительности за счёт согласованности в конечном счёте. В той точке присутствия глобальной сети Cloudflare, где были внесены изменения, они, как правило, становятся видимыми немедленно. Однако это не гарантируется, и полагаться на такое поведение не рекомендуется. В других точках присутствия глобальной сети изменения могут становиться видимыми только через 60 секунд или дольше, по мере истечения срока действия закешированных версий данных.

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

Один из способов добиться согласованности при последовательных записях заключается в том, чтобы направлять все операции записи для конкретного ключа KV через соответствующий экземпляр Durable Object, а затем считывать это значение из KV в других Workers. Такой подход полезен, если вам нужен больший контроль над записью, но при этом вас устраивают описанные выше характеристики чтения KV.

Workers KV представляет собой периферийное хранилище «ключ-значение» с моделью согласованности в конечном счёте. Благодаря этому оно отлично подходит для с преобладанием чтения, рабочих нагрузок с высокой кэшируемостью, например:

• Раздача статических файлов
• Хранение конфигурации приложения
• Хранение пользовательских настроек
• Реализация списков разрешений и запретов
• Кеширование

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

Если у вас есть с преобладанием записи Redis ↗-типа, где один и тот же ключ обновляется десятки или сотни раз в секунду, KV не будет оптимальным решением. Если вы можете пересмотреть подход к записи в отдельные пары ключ-значение и распределить запись между несколькими разными ключами, Workers KV сможет удовлетворить ваши потребности. В качестве альтернативы, Durable Objects предоставляет API ключ-значение с более высокими лимитами частоты записи на ключ.

См. Документация по безопасности данных чтобы понять, как Workers KV защищает данные.