Thanks Sargun,
1. Keys do get exposed to client. We recently learnt about this limitation of javascript and we will convert the keys to String when they get to javascript. 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 bucket name. 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" <sar...@sargun.me> wrote: >I have questions for your question. > >1. What are you using your keys for? Do they get passed around in to >clients in Javascript? This is important because Javascript only >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.man...@getzephyr.com> wrote: >> Hi, >> >> 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 >>node >> coordination, k-sorted. But we would prefer a uncoordinated numeric >>Unique >> Ids. >> >> - Shailesh >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
