To ensure your usage of EdgeKV is successful, it's worth spending some time considering the design of your data model. Let's start by reviewing a logical diagram of the EdgeKV data model.
The root element of the data model is a key-value pair which provides:
- A key (string) that is a pointer to a value
- A value (can be string or JSON format)
Each key-value pair is called an Item. You can organize Items into a collection called a Group.
Groups are logical containers for Items, and you can create an unlimited number of groups in EdgeKV. Groups are typically created by individual developers or development teams to:
- Organize similar data within a namespace
- Ensure that a set of related keys can be retrieved together
- Avoid key potential name collision
In EdgeKV a group is a container for the items stored in your database.
This is different from Akamai Control Center permission groups. Every Akamai contract includes at least one permission group to help you organize your objects and resources. Permission groups are also the primary mechanism for allowing or blocking access to those objects. To learn more about Akamai Control Center permission groups, refer to the About the access control model in the Identity and Access Management documentation.
Groups cannot be manually created and deleted. They are automatically created or destroyed on demand when items are added and deleted from the group.
Groups subsequently roll up to a Namespace object.
Namespaces, while also a logical container of data, are a scarce resource in EdgeKV, and should be used for groupings that are more durable over time. A good example of a namespace is “all the KV data for the EMEA business unit.” Namespaces provide:
- Logical separation of data within an organization.
- The ability to reuse group/item key names between different projects or divisions without having to worry about potential name collisions.
- The ability to specify the storage location for data within the namespace using the
- Lets administrators define user access and permissions to namespaces using Akamai Control Center group membership. For more information see, Manage access to EdgeKV.
geoLocation parameter helps to optimize performance by storing data where most or all of your users are located. By default, the geoLocation is set to
US (United States). The available geoLocations on the production network also include
EU (Europe) and
geoLocationparameter defaults to
USon the staging network. Setting it to a different geoLocation on the staging network is not supported.
To change the geoLocation on the production network you need to create a new namespace with the new geoLocation and copy the data to the new namespace. Once complete, you can contact Akamai to delete the old namespace. At the moment you can only use the EdgeKV API to specify the geoLocation.
Data written to the namespace is replicated across several key locations within the specified geoLocation. For example, if
US is the specified geoLocation, data is replicated across locations in the Eastern U.S., Western U.S., and other locations. When data is requested, and it's not available on the edge server making the request (a cold hit), it is requested from the closest replicated location within the specified namespace geoLocation.
Finally, the Account layer is the connection to your company’s existing account in Akamai Control Center. In order to use EdgeKV, you must be a registered user under your Akamai corporate account. Once EdgeKV is provisioned on contract, you may freely access the product as a registered user within the account. You can find detailed instructions for managing users, roles, and permissions at Akamai in the Identity and Access Management online help.
EdgeKV uses what is known in distributed computing as an eventual consistency model to perform writes and updates. This model achieves high availability with low read latency by propagating data writes globally. The period of time it takes the system to distribute data globally is called the “inconsistency window.”
During the inconsistency window, if a read operation is attempted immediately after a write operation, it can return stale data until all nodes are updated. If you perform a read operation after the inconsistency window expires, the response will return the latest data. This should occur within 10 seconds, but can vary depending on network conditions.
The inconsistency window also applies to an EdgeWorker that writes data into EdgeKV. For example, a read operation after a write from EdgeKV is not guaranteed to return the written value until the inconsistency window expires.
For more information see the Helper library.
Updated 11 months ago