New answers tagged

0

With a Cassandra index (i.e. a "secondary index", as opposed to primary keys), each node has to query its own local data for responding to a query (see the Cassandra [secondary indexexes FAQ] (https://wiki.apache.org/cassandra/SecondaryIndexes)). These index are also built using a background process. This backgrounding means that the index may return false ...


2

Schema design in Cassandra, for efficient tables, will grate against your RDBMS experience; for efficiency, the Cassandra prefers denormalization, not normalization. By this, I mean that if you have some user information and you want to look up that data using two different primary keys, then using Cassandra, it actually is better to use two tables (and ...


1

Be careful about decreasing the amount of free disk space. The recommendation for cassandra 2.1 is to maintain 50-80% free space. You can read about it on the Datastax site. The free space is needed during compaction as the SStables will be streamed to disk. Depending on your compaction strategy, you can determine your disk capacity.


0

As you're accessing all the columns, then consider row based rather than columnar. Partitioning will help. Pick a column that is easy to divide into around 100 ranges, or that has 100 or so distinct values. As you are not joining to any other tables, you might as well distribute randomly. This may be faster than hashing a text column. Nothing beats trying ...


0

So I found there is a better way: you go through the API. I got the idea from this answer: http://stackoverflow.com/a/35182348/2933397 You need to access the keyspace metadata directly. So an example of how to access the schema metadata is here: Cassandra CPP driver: UDF Metadata The idea is to obtain a pointer to a CassSchemaMeta object, then you have ...



Top 50 recent answers are included