This page comparesApache Cassandraand Spanner architecture as well as helps you understand thecapabilities and limitations of the SpannerCassandra interface. It assumes you're familiar with Cassandraand want to migrate existing applications or design new applications while usingSpanner as your database.

Cassandra and Spanner are both large-scale distributeddatabases built for applications requiring high scalability and low latency.While both databases can support demanding NoSQL workloads,Spanner provides advanced features for data modeling, querying,and transactional operations. For more information about howSpanner meets NoSQL database criteria, seeSpanner for non-relationalworkloads.

Core concepts

This section compares key Cassandra and Spannerconcepts.

Terminology

Architecture

A Cassandra cluster consists of a set of servers and storage colocatedwith those servers. A hash function maps rows from a partition keyspace to avirtual node (vnode). A set of vnodes is then randomly assigned to each serverto serve a portion of the cluster keyspace. Storage for the vnodes is locallyattached to the serving node. Client drivers connect directly to the servingnodes and handle load balancing and query routing.

A Spanner instance consists of a set of servers in areplicationtopology. Spannerdynamically shards each table into row ranges based on CPU and disk usage.Shards are assigned to compute nodes for serving. Data is physically stored onColossus, Google's distributed file system, separate from the compute nodes.Client drivers connect to Spanner's frontend servers whichperform request routing and load balancing. To learn more, see theLife of Spanner reads and writeswhitepaper.

At a high level, both architectures scale as resources are added to theunderlying cluster. Spanner's compute and storage separation letsthe load between compute nodes rebalance faster in response to workload changes.Unlike Cassandra, shard moves don't involve data moves as the datastays on Colossus. Moreover, Spanner's range-based partitioningmight be more natural for applications that expect data to be sorted bypartition key. The flip-side of range-based partitioning is that workloads thatwrite to one end of the keyspace (for example, tables keyed by the currenttimestamp) might have hotspots if additional schema designs aren't considered.For more information about techniques for overcoming hotspots, seeSchemadesign best practices.

Consistency

With Cassandra, you must specify a consistency level for eachoperation. If you use the quorum consistency level, a replica node majority mustrespond to the coordinator node for the operation to be considered successful.If you use a consistency level of one, Cassandra needs asinglereplicanodeto respond for the operation to be considered successful.

Spanner provides strong consistency. TheSpannerAPI doesn't expose replicas to the client.Spanner clients interact with Spanner as if itwere a single machine database. A write is always written to a majority ofreplicas before Spanner reports its success to the user. Anysubsequent reads reflects the newly written data. Applications can choose toread a snapshot of the database at a time in the past, which might haveperformance benefits over strong reads. For more information about theconsistency properties of Spanner, see theTransactions overview.

Spanner was built to support the consistency and availabilityneeded in large scale applications. Spanner provides strongconsistency at scale and with high performance. For use cases that require it,Spanner supportssnapshot (stale) reads that relax freshnessrequirements.

Cassandra interface

The Cassandra interface lets you take advantage ofSpanner's fully managed, scalable, and highly availableinfrastructure using familiar Cassandra tools and syntax. This pagehelps you understand the capabilities and limitations of theCassandra interface.

Benefits of the Cassandra interface

• Portability: the Cassandra interface provides access tothe breadth of Spanner features, using schemas, queries, andclients that are compatible with Cassandra. This simplifies movingan application built on Spanner to another Cassandraenvironment or vice-versa. This portability provides deployment flexibilityand supports disaster recovery scenarios, such as a stressed exit.
• Familiarity: if you already use Cassandra, you can quickly getstarted with Spanner using many of the same CQLstatements and types.
• Uncompromisingly Spanner: because it's built onSpanner's existing foundation, theCassandra interface provides all of Spanner'sexisting availability, consistency, and price-performance benefits withouthaving to compromise on any of the capabilities available in thecomplementary GoogleSQL ecosystem.

CQL compatibility

• CQL dialect support: Spanner provides asubset of the CQL dialect, including Data Query Language(DQL), Data Manipulation Language (DML), lightweight transactions (LWT),aggregate and datetime functions.

• Supported Cassandra functionality: theCassandra interface supports many of the most commonly usedfeatures of Cassandra. This includes core parts of the schema andtype system, many common query shapes, a variety of functions and operators,and the key aspects of Cassandra's system catalog. Applications canuse many Cassandra clients or drivers by connecting overSpanner's implementation of the Cassandra wire protocol.

