SequoiaDB监控与开发实践分析

4次阅读

共计 3412 个字符,预计需要花费 9 分钟才能阅读完成。

使用背景

公司近期上线了一个新应用,底层数据库采用了 国产的分布式数据库SequoiaDB

因为需要将 SequoiaDB 集群纳入到公司的整个监控体系中,所以需要对 SequoiaDB 的状态、性能指标等信息收集起来,然后提供监控系统使用。

SequoiaDB 数据库本身提供了一个 图形化的监控界面 – SAC,但是里面的监控项,和我们公司过去常用的指标有很大出入。所以在咨询了 SequoiaDB 的相关人员后,决定自己开发一套监控程序。

SequoiaDB 存储引擎的监控

在 SequoiaDB 数据库,存在两个大的体系,一个是计算层,像我们就是使用了 MySQL 实例,另外一个就是 SequoiaDB 的分布式存储层,也是整个数据库对性能影响最大的部分。

关于 MySQL 的监控,公司本来就已经存在一整套完备的监控程序,所以这块就不需要再额外的开发了。但是对于 SequoiaDB 底层的分布式,还是非常有必要将相关指标收集起来的。

SequoiaDB 在监控体系上,其实做得还是比较完整的,只是在展现方式上,还需要再打磨一下。SequoiaDB 底层分布式的所有运行信息,用户都可以通过 snapshot,或者是 list 命令获取。

我从 SequoiaDB 的技术人员中了解到,其实像 SAC,或者 sdbtop 等这种 SequoiaDB 官方提供的监控工具,实际上也是基于 snapshot 和 list 命令开发。大家可以通过查阅官网信息中心了解更多的方法说明,snapshot 方法介绍 和 list 方法介绍。

2.1 SequoiaDB 的快照说明

在 SequoiaDB 存储引擎中,如果你要查看运行状况,可以通过快照来获取信息。

SequoiaDB 的快照命令非常简答,如果使用它提供的 sdb 客户端,可以这么来执行,例如查看整个集群中,每个 table 的使用情况:

> db.snapshot(SDB_SNAP_COLLECTIONS)
{
  "Name": "foo.bar",
  "UniqueID": 4294967297,
  "Details": [
    {
      "GroupName": "group1",
      "Group": [
        {
          "ID": 0,
          "LogicalID": 0,
          "Sequence": 1,
          "Indexes": 1,
          "Status": "Normal",
          "TotalRecords": 1,
          "TotalDataPages": 1,
          "TotalIndexPages": 2,
          "TotalLobPages": 0,
          "TotalDataFreeSpace": 65432,
          "TotalIndexFreeSpace": 65486,
          "TotalDataRead": 1,
          "TotalIndexRead": 0,
          "TotalDataWrite": 1,
          "TotalIndexWrite": 1,
          "TotalUpdate": 0,
          "TotalDelete": 0,
          "TotalInsert": 1,
          "TotalSelect": 1,
          "TotalRead": 1,
          "TotalWrite": 1,
          "TotalTbScan": 1,
          "TotalIxScan": 0,
          "ResetTimestamp": "2020-05-26-13.42.20.163109",
          "NodeName": "datanode:11820"
        }
      ]
    }
  ]
}

大家从返回的结果就能够了解,首先 SequoiaDB 的分布式存储引擎,在获取快照时,它返回的结果格式为 JSON,这个和我们过去使用 Oracle 或者 MySQL 数据非常的不同,可能有一些朋友在开始时不大适应。但是当你习惯了 JSON 的灵活结构后,你会打开一片新的大陆。

我给大家演示的例子中,是查询整个集群表级的快照信息。它能够让大家清晰地了解每个 table 在各个 group 上的分布,以及它对应的数据读,索引读这类关键信息的瞬时绝对值。当然,如果大家直接这么查看信息,估计大家眼睛都要看瞎,所以在后续的工具跟进上,SequoiaDB 数据库还需要多多努力的。

