• Glossary
  • Support
  • Downloads
  • DataStax Home
Get Live Help
Expand All
Collapse All

Developing applications with DataStax drivers

    • Getting started
    • Best practices
    • Connecting to the database
      • Connecting to DataStax Astra databases
      • Authentication in DataStax drivers
      • Using SSL in DataStax drivers
      • Load balancing with DataStax drivers
      • Connection pooling
      • Retry policies
      • Reconnection policies
      • Execution profiles
    • Submitting queries
      • Working with multi-workload clusters
      • Using DSE Search with the DataStax drivers
      • Submitting DSE Graph queries with the DataStax drivers
      • Result paging with DataStax drivers
      • Synchronous and asynchronous query execution
      • Managing concurrency in asynchronous query execution
      • Speculative query execution
      • Query idempotence
      • Driver metrics
      • Object mappers in DSE drivers
      • Query timestamps
    • Error handling
      • Server errors
      • Client errors
    • Example applications
      • Connecting to Astra
      • Executing CQL statements
      • Executing bound statements
  • Developing applications with DataStax drivers
  • Submitting queries
  • Working with multi-workload clusters

Working with multi-workload clusters

There are several different ways to query the data stored in DataStax Enterprise (DSE), above and beyond that of Apache Cassandra™. These access patterns are enabled by what are known as workloads in DSE. The DataStax drivers can query clusters with different workload types. Below are the different workloads that DSE offers to extend a multi-model experience to developers.

  • DSE Core: transactional, typically through standard Cassandra CQL queries

  • DSE Search: filtering, typically through Lucene queries

  • DSE Analytics: computation, typically through Spark jobs

  • DSE Graph: relationships, typically through TinkerPop traversals

When developing an application, each workload type requires different techniques to effectively leverage the use case covered by the workload.

Before creating applications, study and understand the DSE deployment architecture. Developers need to know which datacenters make up a DSE cluster and the supported workloads to direct the different types of queries to the appropriate datacenter.

For example, to use a solr_query in the application, the target datacenter must have DSE Search enabled. To execute graph traversals from the application, the connected datacenter must have DSE Graph enabled. Transactional queries can typically be made against any datacenter, as this core functionality is present for all workloads.

The DataStax drivers expose load balancing policies as a means to steer from the application. The load balancing policy can be supplied in the execution profiles or while configuring the driver cluster and session objects. Use the datacenter-aware policy to restrict queries to a specified datacenter.

Execution profiles

For the drivers that support execution profiles, define separate profiles for the different workloads used in the application. For example, if there are two datacenters, one with DSE Search enabled and one with DSE Core only, use a SearchExecutionProfile to direct the DSE Search queries to the DSE Search datacenter. For the SearchExecutionProfile, pass the DSE Search datacenter as the local datacenter in the DCAware load balancing policy. This profile can then be passed to all execution methods that use DSE Search indexes in the queries. These queries will be directed to the datacenter that supports DSE Search workloads.

Driver instance per workload

For drivers that do not support execution profiles, use separate driver instances for the different workloads used in the application. This is similar to the execution profile mechanics except that the local datacenter is passed to the load balancing policy when creating the driver instance. For example, create a SearchSession with the DSE Search datacenter configured as the local datacenter in the load balancing policy. Use this SearchSession in the application for all queries that use DSE Search indexes.

DSE Core and DSE Search

Plain CQL queries and CQL queries that use the solr_query syntax for DSE Search are natively supported in the DataStax drivers through the synchronous and asynchronous execute methods.

Table 1. CQL queries for drivers

C/C++

C#

Java

Node.js

PHP

Python

Ruby

DSE Graph

DSE Graph queries are supported in the DataStax drivers through dedicated graph methods. We strongly recommend using the DSE Graph Fluent API (similar to TinkerPop’s ByteCode API) to execute graph queries. The String API is also available (similar to TinkerPop’s Script API) for the drivers that do not support the Fluent API.

Table 2. DSE Graph queries for drivers

C/C++

C#

Java

Node.js

PHP

Python

Ruby

DSE Analytics

DSE Analytics queries are supported by these drivers:

  • Simba ODBC Driver for Apache Spark

  • Simba JDBC Driver for Apache Spark

  • Spark DSE Connector

Submitting queries Using DSE Search with the DataStax drivers

General Inquiries: +1 (650) 389-6000 info@datastax.com

© DataStax | Privacy policy | Terms of use

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries.

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries.

Kubernetes is the registered trademark of the Linux Foundation.

landing_page landingpage