• Client and wire protocol support: Spanner supports the corequery capabilities of theCassandra wire protocol v4using Cassandra Adapter, a lightweight client that runs alongsideyour application. This lets many Cassandra clients work as-is witha Spanner Cassandra interface database, whileleveraging Spanner's global endpoint and connection management andIAM authentication.

Supported Cassandra data types

The following table shows supported Cassandra data types and maps eachdata type to the equivalent Spanner GoogleSQL data type.

Data type Annotations

Thecassandra_type column option lets you define mappings between theCassandra and Spanner data types. When you create atable in Spanner that you intend to interact with it usingCassandra-compatible queries, you can use thecassandra_type optionto specify the corresponding Cassandra data type for each column. Thismapping is then used by Spanner to correctly interpret andconvert data when transferring it between the two database systems.

For example, if there's a table in Cassandra with the following schema:

CREATETABLEAlbums(albumIduuid,titlevarchar,artistsset<varchar>,tagsmap<varchar,varchar>,numberOfSongstinyint,releaseDatedate,copiesSoldbigint,scorefrozen<set<int>>....PRIMARYKEY(albumId))

In Spanner, you use type annotations to map to theCassandra data types, as shown in the following:

CREATETABLEAlbums(albumIdSTRING(MAX)OPTIONS(cassandra_type='uuid'),titleSTRING(MAX)OPTIONS(cassandra_type='varchar'),artistsARRAY<STRING(max)>OPTIONS(cassandra_type='set<varchar>'),tagsJSONOPTIONS(cassandra_type='map<varchar, varchar>'),numberOfSongsINT64OPTIONS(cassandra_type='tinyint'),releaseDateDATEOPTIONS(cassandra_type='date'),copiesSoldINT64OPTIONS(cassandra_type='bigint'),scoreARRAY<INT64>OPTIONS(cassandra_type='frozen<set<int>>')...)PRIMARYKEY(albumId);

In the previous example, theOPTIONS clause maps the column'sSpanner data type to its corresponding Cassandra datatype.

• albumId (SpannerSTRING(MAX)) is mapped touuid inCassandra.
• title (SpannerSTRING(MAX)) is mapped tovarchar inCassandra.
• artists (SpannerARRAY<STRING(MAX)>) is mapped toset<varchar> in Cassandra.
• tags (SpannerJSON) is mapped tomap<varchar,varchar>in Cassandra.
• numberOfSongs (SpannerINT64) is mapped totinyint inCassandra.
• releaseDate (SpannerDATE) is mapped todate inCassandra.
• copiesSold (SpannerINT64) is mapped tobigint inCassandra.
• score (SpannerARRAY<INT64>) is mapped tofrozen<set<int>> in Cassandra.

Modify thecassandra_type option

You can use theALTER TABLE statement to add or modify thecassandra_typeoption on existing columns.

To add acassandra_type option to a column that doesn't have it yet, use thefollowing statement:

ALTERTABLEAlbumsALTERCOLUMNuuidSETOPTIONS(cassandra_type='uuid');

In this example, theuuid column in the Albums table is updated with thecassandra_type option set touuid.

To modify an existingcassandra_type option, use theALTER TABLE statementwith the newcassandra_type value. For example, to change thecassandra_typeof thenumberOfSongs column in the Albums table fromtinyint tobigint,use the following statement:

ALTERTABLEAlbumsALTERCOLUMNnumberOfSongsSETOPTIONS(cassandra_type='bigint');

You are only permitted to modify the following types:

Direct and nuanced mappings

In many cases, the mapping between Spanner and Cassandradata types is straightforward. For example, a SpannerSTRING(MAX) maps to a Cassandravarchar, and aSpannerINT64 maps to a Cassandrabigint.

However, there are situations where the mapping requires more consideration andadjustment. For example, you might need to map a Cassandrasmallintto a SpannerINT64.

Supported Cassandra functions

This section lists the Cassandra functions supported inSpanner.

The following list shows Spanner support for Cassandrafunctions.

• Allaggregate functions
• Alldatetime functions except forcurrentTimeUUID
• Allcast functions except for blob conversion functions
• Alllightweight transaction functions except forBATCHconditions