2.2 SequoiaDB SQL 快速处理

如果大家已经在使用 SequoiaDB 存储引擎提供的 snapshot 和 list 功能了,那么你是否也发现了一个问题,sdb 客户端提供的 api 命令,执行起来的计算能力实在太弱了,例如我要关联把 SDB_SNAP_SESSIONS 快照 (http://doc.sequoiadb.com/cn/s…_id-1479173713-edition_id-304) 和 SDB_SNAP_TRANSACTIONS 快照(http://doc.sequoiadb.com/cn/s…_id-1479173720-edition_id-304) 关联起来,查看当前 SequoiaDB 存储引擎中,到底有哪些事务在等待锁。这个时候,单纯使用 api 就会痛苦万分,因为要自己手工编写一个关联程序。我相信大部分的 DBA 朋友都会怀念那些单纯使用 SQL 命令的时光。

通过自己不断的努力(翻官网信息中心),终于找到了一种优雅的方式来解决,就是 sql 语法的监控视图(http://doc.sequoiadb.com/cn/sequoiadb-cat_id-1559546719-edition_id-304))。

例如刚才的提出的问题,就可以通过这个 sql 命令获取信息:

> db.exec("select trans.NodeName as node, session.LastOpType as lastOpType, session.LastOpInfo as lastOpInfo from $SNAPSHOT_TRANS as trans inner join $SNAPSHOT_SESSION as session on trans.RelatedID = session.RelatedID where trans.WaitLock.CSID is not null")
{
  "node": "datanode:11820",
  "lastOpType": "GETMORE",
  "lastOpInfo": "ContextID:297, NumToRead:-1"
}
{
  "node": "datanode:11820",
  "lastOpType": "UPDATE",
  "lastOpInfo": ""
}

SequoiaDB 存储引擎中这个简易版的 SQL 语法解析,对于日常的操作和运维监控来说,已经达到了事半功倍的效果了。

2.3 开发语言选择

SequoiaDB 存储引擎,支持多种开发语言获取引擎的监控信息,包括常见的:Java、PHP、Python、C++、C 等等。大家在开发时,可以在 SequoiaDB 官网中下载对应的驱动包,在开发和编译时,将 SequoiaDB 的驱动包加入到 ClassPath 就可以了。

对于我个人来说,虽然 Java 很香,但是我还是选择了 REST 接口作为我的程序与 SequoiaDB 引擎的交互方式。REST 接口虽然不像 Driver 驱动使用那么便利,但是它胜在脱离语言与环境的要求,我可以在任何地方调用它,并且获得的结果都是一样的。

引玉抛砖引玉的 Demo 程序

为了给大家演示,我基于 SequoiaDB 提供的 REST 接口,使用 Python 语言做了一个能够实时监控 SequoiaDB 中某张表的数据读、写情况的小程序,算是回馈 SequoiaDB 社区的小贡献。

程序的源码可以从:

https://github.com/yuki0703/Demo

Github 项目中获取。

程序的逻辑非常简单,就是通过 SequoiaDB 提供的 REST 接口,通过 SequoiaDB 的 SQL 语法中的监控视图方法,获取某张表的快照信息,然后通过计算 1 秒以内的数值差距,得出该表每秒钟所执行数据操作。

程序的 help 信息如下:

SequoiaDB Monitor

optional arguments:
  -h, --help   show this help message and exit
  --host HOST  coord host
  -u USERNAME  username
  -p PASSWORD  password
  -t TABLE     table name

监控 SequoiaDB 某张表的效果如下:

后记

整理来看,SequoiaDB 所提供的 接口 还是很 丰富 的,但是在可视化监控界面上,还需要多多努力,能够直接提供对接目前市面上大部分的监控系统,那样就更加完美了。但是不管怎么说,能够做出一款属于国人自己的分布式数据库,还是非常值得大家敬佩和学习的。

共勉之!

正文完
 0