Hi Zoltan,
you must try to avoid multi partition queries as much as possible. Instead,
use asynchronous queries to grab several partitions concurrently.
Try to send no more than ~100 queries at the same time to avoid DDOS-ing
your cluster.
This would leave you roughly with 1000+ async queries gro
Querying by (doc_id and element_id ) OR just by (element_id) is fine, but
the real question is, will it be efficient to query 100k+ primary keys in
the elements table?
e.g.
SELECT * FROM elements WHERE element_id IN (element_id1, element_id2,
element_id3, element_id100K+) ?
The elements_id
Keep in mind there are side effects to increasing to RF = 4
- Storage requirements for each node will increase. Depending on the
number of nodes in the cluster and the size of the data this could be
significant.
- Whilst the number of available coordinators increases, the number of
Have one table hold document metadata (doc_id, title, description, ...) and
have another table elements where partition key is doc_id and clustering
key is element_id.
Only problem here is if you need to query and/or update element just by
element_id but I don't know your queries up front.
On Sun,
Dear cassandra users,
We have the following structure in MySql:
documents->[doc_id(primary key), title, description]
elements->[element_id(primary key), doc_id(index), title, description]
Notation: table name->[column1(key or index), column2, …]
We want to transfer the data to Cassandra.
Each
Prefixing with the ks is best practice, since it allows you to use a single
session for multiple keyspaces. Otherwise you'd have to have a desicated
session and set the keyspace by calling cluster.connect(ks)
On Sun, Mar 26, 2017 at 19:39 S G wrote:
> Thanks, got it working now :)
>
> Just wish t
Thanks, got it working now :)
Just wish that an error like:
"Table x not found in keyspace y"
would have been much better than:
"Table x not configured".
On Sat, Mar 25, 2017 at 6:13 AM, Arvydas Jonusonis <
arvydas.jonuso...@gmail.com> wrote:
> Make sure to prefix the table with the keysp
Yes, throughput for a given partition key cannot be improved with
horizontal scaling. You can increase RF to theoretically improve
throughput on that key, but actually in this case smart clients might hold
you back, because they're probably token aware, and will try to serve that
read off the key'
