Alternator or CQL¶

What is Alternator?¶

ScyllaDB launched in 2015 with support for Cassandra’s CQL API. In 2019, ScyllaDB added the DynamoDB-compatible API called “Alternator.” Alternator is not a separate product from ScyllaDB. It’s an integrated feature within the same database system that allows ScyllaDB to process DynamoDB API requests alongside traditional CQL requests. It provides the following benefits:

1. Processes HTTP requests with JSON payloads.

2. Uses the same installation as standard ScyllaDB

3. Requires minimal configuration changes:

   1. Uses a port specification for Alternator traffic

   2. Offers read-modify-write operation isolation settings

A single ScyllaDB cluster can simultaneously support both CQL and DynamoDB API requests.

Compatibility¶

ScyllaDB’s Alternator project aims to achieve full compatibility with the DynamoDB API, allowing users to run unmodified applications originally designed for Amazon’s service. While most DynamoDB features are supported, some limitations exist. For example:

1. Single-item transactions are supported

2. Multi-item transactions are not currently implemented

A complete list of supported and unsupported features is maintained in the documentation.

Architectural Differences¶

DynamoDB and Alternator/ScyllaDB operate on fundamentally different architectural models:

1. DynamoDB:

   1. Multi-tenant Software as a Service

   2. Users typically unaware of underlying infrastructure

   3. Single endpoint abstracts cluster details

2. Alternator/ScyllaDB:

   1. Dedicated installation for each customer

   2. Cluster-aware architecture

   3. Node selection becomes important for request routing

The ScyllaDB Alternator for DynamoDB users docs page contains a detailed breakdown of different and not yet implemented features. Keep in mind that even if some features are not yet implemented, you might be able to achieve the same functionality in ScyllaDB in other ways.

Load Balancing¶

In traditional DynamoDB applications, a single endpoint URL (like a US-East-1 regional endpoint) is configured. Applications have no awareness of individual nodes behind that endpoint, which means they cannot:

1. Send requests to the optimal node that holds the data

2. Intelligently distribute load across available nodes in the cluster

This creates a challenge for efficiently routing requests in ScyllaDB Alternator.

Server-Side Load Balancing¶

There are two primary approaches to server-side load balancing:

1. HTTP/TCP Load Balancer

   1. Client sends requests to a load balancer

   2. Load balancer forwards to a random live node

   3. ScyllaDB then routes to the node that holds the requested data

   This approach works but requires dedicated load balancer infrastructure and adds network hops, increasing latency.

2. ScyllaDB Coordinator-Only Node

   1. Specific ScyllaDB nodes act solely as coordinators

   2. These nodes don’t store data but route requests to the appropriate data-holding nodes

Both approaches function correctly but come with infrastructure and performance costs.

Client-Side Load Balancing¶

Client-side load balancing offers a more efficient solution. Implementation follows these steps:

1. Create a wrapper around the standard Amazon SDK

2. Configure the SDK with one initial Scylla node instead of a single endpoint URL

3. The wrapper discovers the cluster topology and learns about all available nodes

4. Applications continue using unmodified API calls (get_item, put_item, etc.)

Behind the scenes, this wrapper:

1. Maintains a list of live nodes (automatically removing failed nodes)

2. Selects nodes based on geographic proximity (regions, availability zones)

3. Routes requests directly to nodes that hold the requested data when possible

The benefits include:

1. Lower infrastructure costs (no dedicated load balancer nodes)

2. Reduced networking costs (avoiding cross-availability zone traffic)

3. Improved request latency (fewer network hops)

CQL or Alternator¶

ScyllaDB implements CQL (Cassandra Query Language), which serves as a comprehensive ecosystem. CQL functions simultaneously as:

1. A query language for data retrieval

2. A protocol for client-server communication

3. A data model for structural organization

The CQL implementation in ScyllaDB encompasses everything from table design to the binary protocol used for client-server interaction.

CQL Schema Structure

CQL enforces a defined schema consisting of:

1. Partition keys (potentially composite)

2. Zero to many clustering keys

3. SQL-inspired native types

4. User-defined types (UDTs)

5. Materialized views

6. Secondary indexes and global secondary indexes

7. Change Data Capture (CDC) capabilities

DynamoDB Schema Structure

DynamoDB takes a different approach, enforcing keys rather than a complete schema:

1. Primary key

2. Sharding key

3. DynamoDB native types

4. Local secondary indexes

5. Global secondary indexes

6. DynamoDB streams (implemented as Alternator streams in ScyllaDB)

When to use each

You should generally use Alternator if either of the following is true:

1. You do not want to refactor your code to a new API, or

2. You want to start using or evaluating ScyllaDB prior to major code refactoring.

For example, you would want to use the DynamoDB API for a project where hundreds of independent Lambda services communicating with DynamoDB may require quite an effort to refactor. Or, you might use it when you rely on a connector that doesn’t provide compatibility with the CQL protocol. For all other cases, CQL is likely to be a better option. See the protocol comparison for more details.