在最近 Apache Cassandra 4.0 beta 版本的众多新增功能中,虚拟表是值得关注的一个功能。
在以前的 Cassandra 版本中,用户需要访问 Java 管理扩展 (JMX) 来检查 Cassandra 的详细信息,例如正在运行的压缩、客户端、指标和各种配置设置。虚拟表消除了这些挑战。Cassandra 4.0 beta 使用户能够从只读系统表中以 Cassandra 查询语言 (CQL) 行的形式查询这些详细信息和数据。
以下是以前 Cassandra 版本中基于 JMX 的机制的工作原理。假设用户想要检查集群中特定节点的压缩状态。用户首先必须建立 JMX 连接以在节点上运行 nodetool compactionstats
。这个要求立即给用户带来了一些复杂性。用户的客户端是否配置了 JMX 访问权限?Cassandra 节点和防火墙是否配置为允许 JMX 访问?是否已准备好并落实了适当的安全和审计措施?这些只是用户在处理以前版本的 Cassandra 时必须应对的一些问题。
使用 Cassandra 4.0,虚拟表使用户可以通过利用他们以前配置的驱动程序来查询他们需要的信息。此更改消除了与实施和维护 JMX 访问相关的所有开销。
Cassandra 4.0 创建了两个新的键空间,以帮助用户利用虚拟表:system_views
和 system_virtual_schema
。system_views
键空间包含用户寻求的所有有价值的信息,这些信息以有用的方式存储在多个表中。顾名思义,system_virtual_schema
键空间存储这些虚拟表的所有必要模式信息。

(Ben Bromhead, CC BY-SA 4.0)
重要的是要理解,每个虚拟表的范围都限制在其节点。对虚拟表的任何查询都将返回仅对充当其协调器的节点有效的数据,而与一致性无关。为了简化此要求,已在多个驱动程序中添加了支持,以在这些查询中指定协调器节点(Python、DataStax Java 和其他驱动程序现在都提供此支持)。
为了说明,请检查这个 sstable_tasks
虚拟表。此虚拟表显示有关 SSTables 的所有操作,包括压缩、清理、升级等。

(Ben Bromhead, CC BY-SA 4.0)
如果用户要在以前的 Cassandra 版本中运行 nodetool compactionstats
,则会显示相同类型的信息。在这里,查询发现该节点当前有一个正在进行的压缩。它还显示其进度及其键空间和表。借助虚拟表,用户可以快速收集此信息,并同样有效地获得正确诊断集群运行状况所需的洞察力。
需要明确的是,Cassandra 4.0 并未消除对 JMX 访问的需求:JMX 仍然是查询某些指标的唯一选择。也就是说,用户将欢迎能够仅通过使用 CQL 来提取关键集群指标的能力。由于虚拟表带来的便利,用户可能能够将以前用于 JMX 工具的时间和资源重新投入到 Cassandra 本身。客户端工具也应开始利用虚拟表提供的优势。
如果您对 Cassandra 4.0 beta 版本及其虚拟表功能感兴趣,请试用一下。
评论已关闭。