Thank you Bowen - I'm redesigning the tables now. When you give
Cassandra two parts to the primary key like
create table xyz (uuid text, source text, primary key (source, uuid));
How is the second part of the primary key used to determine partition size?
-Joe
On 3/12/2021 5:27 PM, Bowen Song
To be clear, this
CREATE TABLE ... PRIMARY KEY (k1, k2);
is the same as:
CREATE TABLE ... PRIMARY KEY ((k1), k2);
but they are NOT the same as:
CREATE TABLE ... PRIMARY KEY ((k1, k2));
The first two statements creates a table with a partition key k1 and a
clustering key k2. The 3rd
Hi Everyone,
I need to nuke a cluster and want to restore the system_auth details from a
backup - is this possible? Never restored system_auth before and thought there
was some salt on the encrypted passwords?
Thanks
-
To unsu
Great stuff - thank you. I've spent the morning here redesigning with
smaller partitions.
If I have a large number of unique IDs that I want to regularly 'do
something' with, would it make sense to have a table where a UUID is the
partition key, and create a secondary index on a field (call
It's safe to restore the system_auth keyspace. The salted_hash in the
system_auth.roles table stores the bcrypt salted hashed passwords. The
data in this column actually contains both the salt and the hash.
On 15/03/2021 17:00, Who Dadddy wrote:
Hi Everyone,
I need to nuke a cluster and want
I personally try to avoid using secondary indexes, especially in large
clusters.
SI is not scalable, because a SI query doesn't have the partition key
information, Cassandra must send it to nearly all nodes in a DC to get
the answer. Thus, the more nodes you have in a cluster, the slower and
Thank you.
What is the best way to iterate over a very large number of rows in
Cassandra? I know the datastax driver let's java do blocks of n
records, but is that the best way?
-joe
On 3/15/2021 1:42 PM, Bowen Song wrote:
I personally try to avoid using secondary indexes, especially in l
There are different approaches, depending on the application's logic.
Roughly speaking, there's two distinct scenarios:
1. Your application knows all the partition keys of the required data
in advance, either by reading them from another data source (e.g.:
another Cassandra table, other da
Keep in mind that you'll need the same tokens for each node for your
restore to work if RF < #Nodes. There is an easy way to work around this
though by setting RF=# of nodes on the system_auth keyspace (and do a
repair of it) before you take the backup, then restore system_auth to every
node. If yo
