I admit about missing details. Sorry for that. The thing is that I was looking for guidance at the high-level so we can then sort out myself what fits our requirements and use-cases (mainly because we are at the stage that they could be molded according to hardware and software limitations/features.) So, for example if it is recommended that ' for heavy reads physical is better etc.')
Anyway, just to give you a quick recap: 1- Cassandra 1.2.8 2- Row is a unique userid and can have one or more columns. Every cell is basically a blob of data (using Avro.) All information is in this one table. No joins or other access patters. 3- Writes can be both in bulk (which will of course has less strict performance requirements) or real-time. All writes would be at the per userid, hence, row level and constitute of adding new rows (of course with some column values) or updating specific cells (column) of the existing row. 4- Reads are per userid i.e. row and 90% of the time random reads for a user. Rather than in bulk. 5- Both reads and write interfaces are exposed through REST service as well as direct Java client API. 6- Reads and writes, as mentioned in 3&4 can be for 1 or more columns at a time. Regards, Shahab On Thu, Sep 12, 2013 at 1:51 AM, Aaron Turner <synfina...@gmail.com> wrote: > > > > > On Wed, Sep 11, 2013 at 4:40 PM, Shahab Yunus <shahab.yu...@gmail.com>wrote: > >> Thanks Aaron for the reply. Yes, VMs or the nodes will be in cloud if we >> don't go the physical route. >> >> " Look how Cassandra scales and provides redundancy. " >> But how does it differ for physical machines or VMs (in cloud.) Or after >> your first comment, are you saying that there is no difference whether we >> use physical or VMs (in cloud)? >> > > They're different, but both can and do work... VM's just require more > virtual servers then going the physical route. > > Sorry, but without you providing any actual information about your needs > all you're going to get is generalizations and hand-waving. > > > >
