ID generation techniques
shailesh.mangal at getzephyr.com
Wed Aug 20 18:14:04 EDT 2014
1. Keys do get exposed to client. We recently learnt about this limitation
2. Considering Bitcask as storage choice due to its performance, but we
are open for levelDB as well. BTW, We already have tenantId (UUID) in the
3. Coming from RDBMS background, we are used to seeing incremental Ids.
K-sort is not a hard requirement but nice to have.
On 8/20/14, 11:03 AM, "Sargun Dhillon" <sargun at sargun.me> wrote:
>I have questions for your question.
>1. What are you using your keys for? Do they get passed around in to
>reliably implements IEEE 754 floating point, which is limited to 53
>bits of precision.
>2. What backend are you using? In Bitcask, your keyspace is "costly"
>whereas in LevelDB, keys on disk are "cheap." Additionally, having
>k-sorted writes helps your story around levelDB compactions?
>3. Is there any reason you want them K-sorted, other than to make
>LevelDB compactions a bit nicer?
>On Wed, Aug 20, 2014 at 10:23 AM, Shailesh Mangal
><shailesh.mangal at getzephyr.com> wrote:
>> I wanted to ask what are popular, scalable ID generation techniques for
>> storing data in RIAK. Some ideas that we are toying with:
>> ID Generation server (like Flikr ticket server) - Numeric
>> Twitter's Snowflake like implementation- Alphanumeric
>> Riak¹s auto ID generation- Alphanumeric
>> So far, we are thinking of going with option 2 as it doesn¹t require
>> coordination, k-sorted. But we would prefer a uncoordinated numeric
>> - Shailesh
>> riak-users mailing list
>> riak-users at lists.basho.com
More information about the riak-users