SequoiaDB监控与开发实践分析

使用背景

公司近期上线了一个新应用，底层数据库采用了国产的分布式数据库 – 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 所提供的接口仍是很丰富的，可是在可视化监控界面上，还须要多多努力，可以直接提供对接目前市面上大部分的监控系统，那样就更加完美了。可是无论怎么说，可以作出一款属于国人本身的分布式数据库，仍是很是值得你们敬佩和学习的。

共勉之！