If I don't set any read/write consistency level at all in my spring-data-cassandra project, what will be my consistency level for reads? What about writes?
(I asked this question here, but the Google Group is now locked)
The default consistency level used by the driver, if not set, is one. Since spring-data-cassandra, as they claim is:
Based on the latest DataStax Enterprise CQL Java Driver
the default CL is one.
See https://jira.spring.io/browse/DATACASS-145 & https://jira.spring.io/browse/DATACASS-146. I am working on this in branch https://github.com/spring-projects/spring-data-cassandra/tree/DATACASS-145. When DATACASS-145 is done, I can move on to DATACASS-146.
I don't think it's going to make it into 1.1.0; 1.1.1 is likely.
Related
Can someone help me on how to set consistency level separately for read and write in cassandra (cqlsh)
and one more question can we set consistency level for a keyspace?
please explain
Yes, you can set consistency level other then your default consistency level. (which you have defined while building your cluster object).
Here is the example of setting consistency level to your prepared statement.
session.prepare(<Query>).setConsistencyLevel(<consistency_level>)
If you are using JAVA driver, you can explore the enum class ConsistencyLevel defined in the datastax driver library.
import com.datastax.driver.core.ConsistencyLevel.{consistency_level}
This link might help you dmlConfigConsistency
For setting this in cqlsh you need to issue corresponding CONSISTENCY command before executing the specific query, like this:
CONSISTENCY QUORUM;
INSERT INTO ... ;
Setting the consistency level for "class" of queries is impossible in cqlsh...
You can set consistency after login CQLSH like below for read and write.
CONSISTENCY ONE/TWO; etc
https://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlshConsistency.html
Also,you can refer below for setting a Consistency Level with Prepared Statements
https://datastax.github.io/python-driver/getting_started.html
According to docs from datastax, it's good to use the cqlsh CONSISTENCY command to set the consistency level to ALL. I saw same recommendation from many other places. But why should we do that? Especially, in native protocol specification from apache-cassandra, it seems truncate query would ignore the consistency we set before.
The truncate command requires all nodes up and it will fail preemptively if anything is down regardless of consistency level. You are right that you don't need to do that.
Also CQL truncate no longer uses JMX at all (blurb at bottom), that was from thrift days before cql3 so it might be just old documentation that hasn't been updated.
While going through Datastax tutorial I learned that
1)Lower consistency level is quicker for read and write whereas, it's much longer if we use higher consistency level
2) Lower consistency level also ensures high availability of data.
My question is
if Lower CL is good then we can always set CL as ONE,
why do we need QUORUM and ALL consistency levels?
It ultimately depends on the application using Cassandra. If the application is ok with serving up data that may be under-replicated or slightly stale, then LOCAL_ONE should be fine. If the application absolutely cannot provide a wrong answer, or if written rows are not being successfully read consistently, then perhaps LOCAL_QUORUM may be more applicable.
I tell my application teams the same thing. Start with LOCAL_ONE, and and work with it through testing. If you don't have any problems, then continue using it. If you do experience stale data, and your application is more read-sensitive, then try writing at LOCAL_QUORUM and continue reading at LOCAL_ONE. And if that doesn't help, then perhaps the application may need both at QUORUM.
Again, that's why application teams need to do thorough testing.
And just to address it, ALL is a useful consistency level because it invokes a read repair. Essentially, if you have a table which you know is missing data, and you don't want to run a costly nodetool repair on it, you can set your consistency to ALL and read from it. I find this trick to be most-useful when addressing issues with multi-DC clusters having issues with system_auth.
But you probably wouldn't want to use ALL from within an application. Or if you did, it'd be for a very specific edge case.
The real meat of database like Cassandra is "eventual consistency": it won't enforce strong consistency when you first write data to the database. rather, it gives you option to choose a weaker consistency level like "one" to reach high writing performance, and then later when you query data, as long as this rule "Read_Consistency_level + Write_consistency_level >= the RF policy (Replication factor)" satisfies, you won't have stale data.
It's risky if you can't fulfill the above rule since you might get either stale or contradictory (sometimes new, sometimes old) data.
I can not find the documentation for this. I know there is a consistency command in cqlsh, but there is no distinction between read and write consistency. How would I set different consistency levels for read and write?
Furthermore, there is a mention of a "default" consistency level. Where is that default set? and is it for read or write?
How would I set different consistency levels for read and write?
If you just want to change consistency level for your current session, use CONSISTENCY.
If you want to change the consistency level programamtically, use the cassandra driver for your client language.
Since the Consistency Level can be set per-statement, you can either set it on every statement, or use PreparedStatements. If you're using the Java driver, you can configure a global Consistency level for BOTH reads and writes (but not only reads and only writes).
Where is that default [consistency level] set? and is it for read or write?
If you want to set up a different consistency level for reads than writes, you'll have to do it on a per-statement basis. Use QueryOptions().setConsistencyLevel to set a global consistency level (for the Java driver). It is for BOTH reads and writes.
To set the consistency level for your current session, use the CONSISTENCY command
from the cassandra shell (CQLSH).
For example:
Set CONSISTENCY to force the majority of the nodes to respond:
CONSISTENCY QUORUM
To see your current consistency level, just run CONSISTENCY; from the shell:
ty#cqlsh> consistency;
Current consistency level is ONE.
For programming client applications, set the consistency level using an appropriate driver.
To set a per-insert consistency level using the Java driver, for example, call QueryBuilder.insertInto with setConsistencyLevel.
For example:
PreparedStatement pstmt = session.prepare(
"INSERT INTO product (sku, description) VALUES (?, ?)");
pstmt.setConsistencyLevel(ConsistencyLevel.QUORUM);
To set a global consistency level for reads AND writes using the Java driver, do something like:
QueryOptions qo = new QueryOptions().setConsistencyLevel(ConsistencyLevel.ALL);
Since the Java driver only executes CQL statements, which can be either reads or writes to Cassandra, it is not possible to globally configure the Consistency Level for only reads or only writes. To do so, since the Consistency Level can be set per-statement, you can either set it on every statement, or use PreparedStatements. More info in the Queries and Results document.
More resources on read/write consistency levels
How consistency level is configured
The different consistency levels are also explained here ^
Cassandra's Java Driver documentation
See the "Consistency levels" section in configuring consistency with the Java Driver
Other resources on consistency:
You may also want to look into your replica placement strategy and replication factor (which are other forms of consistency).
I included links below for good measure:
Background on data replication in Cassandra
How to update replica strategy and replication factor using CREATE KEYSPACE
How consistency affects performance
By default, the Consistency Level is ONE for all R/W Operations.
Setting CL is done on a per query (read or upsert) basis by adding the CONSISTENCY XXXX syntax on the query as seen here:
https://cassandra.apache.org/doc/latest/cql/dml.html#insert
and
https://cassandra.apache.org/doc/4.0/tools/cqlsh.html
The consistency level is not set anymore with a CQL USING clause. See CASSANDRA-4734 for an explanation.
Instead, with CQLSH, you should use the CONSISTENCY command: see here for details.
Note that the default consistency level changed in all DataStax drivers from ONE to LOCAL_ONE: see the python driver documentation for details - however, in spite of using the python driver behind the scenes, CQLSH still has a default consistency of ONE).
The consisenty level is no longer set using PreparedStatement. That API was changed. Now you have to use BatchStatementBuilder.
Here is sample code that works.
BatchStatementBuilder builder = BatchStatement.builder(DefaultBatchType.UNLOGGED);
builder.setConsistencyLevel(ConsistencyLevel.LOCAL_QUORUM);
PreparedStatement preparedStatement = session.prepare("INSERT INTO \"ScottKeySpace16\".\"Movie\" (title, year, plot) values (:k0, :k1, :k2)");
builder.addStatement(preparedStatement.boundStatementBuilder()
.setString("k0", "Movie44")
.setInt("k1", 2022)
.setString("k2", "This is a very funny movie")
.build());
BatchStatement batchStatement = builder.build();
session.execute(batchStatement);
Default consistency is set in cassandra.conf file . It is for read and write .
You can set consistency per query basis adding USING option in query .
I'm wondering why this happens with the parameters N=2, RF=1, and ANY write consistency level. The error I get is:
HUnavailableException: May not be enough replicas present to handle consistency level.
Should RF be set to 2 instead? If so, why? ANY is meant to "just write it somewhere", isn't it?
(version of Cassandra is 1.2.4)
This is a bug in Hector. Cassandra will never reject a write at ANY. (Unless it's so behind on its workload that it has to refuse new writes temporarily to catch up; in that case it will return OverloadedException, not Unavailable.)
Best practice today is to use the native Java driver rather than Hector.