Rate quotas

Large deployments tend to have multiple applications cohabiting in the same Aerospike Database cluster. A new application using the cluster may consume more disk IO than expected. Similarly, an increase in traffic to a single application may affect the latency of others.

One way for an operations team to mitigate this risk is to use rate quotas, which were introduced in Aerospike Database Enterprise Edition 5.6. Rate quotas, specified in records per second, can independently limit an application's reads and writes.

Quota Assignment

• You use asadm to assign rate quotas to custom roles. These roles are then assigned to users. There are separate read and write rate quotas.

See Enable Access Control and, use asadm: Access Control to configure users for examples.

• Assigned rate quota values apply at each server node. For example, a read quota of 1000 transactions per second (TPS) applies at each server node, regardless of cluster size.
• You do not have to assign rate quotas to track TPS and record reads per second (RPS) for each client application. The show users statistics command in asadm added in tools 8.4.0 (asadm 2.15.0) displays these rates. For more information about rate quotas, see enable-quotas.
• A user's limits are derived from the user's roles. If a user has more than one role with a read quota, the largest of those read quotas takes precedence and is enforced. Likewise for write quotas. If none of the user's roles has a quota, then there are no limits on the number of reads and writes that the user can perform.
• The user's derived read quota and write quota count toward operations they perform on any set they have access to.

note

The records_per_second query field has an effective lower limit of 100. Even though it accepts a value less than 100 without an error, it will not decrease the TPS below this limit.

Counting Toward a Quota

• Reads and primary index (PI) queries, including aggregations, count against read quotas. Starting with Database 6.0, secondary index (SI) queries and aggregations also count against read quotas.
• Writes, deletes, record UDFs, PI background queries, and UDFs count against write quotas. Starting with Database 6.0, SI background queries and UDFs also count against write quotas.
• A user's computed current TPS value is based on transaction requests and is an exponential moving average (see tps-weight), thus it is possible for a user's transaction rate to briefly spike above the quota without being in violation.
• Starting with Database 6.0, PI and SI queries are screened against the appropriate quota using their specified RPS when the query request is received. If accepted, this RPS counts against the quota. If a query's specified RPS, combined with the user's current TPS, plus any other currently accepted queries' RPS, do not breach the quota, then the requested query is allowed to run. Otherwise it is rejected.
• Prior to Database 6.0, quotas only applied to PI queries, and PI queries were referred to as "scans".
• Query requests from users who have quotas must specify an RPS in the PI or SI query policy.

note

The quota mechanism behaves as a circuit breaker, not as a throttle. The user and client application must reduce transaction requests when a quota is violated.

When a query request exceeds the quota, the server returns error code 83 QUOTA_EXCEEDED.