Cassandra Connector¶

The Cassandra connector allows querying data stored in Apache Cassandra® or in Cassandra-compatible cluster like Astra DB, ScyllaDB, or Instaclustr.

Compatibility¶

Connector is compatible with all Cassandra versions starting from 2.1.5 and uses the DataStax Java Driver 4.19.3. Latest ScyllaDB tested is 5.1.11.

Configuration¶

To configure the Cassandra connector, create a catalog properties file etc/catalog/cassandra.properties with the following contents, replacing host1,host2 with a comma-separated list of the Cassandra nodes used to discovery the cluster topology:

connector.name=cassandra
cassandra.contact-points=host1,host2

You will also need to set cassandra.native-protocol-port if your Cassandra nodes are not using the default port (9042).

For ScyllaDB you don’t need to add any additional configuration. ScyllaDB uses the same port as Cassandra by default. Just point to ScyllaDB nodes in cassandra.contact-points config property.

Multiple Cassandra or Cassandra-compatible service Clusters¶

You can have as many catalogs as you need, so if you have additional Cassandra or Cassandra-compatible service clusters, add another .properties file to etc/catalog with a different name. For example, if you name the property file sales.properties, Presto will create a catalog named sales using the configured connector.

Configuration Properties¶

The following configuration properties are available:

The following advanced configuration properties are available:

Querying Cassandra or Cassandra-compatible service Tables¶

The users table is an example Cassandra table from the Cassandra Getting Started guide. It can be created along with the mykeyspace keyspace using Cassandra’s cqlsh (CQL interactive terminal):

cqlsh> CREATE KEYSPACE mykeyspace
   ... WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };
cqlsh> USE mykeyspace;
cqlsh:mykeyspace> CREATE TABLE users (
              ...   user_id int PRIMARY KEY,
              ...   fname text,
              ...   lname text
              ... );

This table can be described in Presto:

DESCRIBE cassandra.mykeyspace.users;

 Column  |  Type   | Extra | Comment
---------+---------+-------+---------
 user_id | bigint  |       |
 fname   | varchar |       |
 lname   | varchar |       |
(3 rows)

This table can then be queried in Presto:

SELECT * FROM cassandra.mykeyspace.users;

Data types¶

The data types mappings are as follows:

Any collection (LIST/MAP/SET) can be designated as FROZEN, and the value is mapped to VARCHAR. Additionally, blobs have the limitation that they cannot be empty.

A Cassandra vector<subtype, n> is mapped to a Presto ARRAY of the corresponding element type. The common vector<float, n> maps to ARRAY(REAL), so the column can be used directly with Presto’s vector similarity functions (cosine_similarity, dot_product, l2_squared) and CREATE VECTOR INDEX. Vector element types other than the numeric types (FLOAT, DOUBLE, INT, BIGINT, SMALLINT, TINYINT) are not supported. The maximum allowed dimension is controlled by cassandra.vector.max-dimensions.

Data types not listed in the table above, such as UDT, are not supported.

Partition keys can only be of the following types:

• ASCII

• TEXT

• VARCHAR

• BIGINT

• BOOLEAN

• DOUBLE

• INET

• INT

• FLOAT

• DECIMAL

• TIMESTAMP

• UUID

• TIMEUUID

• SMALLINT

• TINYINT

• DATE

Limitations¶

• Queries without filters containing the partition key result in fetching all partitions. This causes a full scan of the entire data set, therefore it’s much slower compared to a similar query with a partition key as a filter.

• IN list filters are only allowed on index (that is, partition key or clustering key) columns.

• Range (< or > and BETWEEN) filters can be applied only to the partition keys.

Migration from Driver 3.x¶

If you are upgrading from a previous version of Presto that used Cassandra Java Driver 3.x, please note the following changes:

Removed Configuration Properties¶

The following configuration properties are no longer supported in driver 4.x and must be removed from your configuration:

• cassandra.load-policy.use-white-list - WhiteListPolicy does not exist in driver 4.x

• cassandra.load-policy.white-list.addresses - WhiteListPolicy does not exist in driver 4.x

If you were using whitelist policy, you have these alternatives:

1. Network-level filtering: Use firewall rules or network policies to restrict which Cassandra nodes are accessible.

2. Contact points selection: Specify only the desired nodes in cassandra.contact-points. The driver will discover the cluster topology from these nodes.

3. Custom load balancing: Implement a custom load balancing policy if you need advanced node filtering logic.

Action Required: Remove these properties from your cassandra.properties configuration file:

# REMOVE THESE LINES if present:
# cassandra.load-policy.use-white-list=true
# cassandra.load-policy.white-list.addresses=node1,node2,node3

Protocol Version Changes¶

• Protocol V2 is no longer supported. Minimum supported version is V3.

• The driver automatically negotiates the highest common protocol version, so manual configuration is rarely needed.

• Protocol V5 is supported for Cassandra 4.0+.