incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Jones <MJo...@imagehawk.com>
Subject RE: OrderPreservingPartitioner limits and workarounds
Date Thu, 29 Apr 2010 16:38:44 GMT
Sounds like you want something like http://oss.oetiker.ch/rrdtool/

Assuming you are trying to store computer log data.

Do you have any other data that can spread the data load?  Like a machine name?  If so, you
can use a hash of that value to place that "machine"  randomly on the net, then append the
timestamp, this groups each machine on the ring (assuming you don't have a massive # of writes
about each machine at one time).....

-----Original Message-----
From: prescod@gmail.com [mailto:prescod@gmail.com] On Behalf Of Paul Prescod
Sent: Wednesday, April 07, 2010 5:52 AM
To: cassandra user
Subject: OrderPreservingPartitioner limits and workarounds

I have one append-oriented workload and I would like to know if
Cassandra is appropriate for it.

Given:

 * 100 nodes

 * an OrderPreservingPartitioner

 * a replication factor of "3"

 * a write-pattern of "always append"

 * a strong requirement for range queries

My understanding is that there will exist 3 nodes will end up being
responsible for all writes and potentially a disproportionate amount
of reads (in the common case that users care more about recent data
than older data).

Is there some manual way I can fiddle with InitialTokens and
ReplicationFactors to share the load more fairly?

 Paul Prescod

Mime
View raw message