In that case, just don't delete the dead node (what I think you should
do anyways. I'm pretty sure it can't be deleted if you're going to
replace it with -Dcassandra.replace_address=...).
I was speaking about the case that you _do_ want it replaced. You can
just delete it and bootstrap a new node.
Hi,
I am doing stress test on Datastax Cassandra Community 2.1.2, not using the
provided stress test tool, but use my own stress-test client code instead(I
write some C++ stress test code). My Cassandra cluster is deployed on Amazon
EC2, using the provided Datastax Community AMI( HVM instances )
B would work better in the case where you need to do sequential or ranged
style reads on the id, particularly if id has any significant sparseness
(eg, id is a timeuuid). You can compute the buckets and do reads of entire
buckets within your range. However if you're doing random access by id,
The official recommendation is 100k:
http://www.datastax.com/documentation/cassandra/2.0/cassandra/install/installRecommendSettings.html
I wonder if there's an advantage to this over unlimited if you're running
servers which are dedicated to your Cassandra cluster (which you should be
for
It depends on the size of your data, but if your data is reasonably small,
there should be no trouble including thousands of records on the same
partition key. So a data model using PRIMARY KEY ((seq_id), seq_type)
ought to work fine.
If the data size per partition exceeds some threshold that
Based on recent conversations with Datastax engineers, the recommendation
is definitely still to run a finite and reasonable set of column families.
The best way I know of to support multitenancy is to include tenant id in
all of your partition keys.
On Fri Dec 05 2014 at 7:39:47 PM Kai Wang
On Sat, Dec 6, 2014 at 8:05 AM, Eric Stevens migh...@gmail.com wrote:
The official recommendation is 100k:
http://www.datastax.com/documentation/cassandra/2.0/cassandra/install/installRecommendSettings.html
I wonder if there's an advantage to this over unlimited if you're running
servers
On Sat, Dec 6, 2014 at 11:18 AM, Eric Stevens migh...@gmail.com wrote:
It depends on the size of your data, but if your data is reasonably small,
there should be no trouble including thousands of records on the same
partition key. So a data model using PRIMARY KEY ((seq_id), seq_type)
ought
Generally, limit a Cassandra cluster low hundreds of tables, regardless of
number of keyspaces. Beyond low hundreds is certainly an “expert” feature and
requires great care. Sure, maybe you can have 500 or 750 or maybe even 1,000
tables in a cluster, but don’t be surprised if you start running
There are two categorically distinct forms of multi-tenancy: 1) You control the
apps and simply want client data isolation, and 2) The client has their own
apps and doing direct access to the cluster and using access control at the
table level to isolate the client data.
Using a tenant ID in
+1 well said Jack!
On Sun, Dec 7, 2014 at 6:13 AM, Jack Krupansky j...@basetechnology.com
wrote:
Generally, limit a Cassandra cluster low hundreds of tables, regardless
of number of keyspaces. Beyond low hundreds is certainly an “expert”
feature and requires great care. Sure, maybe you can
11 matches
Mail list logo
