Astra DB Multi-cloud DBaaS Built on Apache Cassandra™
Astra Streaming Multi-cloud Streaming-as-a-Service Built on Apache Pulsar™
Luna for Apache Cassandra™ Subscription-to-Success with Open-Source Apache Cassandra™
Luna Streaming Subscription-to-Success with Open-Source Apache Pulsar™
DataStax Enterprise Scale-out, Cloud-native NoSQL built on Apache Cassandra.

Start building your modern data apps faster with DataStax's cloud native messaging and event streaming service powered by Apache Pulsar.

Try Astra Now

Pricing

Enterprise Success Stories of data-driven enterprises using DataStax to grow their business
Open||Source||Data A podcast series with Sam Ramji
Inspired Execution A podcast series with Chet Kapoor
Events Join the DataStax team at a virtual event or workshop

Cassandra Total Cost of Ownership Study

Analyst firm, GigaOm, has conducted a comprehensive new study comparing serverless Cassandra with self-managed Cassandra.

Get The Report

Learn Without Fear

We’re excited to share a new learning experience for both new and experienced Cassandra users now at datastax.com/dev.

Try For Free Schedule Demo

Apache Cassandra™ 4.0 Virtual Tables

Play

Video: Monitor Apache Cassandra™ 4.x Component Status

Virtual Tables

At first glance, virtual tables look like all other tables: CQL lets you read them with ordinary SELECT statements. But the results don't come from sstables and are not distributed: indeed they may not even be written on disk at all, originating instead from live calculations.

Next: Querying

Querying

When you query a virtual table, you do so on a specific node and it is that node that answers. Concepts such as replication, distribution, consistency level do not apply (the latter is simply ignored in queries). If you read the same table on another node, you may well obtain different results—hardly surprising, given that virtual tables are conceived for node-specific information.

In version 4.0, virtual tables are read-only. Write operations, as well as DDL statements, are not permitted. In future versions, row updates may be allowed, which will come handy for changing node settings on the fly or triggering certain actions, something still requiring nodetool/JMX at the moment.

Next: system_virtual_schema keyspace

system_virtual_schema keyspace

Virtual tables are confined to dedicated system keyspaces. One such keyspace, system_virtual_schema, contains tables encoding the schema information for all virtual tables—just what you would get with a DESCRIBE TABLE statement on a virtual table, but in machine-readable form.

Next: system_views keyspace

system_views keyspace

The interesting data is in keyspace system_views. DESCRIBE TABLES shows that it contains about twenty tables, each exposing a specific type of information. Some are:

clients: currently active connections, their driver version, ports used and so on;
sstable_tasks: status and progress of currently-running operations such as compactions;
system_properties: OS and JVM versions, Cassandra path definitions and other settings;
tombstones_per_read: statistics on the efficiency of read operations;
disk_usage: how much space each table occupies on the hard drive;
settings: the many, many settings one would find in cassandra.yaml.

Next: Table Structure

Table Structure

You can run a DESCRIBE KEYSPACE or DESCRIBE TABLE statement on a virtual table: however, CQL duly informs you that the results are for your convenience only, and that the corresponding CREATE commands would not work - indeed, the entire output of the DESCRIBEstatements is given as a CQL comment!

Next: Summary

Summary

Virtual tables help make a node observable from within CQL. This opens the way for new, more integrated tools and automation, especially related to performance monitoring.More metrics and internal information will be added in future releases, together with the ability to change some settings by writing directly to the tables: feature equivalence with the JMX approach is indeed on the roadmap.

Next: Skill Building