ScyllaDB University has many courses on how to configure, administer and get the most out of your ScyllaDB cluster. Most of them are written within the context of using our Cassandra-compatible CQL interface. With the release of ScyllaDB Open Source 4.0, we now provide content for users who are coming to ScyllaDB in the context of using its new DynamoDB®-compatible API, which we call Project Alternator.
Our first lesson is called DynamoDB API Compatibility – Project Alternator Basics. If you are already familiar with tools like git and Docker, you should be able to complete the lesson in around 12 minutes.
Overview
Alternator is an open-source project that gives ScyllaDB compatibility with Amazon DynamoDB.
In this lesson, we’ll start by introducing the project. Afterward, we’ll see a hands-on example of creating a one node ScyllaDB cluster and performing some basic operations on it.
The goal of this project is to deliver an open-source alternative to DynamoDB, deployable wherever a user would want: on-premises, on other public clouds like Microsoft Azure or Google Cloud Platform, or still on AWS (for users who wish to take advantage of other aspects of Amazon’s market-leading cloud ecosystem, such as the high-density i3en instances). DynamoDB users can keep their same client code unchanged. Alternator is written in C++ and is a part of ScyllaDB.
You can read more about it in this blog post and in the documentation.
The three main benefits ScyllaDB Alternator provides to DynamoDB users are:
- Cost: DynamoDB charges for read and write transactions (RCUs and WCUs). A free, open-source solution doesn’t.
- Performance: ScyllaDB was implemented in modern C++. It supports advanced features that enable it to improve latency and throughput significantly.
- Openness: ScyllaDB is open-source. It can run on any suitable server cluster regardless of location or deployment method.
Setting up a ScyllaDB Cluster
If you haven’t done so yet, download the example from git:
git clone https://github.com/scylladb/scylla-code-samples.gitGo to the directory of the alternator example:
cd scylla-code-samples/alternator/getting-startedNext, we’ll start a one-node cluster with Alternator enabled.
By default, ScyllaDB does not listen to DynamoDB API requests. To enable such requests, we will set the alternator-port configuration option to the port (8000 in this example), which will listen for DynamoDB API requests.
Alternator uses ScyllaDB’s LWT feature. You can read more about it in the documentation.
docker run --name some-scylla --hostname some-scylla -p 8000:8000 -d scylladb/scylla:4.0.0 --smp 1 --memory=750M --overprovisioned 1 --alternator-port=8000Wait a few seconds and make sure the cluster is up and running:
docker exec -it some-scylla nodetool statusIn this example, we will use the Python language to interact with ScyllaDB with the Boto 3 SDK for Python. It’s also possible to use the CLI or other languages such as Java, C#, Python, Perl, PHP, Ruby, Erlang, Javascript.
Next, if you don’t already have it set up, install boto3 python library which also contains drivers for DynamoDB:
sudo pip install --upgrade boto3In the three scripts create.py read.py and write.py change the value for “endpoint_url” to the IP address of the node.
Create a Table
Now, we’ll use the create.py script to create a table in our newly created cluster, using Alternator.
Authorization is not in the scope of this lesson, so we’ll use ‘None’ and revisit this in a future lesson.
We define a table called ‘mutant_data’ with the required properties such as the primary key “last_name” which is of a String data type. You can read about Boto 3 data types here.
The DynamoDB data model is similar to ScyllaDB’s. Both databases have a partition key (also called “hash key” in DynamoDB) and an optional clustering key (called “sort key” or “range key” in DynamoDB), and the same notions of rows (which DynamoDB calls “items”) inside partitions. There are some differences in the data model. One of them is that in DynamoDB, columns (called “attributes”), other than the hash key and sort key, can be of any type, and can be different in each row. That means they don’t have to be defined in advance. You can learn more about data modeling in Alternator in more advanced lessons.
In this simple example, we use a one node ScyllaDB cluster. In a production environment, it’s recommended to run a cluster of at least three nodes.
Also, in this example, we’ll send the queries directly to our single node. In a production environment, you should use a mechanism to distribute different DynamoDB requests to different ScyllaDB nodes, to balance the load. More about that in future lessons.
Run the script:
python create.pyEach Alternator table is stored in its own keyspace, which ScyllaDB automatically creates. Table xyz will be in keyspace alternator_xyz. This keyspace is initialized when the first Alternator table is created (with a CreateTable request). The replication factor (RF) for this keyspace and all Alternator tables is chosen at that point, depending on the size of the cluster: RF=3 is used on clusters with three or more live nodes. RF=1 would is used if our cluster is smaller, as is in our case. Using a ScyllaDB cluster of fewer than three nodes is not recommended for production.
Performing Basic Queries
Next, we will write and read some data from the newly created table.
In this script, we use the batch_write_item operation to write data to the table “mutant_data.” This allows us to write multiple items in one operation. Here we write two items using a PutRequest, which is a request to perform the PutItem operation on an item.
Notice that unlike ScyllaDB (and Apache Cassandra for that matter) in DynamoDB, Writes do not have a configurable consistency level. They use CL=QUORUM.
Execute the script to write the two items to the table:
python write.pyNext, we’ll read the data we just wrote, again using a batch operation, batch_get_item.
The response is a dictionary with the result, the two entries we previously wrote.
Execute the read to see the results:
DynamoDB supports two consistency levels for reads, “eventual consistency” and “strong consistency.” You can learn more about ScyllaDB consistency levels here and here. Under the hood, ScyllaDB implements Strongly-consistent reads with LOCAL_QUORUM, while eventually-consistent reads are performed with LOCAL_ONE.
More Resources
- Project Alternator Wiki, with examples (Github)
- ScyllaDB Cloud versus Amazon DynamoDB, benchmark
- Alternator Design Documentation
Conclusion
In this lesson, we learned the basics of Alternator: the open-source DynamoDB ScyllaDB API. We saw how to create a cluster, connect to it, write data, and read data. Future lessons will cover more advanced topics and more interesting examples, including data modeling, backup and restore, single region vs. multi-region, streams (CDC), encryption at rest, and more.
Sign Up for ScyllaDB University
Once you’re done reading the black, make sure you sign up for or login to ScyllaDB University to get credit for taking this course. You’ll get your own personalized certificate which you can add to your LinkedIn profile.
