Hi Victor, In my research and playing around with nosql, specifically cassandra, I see the true benefit in defining search requirements and then creating CF's and the hierarchy based on this. So for me, I see quite a bit of simplicity in defining alternate CF's to allow me to efficiently find a specific row. For example, I have a CF for users with uid as the key and some random columns like name, birthday, etc, etc. etc. I have another CF for user emails where email is the key and the user uid the column. I am structuring my application to target specific rows based on the keys ... cheating on search. Suppose we have different definitions of simplicity ; )
With regards to your second comment, consistency, I am using Hector and using the Batch_Mutation to ensure my writes are consistent Of course, maybe I'm way off here and have missed the plot entirely. Just trying to understand if secondary indexes degrade the the core benefits of cassandra On Fri, Jan 28, 2011 at 3:43 PM, Victor Kabdebon <victor.kabde...@gmail.com> wrote: > Dear Sasha, > > I am currently thinking about using secondary index in the future. I have > seen two pros : > _Simplicity, it is "more simple" to query based on a second index than going > for a first column then a second. > _ "Consistency" : depending on where you store your inverted index, it may > be unavailable to query because of a node down, or an error allows you to > insert in the first column but then you crash and cannot insert into the > inverted your inverse information. Because of that you cannot query and you > have to periodically check the consistency of the data in the double column. > That's what I am doing right now for my applications and making it simpler > and more consistent would be great. > > Remember : I don't know the details of the implementation, I take this > principle as if it was perfectly working. > But I am interested in experiences.
