Cassandra Java Driver- QueryBuilder API vs PreparedStatements

Question

Datastax Java driver (cassandra-driver-core 2.0.2) for Cassandra supports PreparedStatements as well as QueryBuilder API. Any specific advantages using one over the other? Disadvantages?

Documentation: http://www.datastax.com/documentation/developer/java-driver/2.0/common/drivers/reference/driverReference_r.html

The above doc does not state any advantages over using QueryBuilder API over PreparedStatements, other than writing queries programmatically, which isn't much of an advantage (in my book).

Please share your thoughts and experiences. Thanks.

Photostat

Answer 1

PreparedStatements gives you a performance boost since what you're executing is already stored server-side (assuming you re-use the statements). You just bind new concrete values and re-execute the statement.

The query builder is a fancier way of creating a string statement to be executed as is without requiring any preparation.

From a performance standpoint the first option is fastest, the second and third are identical:

// below prepared statement has already been prepared, we're now just re-using
PreparedStatement ps = session.prepare("SELECT * FROM users WHERE uname=?");

1) session.execute(ps.bind('david');
2) session.execute("SELECT * FROM users WHERE uname=david");
3) session.exectute(QueryBuilder.select()
                                .all()
                                .from("users")
                                .where(QueryBuilder.eq('uname', 'david'))

Not too sure if this is relevant but there's a good example of migrating from string execution of queries build with the query builder to using pre-built prepared statements in this ycsb client.

Banerjee

Note, you can create PreparedStatement objects from QueryBuilder chains so it's pretty easy to move from QueryBuilder to PreparedStatement – Caia