Re: cassandra database design

2016-09-01 Thread Stone Fang
Thanks,Carlos. the key point is how to balance the data spread around the cluster and the partition number of query. it is hard to determine which is best.anyway,thanks for your suggestion.it help me a lot. stone On Thu, Sep 1, 2016 at 4:54 PM, Carlos Alonso wrote: > I guess there's no easy sol

Re: cassandra database design

2016-09-01 Thread Carlos Alonso
I guess there's no easy solution for this. The bucketing technique you were applying with the publish_pre extra field making a composite partition key is probably your best bet but you're right being concerned that all your workload will hit the same node during an hour. I'd then suggest adding a

Re: cassandra database design

2016-08-31 Thread Stone Fang
access pattern is select *from datacenter where datacentername = '' and publish>$time and publish<$time On Wed, Aug 31, 2016 at 8:37 PM, Carlos Alonso wrote: > Maybe a good question could be: > > Which is your access pattern to this data? > > Carlos Alonso | Software Engineer | @calonso

Re: cassandra database design

2016-08-31 Thread Carlos Alonso
Maybe a good question could be: Which is your access pattern to this data? Carlos Alonso | Software Engineer | @calonso On 31 August 2016 at 11:47, Stone Fang wrote: > Hi all, > have some questions on how to define clustering key. > > have a table like this > > CR

cassandra database design

2016-08-31 Thread Stone Fang
Hi all, have some questions on how to define clustering key. have a table like this CREATE TABLE datacenter{ datacentername varchar, publish timestamp, value varchar, PRIMARY KEY(datacentername,publish) } *issues:* there are only two datacenter,so the data would only have two partitions.an

Re: database design

2011-04-14 Thread aaron morton
In some cases you may be able to add a secondary index. Aaron On 14 Apr 2011, at 03:11, Edward Capriolo wrote: > On Wed, Apr 13, 2011 at 10:39 AM, Jean-Yves LEBLEU wrote: >> Hi all, >> >> Just some thoughts and question I have about cassandra data modeling. >> >> If I understand well, cassan

Re: database design

2011-04-13 Thread Victor Kabdebon
Dear Jean-Yves, You can have a different approach of the problem. You need on one side a relational database (MySQL, PostGreSQL) or SolR (as an very efficient index) and on the other side Cassandra. The relational database or SolR must contain the minimum amount of information possible : a date an

Re: database design

2011-04-13 Thread Edward Capriolo
On Wed, Apr 13, 2011 at 10:39 AM, Jean-Yves LEBLEU wrote: > Hi all, > > Just some thoughts and question I have about cassandra data modeling. > > If I understand well, cassandra is better on writing than on reading. > So you have to think about your queries to design cassandra schema. We > are doi

database design

2011-04-13 Thread Jean-Yves LEBLEU
Hi all, Just some thoughts and question I have about cassandra data modeling. If I understand well, cassandra is better on writing than on reading. So you have to think about your queries to design cassandra schema. We are doing incremental design, and already have our system in production and we

Re: New user asking for advice on database design

2010-04-22 Thread Zhiguo Zhang
not raised your question about put them in a separated keyspaces, but > I also appreciate any sugestion. > > Yess > > David Boxenhorn escribió: > > Hi guys! I'm brand new to Cassandara, and I'm working on a database >> design. I don't necessarily know all the ad

Re: New user asking for advice on database design

2010-04-22 Thread Yésica Rey
also appreciate any sugestion. Yess David Boxenhorn escribió: Hi guys! I'm brand new to Cassandara, and I'm working on a database design. I don't necessarily know all the advantages/limitations of Cassandra, so I'm not sure that I'm doing it right... It seems to me that

New user asking for advice on database design

2010-04-21 Thread David Boxenhorn
Hi guys! I'm brand new to Cassandara, and I'm working on a database design. I don't necessarily know all the advantages/limitations of Cassandra, so I'm not sure that I'm doing it right... It seems to me that I can divide my database into two parts: 1. The (mostly) norma