Working with multi-workload clusters
The DataStax drivers can query clusters with different workload types.
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.
| 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.
| C/C++ | C# | Java | Node.js | PHP | Python | Ruby |