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 所提供的接口仍是很豐富的，可是在可視化監控界面上，還須要多多努力，可以直接提供對接目前市面上大部分的監控系統，那樣就更加完美了。可是無論怎麼說，可以作出一款屬於國人本身的分佈式數據庫，仍是很是值得你們敬佩和學習的。

共勉之！