Thanks so much Ryan for the links; I'll definitely take them into consideration.
Just another thought which came to my mind:- perhaps it may be beneficial to store(or duplicate) some of the data like the Login credentials & particularly userId to User's Name mapping, etc (which is very heavily read), in a fast MyISAM table. This could solve the problem of keys though auto-generated unique & sequential primary keys. I could use the same keys for Cassandra rows for that user. And also since Cassandra reads are relatively slow, it makes sense to store data like userId to Name mapping in MyISAM as this data would be required after almost all queries to the database. Regards -Asil On Fri, Feb 4, 2011 at 10:14 PM, Ryan King <r...@twitter.com> wrote: > On Thu, Feb 3, 2011 at 9:12 PM, Aklin_81 <asdk...@gmail.com> wrote: >> Thanks Matthew & Ryan, >> >> The main inspiration behind me trying to generate Ids in sequential >> manner is to reduce the size of the userId, since I am using it for >> heavy denormalization. UUIDs are 16 bytes long, but I can also have a >> unique Id in just 4 bytes, and since this is just a one time process >> when the user signs-up, it makes sense to try cutting down the space >> requirements, if it is feasible "without any downsides"(!?). >> >> I am also using userIds to attach to Id of the other data of the user >> on my application. If I could reduce the userId size that I can also >> reduce the size of other Ids, I could drastically cut down the space >> requirements. >> >> >> [Sorry for this question is not directly related to cassandra but I >> think Cassandra factors here because of its tuneable consistency] > > Don't generate these ids in cassandra. Use something like snowflake, > flickr's ticket servers [2] or zookeeper sequential nodes. > > -ryan > > > 1. http://github.com/twitter/snowflake > 2. > http://code.flickr.com/blog/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/ >
