HBase has the same problem.
Your choices are basically (a) figure out a way to not do all writes
sequentially or (b) figure out a way to model w/o OPP.
Most Cassandra users go with option (b).
On Thu, May 20, 2010 at 8:21 AM, Sonny Heer wrote:
> Yes, I'm using OOP, because of the way we modeled
meant to say OPP :)
On Thu, May 20, 2010 at 8:21 AM, Sonny Heer wrote:
> Yes, I'm using OOP, because of the way we modeled our data. Does
> Cassandra not handle OOP intensive write operations? Is HBase a
> better approach if one must use OOP?
>
>
> On Thu, May 20, 2010 at 7:41 AM, Jonathan Elli
Yes, I'm using OOP, because of the way we modeled our data. Does
Cassandra not handle OOP intensive write operations? Is HBase a
better approach if one must use OOP?
On Thu, May 20, 2010 at 7:41 AM, Jonathan Ellis wrote:
> Are you using OOP? That will tend to create hot spots like this,
> whi
Are you using OOP? That will tend to create hot spots like this,
which is why most people deploy on RP.
If you are using RP you may simply need to add C* capacity, or take
TimeoutException as a signal to throttle your activity.
On Tue, May 18, 2010 at 4:37 PM, Sonny Heer wrote:
> Yeah there are
Yeah there are many writes happening at the same time to any given cass node.
e.g. assume 10 machines, all running hadoop and cassandra. The hadoop
nodes are randomly picking a cassandra node and writing directly using
the batch mutate.
After increasing the timeout even more, i don't get that ex
rpctimeout should be sufficient
you can turn on debug logging to see how long it's actually taking the
destination node to do the write (or look at cfstats, if no other
writes are going on)
On Fri, May 14, 2010 at 11:55 AM, Sonny Heer wrote:
> Hey,
>
> I'm running a map/reduce job, reading from
