# Limiting the cardinality of a key range **URL:** \ **Category:** Using FoundationDB\ **Created:** [August 26, 2018, 6:47pm UTC](https://forums.foundationdb.org/t/limiting-the-cardinality-of-a-key-range/665 "2018-08-26T18:47:07Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![George](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/george/32/620_2.png) [@George](https://forums.foundationdb.org/u/George)\ **Post date:** [August 26, 2018, 6:47pm UTC](https://forums.foundationdb.org/t/limiting-the-cardinality-of-a-key-range/665/1 "2018-08-26T18:47:07Z")
Sorry if this should be obvious, but I was wondering if there was a preferred mechanism for limiting a key range to some cardinality (i.e. “messages/\* should have no more than 10,000 keys”). The documentation points out that offsets are O(n) complexity, so it seems expensive to do a clear(start + 10,000, end) with every transaction affecting that key range. Does this becomes easier if the constraint is relaxed? (i.e. “messages/\* should not have _significantly_ more than 10,000 keys”). ---
**Author:** ![ajbeamon](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ajbeamon/32/13_2.png) [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)\ **Post date:** [August 27, 2018, 5:05pm UTC](https://forums.foundationdb.org/t/limiting-the-cardinality-of-a-key-range/665/3 "2018-08-27T17:05:16Z")
If you want to support limiting the size of a range while supporting concurrency, you’ll probably need to rely on atomic operations to keep track of its size. There is some discussion about that here: > [@Getting the number of key/value pairs](https://forums.foundationdb.org/t/getting-the-number-of-key-value-pairs/189): > > Sorry if this is something obvious but i have been looking for a way to quickly get the total number of keys / values in the database. I know status shows total size and utilization of the database but is there a simple way to get the total number of key value pairs? > [@George](#): > > Does this becomes easier if the constraint is relaxed? (i.e. “messages/\* should not have _significantly_ more than 10,000 keys”). Depending on the nature of your writes, if you are willing to enforce this at write time (rather than by clearing keys after having exceeded the limit), you could disallow writes to messages when the counter exceeds 10,000. If you have lots of concurrent writers and/or if they are each writing lots of keys to “messages”, then the counter could exceed this limit by a sizable margin. If you instead want to be able to estimate where the 10,000th key is and then clear all keys after that, then you could try something like what Dave described in the link above called the ranked set. Alec provides a more detailed description here: > [@How to model a Leaderboard](https://forums.foundationdb.org/t/how-to-model-a-leaderboard/373/9): > > There’s another solution that I don’t think I’ve seen here that doesn’t require a background job or reading through the entire data set, but it does involve doing multiple reads from the database’s data structures. But then as soon as your data are inserted, you can start querying your index, which might be a desirable property. The basic idea is to persist a skip list in FDB. Each level of the skip list is kept as a contiguous range, and the keys in each level are the indexed values (probably … And there’s an implementation of the idea here in C#, though I haven’t looked at it to see how closely it matches the previous descriptions: >