[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-05 (世界標準時間)。"],[[["\u003cp\u003eApigee offers three primary data persistence mechanisms for API proxy developers: Key Value Maps (KVMs), Property Sets, and Kubernetes Secrets (for Apigee hybrid).\u003c/p\u003e\n"],["\u003cp\u003eKey Value Maps (KVMs) are suitable for storing large amounts of data that changes frequently, accessible and modifiable at runtime through the KeyValueMapOperations policy.\u003c/p\u003e\n"],["\u003cp\u003eProperty Sets are best for configuration data known at design time, such as route rules or public keys, and they are read-only during proxy execution.\u003c/p\u003e\n"],["\u003cp\u003eKubernetes Secrets, available only in Apigee hybrid, are used for storing sensitive data that should not be in the management plane, like private keys or credentials, and are accessible to multiple proxies in the same environment.\u003c/p\u003e\n"],["\u003cp\u003eThe mechanisms differ in their scope of data access: KVM data can be accessed at the organization, environment, and API proxy levels, property set data can be accessed at environment and proxy level, and kubernetes secrets are only accessible at environment level.\u003c/p\u003e\n"]]],[],null,["# Accessing configuration data\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n\nAPI proxy developers commonly use one or more Apigee data persistence mechanisms to store configuration\ndata so they can later access it in an API proxy.\nThis topic discusses how to choose the right persistence mechanism depending on your use case.\n\nPersistence mechanisms\n----------------------\n\nThe following table briefly describes the persistence mechanisms available in Apigee:\n\nScope of persistence mechanisms\n-------------------------------\n\n\nEach of the available persistence mechanisms has a specific scope that determines where you can\naccess its stored data. The following table summarizes the available scopes for each persistence\nmechanism. For more about scopes, see [About persistence scope](/apigee/docs/api-platform/cache/key-value-maps#scope) and\n[Property\nset scopes](/apigee/docs/api-platform/cache/property-sets#scopes).\n\nDeciding which persistence mechanism to use\n-------------------------------------------\n\n\nThis section describes use cases for each persistence mechanism to help you decide\nwhich one is best suited for storing configuration data.\n\n### When to use Key Value Maps\n\n\nApigee does not provide APIs for storing, updating, or deleting KVM data. You must perform these\ntasks using the [KeyValueMapOperations policy](/apigee/docs/api-platform/reference/policies/key-value-map-operations-policy). The policy lets you perform KVM operations at runtime, when the\nproxy is executing.\n\nConsider using KVMs when:\n\n- You have thousands, hundreds of thousands, or millions of key value map entries (any number up to the [documented KVM size limits](/apigee/docs/api-platform/reference/limits)).\n- You have entries that are not known at design time.\n\n\nFor example, use KVM to store user session data when a user logs in and delete it when the\nuser logs out.\n\n### When to use property sets\n\n\nConsider using property sets when:\n\n- The keys and values are known at design time. Property set values cannot be changed by the API proxy when it is running. They are available in the proxy flow as read-only variables.\n- You have a few to few hundred keys (\\\u003c110 KB in total). Property set keys and values are always stored in memory for quick access.\n- You want the convenience of allowing administrators to change property sets in an environment without redeploying API proxies.\n\n\nFor example, property sets are good for storing route rules. Route rules are key/value pairs\nwhere values are target endpoint URLs. These values typically vary between environments and\ncan be shared by multiple API proxies deployed in an environment. Property sets can also be\na good choice for storing public keys and certificates.\n\n### When to use Kubernetes Secrets\n\n\nThis option is only available with Apigee hybrid. It allows an API proxy to access data stored in\nKubernetes Secrets. This option is similar to property sets, where stored data is available\nas message flow variables within the executing proxy. However, the data always remains within the\nruntime plane; it is never set to the management plane in the Apigee cloud.\n\n\nConsider using Kubernetes Secrets when:\n\n- You need to store sensitive information that you never want to be stored in the management plane. For example, you might use a Kubernetes Secret to store private keys or credentials required to access external systems.\n- You need to share stored data with multiple API proxies deployed in the same environment."]]
