Shulou(Shulou.com)06/02 Report--

Editor to share with you how to use virtual tables in Apache Cassandra 4.0.I hope you can get something after reading this article. Let's discuss it together.

Among the many new features in the beta version of Apache Cassandra 4.0, the virtual table virtual table is a noteworthy feature.

In previous versions of Cassandra, users needed to visit the Java Management extension Java Management Extensions (JMX) to view the details of Cassandra, such as running compacted compaction, clients, metrics, and various configuration settings. Virtual tables eliminate these challenges. Cassandra 4.0beta allows users to query these details and data from a read-only system table in the form of Cassandra query language Cassandra Query Language (CQL) rows.

Here is how the JMX-based mechanism worked in previous versions of Cassandra. Imagine that a user wants to check the compaction status of a node in the cluster. The user first establishes a JMX connection and runs nodetool compactionstats on the node. This requirement immediately brings some complex problems to users. Is the user's client configured with JMX access? Are the Cassandra nodes and firewalls configured to allow JMX access? Are appropriate security and audit measures in place? These are just some of the problems that users have to face when dealing with previous versions of Cassandra.

In Cassandra 4.0, virtual tables allow users to query the required information using previously configured drivers. This change eliminates all the overhead associated with implementing and maintaining JMX access.

Cassandra 4.0has created two new keyspace keyspace to help users take advantage of virtual tables: system_views and system_virtual_schema. The system_views key space contains all the valuable information queried by the user and is usefully stored in some tables. The system_virtual_schema key space, as its name implies, stores all the necessary schema information for these virtual tables.

System_views and system_virtual_schema keyspaces and tables

It is important to understand that the scope of each virtual table is limited to its nodes. The data returned by any virtual table query is valid only for the nodes of its coordinator, regardless of consistency. To simplify this requirement, support has been added to several drivers to specify the coordinator node in these queries (Python, DataStax Java, and other drivers now provide this support).

To illustrate this point, look at the sstable_tasks virtual table. This virtual table shows all the operations on SSTables, including compaction, cleaning, upgrading, etc.

Querying the sstable_tasks virtual table

If the user runs nodetool compactionstats in a previous version of Cassandra, the same type of information is displayed. Here, the query finds that the node currently has an active compression. It also shows its progress as well as its key space and table. Thanks to virtual tables, users can quickly collect this information and equally effectively acquire the capabilities needed to correctly diagnose the health of the cluster.

It is important to note that Cassandra 4.0 does not remove the need for JMX access. JMX is still the only option for querying certain metrics. However, users will welcome the ability to simply use CQL to obtain key cluster metrics. Because of the convenience provided by virtual tables, users may reinvest the time and resources previously invested in JMX tools into Cassandra itself. Client tools should also start to take advantage of the advantages offered by virtual tables.

After reading this article, I believe you have a certain understanding of "how to use virtual tables in Apache Cassandra 4.0". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.