It was just an example to showcase how i want to implement it, and I have even added that this entierly depends upon what you want and what the scenario is, i'm thinking of using this for articles that we are storing, and the number is big. thinking of making each values as column name itself.
Once I am done with its intial designing I'll share with you guys. If at any moment i feel that it won't work, will update in that case also. On Sun, Apr 11, 2010 at 3:58 PM, Mark Robson <mar...@gmail.com> wrote: > On 11 April 2010 07:59, Lucifer Dignified <vineetdan...@gmail.com> wrote: > >> For a very simple query wherin we need to check username and password I >> think keeping incremental numeric id as key and keeping the name and value >> same in the column family should work. >> > > It is highly unlikely that your application has enough usernames/passwords > that you need Cassandra to store them in. > > If you have < 1Bn rows, I really think you should reconsider whether > Cassandra is the best solution. > > Remember that you pay for Cassandra's high availability / scalability > features with a lack of these other features (secondary indexes, joins, > query optimiser) - be sure it's worth it. > > There are workarounds, but they essentially involve rewriting your RDBMS to > use Cassandra as a back-end. This is not a simple task, nor one which should > be necessary. > > Remember that if you have SOME big data, and some small data, you don't > need to keep it all in the same place. A common use-case is to keep your big > stuff (heavy write workloads etc) in Cassandra and the others in a more > familiar database. > > Mark >
