For sanity, I ran the same python script with the same row ids again today and
it was 10x faster. Must be something going wrong intermittently in my cluster.
-Allan
On April 11, 2014 at 11:02:11 AM, Allan C (alla...@gmail.com) wrote:
It’s a fairly standard relational-like CF. Description is
27;},
{column_name: 'country', validation_class: 'UTF8Type'},
{column_name: '~lastSync', validation_class: 'DateType'},
{column_name: '~nextSync', validation_class: 'DateType'},
{column_name: '~syncBlock', validati
As one CQL statement:
SELECT * from Event WHERE key IN ([100 keys]);
-Allan
On April 9, 2014 at 12:52:13 AM, Daniel Chia (danc...@coursera.org) wrote:
Are you making the 100 calls in serial, or in parallel?
Thanks,
Daniel
On Tue, Apr 8, 2014 at 11:22 PM, Allan C wrote:
Hi all,
I’ve
Hi all,
I’ve always been told that multigets are a Cassandra anti-pattern for
performance reasons. I ran a quick test tonight to prove it to myself, and,
sure enough, slowness ensued. It takes about 150ms to get 100 keys for my use
case. Not terrible, but at least an order of magnitude from wha
(!StorageService.instance.getTokenMetadata().isMember(endpoint))
return;
On Mon, Jan 20, 2014 at 12:34 PM, Allan C wrote:
There are 3 other nodes that have a mild case. This is one node is worse by an
order of magnitude. deleteHintsForEndpoint fails with the same error on any of
node or all. Did you try to delete the hints via JMX
in other nodes?
On Mon, Jan 20, 2014 at 12:18 PM, Allan C wrote:
Hi ,
I’m hitting a very odd issue with HintedHandoff on 1 node in my 12 node cluster
running 1.2.13. Somehow it’s holding a large amount of hints for tokens that
have never
Hi ,
I’m hitting a very odd issue with HintedHandoff on 1 node in my 12 node cluster
running 1.2.13. Somehow it’s holding a large amount of hints for tokens that
have never been part of the cluster. Pretty sure this is causing a bunch of
memory pressure somehow that’s causing the node to go dow