Time to live (TTL)

When migrating from Cassandra, add a row deletion policy to yourSpanner table in order to use theUSING TTL option inINSERTorUPDATE statements or the Spanner TTL.

The Spanner TTL logic operates at therow level, in contrast toCassandra, where TTL logic can be applied at thecell level. To usethe Spanner TTL, you must include a timestamp column and a timeinterval in the row deletion policy. Spanner deletes the rowafter the row exceeds the specified duration relative to the timestamp.

Spanner TTL deletion isn'tinstantaneous. An asynchronous background process deletes expired rows,and deletions can take up to 72 hours.

For more information, seeEnable TTL on Cassandra data.

Unsupported Cassandra features on Spanner

It's important to understand that the Cassandra interfaceprovides the capabilities of Spanner through schemas, types,queries, and clients that are compatible with Cassandra. It doesn'tsupport all of the features of Cassandra. Migrating an existingCassandra application to Spanner, even using theCassandra interface, likely requires some rework to accommodateunsupported Cassandra capabilities or differences in behavior, likequery optimization or primary key design. However, once it's migrated, yourworkloads can take advantage of Spanner's reliability and uniquemulti-model capabilities.

The following list provides more information on unsupportedCassandra features:

• Some CQL language features aren't supported: userdefined types and functions,token function.
• Spanner and Google Cloud control plane: databases withCassandra interfaces use Spanner and Google Cloudtools to provision, secure, monitor, and optimize instances.Spanner doesn't support tools, such asnodetool foradministrative activities.

DDL support

CQL DDL statements are not directly supported usingCassandra interface. For DDL changes, you must use theSpanner Google Cloud console, gcloud command, or clientlibraries.

Connectivity

• Cassandra client support

  Spanner lets you connect to databases from a variety ofclients:

  • Cassandra Adapter can be used as an in-process helper oras a sidecar proxy to connect your Cassandra applications toCassandra interface. For more information, seeConnect to Spanner using the Cassandra Adapter.
  • Cassandra Adapter can be started as a standalone processlocally and connected usingCQLSH. For more information, seeConnect the Cassandra interface to your application.

Access control with Identity and Access Management

You need to have thespanner.databases.adapt,spanner.databases.select, andspanner.databases.write permissions to perform read and write operationsagainst the Cassandra endpoint. For more information, see theIAM overview.

For more information about how to grant SpannerIAM permissions, seeApply IAM roles.

Monitoring

Spanner provides the following metrics to help you monitor theCassandra Adapter:

• spanner.googleapis.com/api/adapter_request_count: captures and exposes thenumber of adapter requests that Spanner performs per second,or the number of errors that occurs on the Spanner serverper second.
• spanner.googleapis.com/api/adapter_request_latencies: captures and exposesthe amount of time that Spanner takes to handle adapterrequests.

You can create a custom Cloud Monitoring dashboard to display and monitormetrics for Cassandra Adapter. The custom dashboard contains thefollowing charts:

• P99 Request Latencies: The 99th percentile distribution of serverrequest latencies permessage_type for your database.

• P50 Request Latencies: The 50th percentile distribution of serverrequest latencies permessage_type for your database.

• API Request Count by Message Type: The API request count permessage_type for your database.

• API Request Count by Operation Type: The API request count perop_type for your database.

• Error Rates: The API error rates for your database.

Additionally, the following Spanner metrics are helpful formonitoring the Cassandra Adapter:

• CPU utilization metrics provide informationabout CPU usage for user and system tasks with breakdowns by priority andoperation type.
• Storage utilization metrics provideinformation about database and backup storage.
• Spanner's built-in statistics tablesprovide insights about queries, transactions, and reads to help you discoverissues in your databases.

For a complete list of system insights, seeMonitor instances with system insights.To learn more about monitoring your Spanner resources, seeMonitor instances with Cloud Monitoring.

Pricing

There is no additional charge for using the Cassandra endpoint. You arecharged the standard Spanner pricing for the amount of computecapacity that your instance uses and the amount of storage that your databaseuses.

For more information, seeSpanner pricing.

What's next

• Learn how toMigrate from Cassandra to Spanner.
• Learn how toConnect to Spanner using the Cassandra Adapter.
• Try theSpanner for Cassandra users codelab.