You could directly use secondary indexes on the other fields instead of handling yourself your indexes :
Define your global id (can be UUID), and have columns loginName, email etc with a secondary index. Retrieval will then be fast. 2011/11/7 Felix Sprick <fspr...@gmail.com>: > Hallo, > > We are implementing a Cassandra-backed user database. The challange in > this is that there are 4 different sort of user IDs that all need to > be indexed in order to access user data via them quickly. For example > the user has a unique UUID, but also a LoginName and an email address, > which can all be used for authentication. > > How do I model this in Cassandra? > > My approach would be to have one main "table" which is indexed by the > most frequently used lookup value as row-key, lets say this is the > UUID. This table would contain all customer data. Then I would create > a index "table" for each of the other login alternatives, where I just > reference to the UUID. So each alternative login which is not using > the UUID would require two Cassandra queries. Are there any better > approaches to model this? > > Also, I read somewhere that Cassandra is not optimized for these > "reference tables" which are very short with two columns only. What is > the reason for that? > > thanks, > Felix > -- sent from my Nokia 3210
