TiDB 在株式會社 FUNYOURS JAPAN 的應用

株式會社 FUNYOURS JAPAN 是一家日本東京的遊戲公司， 從社區了解到 TiDB 後與官方團隊取得聯繫，在雙方共同努力下，TiDB 現已正式上線，運行在海外的 Azure 平台上。這也是第一家上線 TiDB 的海外遊戲公司。

背景

株式會社 FUNYOURS JAPAN（http://company.funyours.co.jp/）自 2014 在日本成立以來，營運多款頗受好評的頁游跟手游，如：剣戟のソティラス、九十九姬等，對於營運遊戲來說，能夠了解遊戲中的玩家在做什麼，喜歡的偏好是什麼，關卡的設計是否平衡，都是相當重要的，所以隨著營運時間的增長，資料庫數據在億筆以上也是尋常的。

所以我們的技術單位也一直不斷在評估市面上的各種資料庫以及如何改進目前現有系統與架構，近年來最熱門的資料庫系統可以說是 NoSQL 了，不論 MongoDB，Cassandra，Redis，HBase 等等都佔有一片天，具有讀寫快速，容易擴展等特性。經過初步了解後，採用 NoSQL 方式，需要對於目前的資料儲存架構整個重新設計，並且需要配合採用的該套 NoSQL 資料庫進行業務改造設計，那麼該採用哪一套 NoSQL 資料庫又是一個需要慎重考慮的課題。先回過頭來看當前最需要處理改進的項目：1. 儲存空間擴展不易，2. 單台資料庫效能有限。

初期方案

在處理儲存空間不足部分，一開始我們先採用了 MySQL innoDB 提供的壓縮表格格式，對於需要時常讀寫更新的部分使用了 8K page size，過往的日誌部分採用 4K page size，效果非常令人滿意，釋放了大量的儲存空間，並且對於效能來說沒有造成可察覺的影響。這部分網路上的測試比較多，就不在此多做說明。但是很快的壓縮表格節省的空間畢竟是有限的，接下來只能增加 volume 容量以及將沒有需要更新的過往日誌移動到其他資料庫上，雖然造成維護工作跟時間的繁複與負擔，但是問題解決了。

基於 MySQL 資料庫架構單台的性能限制上，我們採用了多組的資料庫伺服器，來滿足所需的效能。當然不同組之間資料是不共通的，也就是無法直接使用 SQL 來做跨組間的操作，需要額外的程式來作業。而當然為了大量的資料存取上的效能，分表分庫對表格進行 partition 這些作業都少不了。

初識 TiDB

使用 NoSQL 式資料庫看似可以完美的提供出一個解法，但需要付出的成本也是高昂的。於是我們把眼光落到了 MySQL Cluster 上，這時看到了 Google 發布 Cloud Spanner beta 的新聞，NewSQL？這是什麼? 很快的引起了我們濃厚的興趣，然後經過多方調研，我們發現了 TiDB：一個開源在 GitHub 上的 NewSQL 資料庫。官方也持續不斷發布了很多相關的文章，隨著對 TiDB 的認識，認為對於目前現況是很合適的最佳化方案，相容於 MySQL，高可用性，容易水平擴展。

在可行性評估與測試的時候，一開始採用了 TiKV 3 台搭配 PD 3 台，TiDB 2 台混搭 PD 的架構，使用了文件建議的 ansible 安裝，這時遇到兩個困難，第一個是在 ansible 檢查機器效能的時候會因為硬碟讀寫效能而無法安裝。由於是使用雲端機器，所以對硬體方面沒有太大的彈性，只好自己手動去修改腳本才能順利安裝。第二個也是在 ansible 裡面會檢查 ntp 同步服務是否啟動，但是 centos7 預設的時間同步服務是 chrony，所以也是修改了腳本（後來的版本有提供 flag 能切換，也有自動安裝 ntp 的選項），總之是順利安裝了。這時因為 PingCAP 才剛發布了 ansible 安裝的方式，所以文件對於水平擴展部分，如新增 TiKV、 PD 、TiDB 機器，或者移除機器，官方 doc 沒有詳細說明，於是就寫了封 mail 聯繫 PingCAP，發完信出去吃午餐回來，官方已經回復並且邀請加入 wechat，提供更即時的溝通跟支援，實在是很令人驚艷。

備份與還原的機制，TiDB 在這部分提供了一個性能比官方的 mysqldump 更快的方案- mydumper/loader，這裡我們一開始使用 GitHub 上的 source 自己 build，但是有點問題，跟官方交流後，才知道原來 tidb-enterprise-tools 這個工具包裡面已經有提供了。mydumper 能夠使用正則表達式去挑選出想要的 database 跟 table 備份，對於原本架構就會分庫分表的設計，更添加了不少方便，備份出來的檔案會全部放在一個資料夾內，使用 loader 就可以將這個備份的資料再次進入 DB。但是採用 TiDB 不就是為了使用同一張表的便利性嗎。當巨量的數據都在同一個表內的時候，雖然 mydumper/loader 的效能很好，由於必需全量備份的關係，還是需要一點時間，因為 TiDB 也支援 mysqldump，所以如果需要進行增量備份，也可以採用 mysqldump 搭配 where 條件式來進行。

因為需要對於不同的服務進行許可權的管制，所以也一併測試了 TiDB 的帳號許可權機制，那時還是 pre-GA 版本，根據文件上賦予模糊匹配會無法獲得許可權，必須要完全匹配才能正常取得；另外是在使用 revoke 回收許可權方面會沒有正確收回許可權。但是在回報 PingCAP 後，很快的在 GA 版中就修復了。

上線 TiDB

初期上線採用了 4 core cpu、記憶體 32 GB 作為 TiKV，8 core cpu、記憶體 16 GB 作為 TiDB/PD，3 台 TiKV、3 台 PD 、2 台 TiDB 跟 PD 混搭的方式。透過 prometheus 觀察，發現 loading 都集中在同一台 TiKV 上，且 loadaverage 在高峰期間會衝到 7 以上，初步判斷可能是規格不夠，於是決定將 TiKV 都提升到 16 core 、24 GB 記憶體。因為線上正在舉辦活動，所以不希望停機，採用先增加三台 TiKV 機器同步後，再移除三台原本 TiKV 的方式進行，也特別感謝 PingCAP 在置換機器中間，一直在線上支援，過程中很平順的完成了切換機器。機器提高規格後，高峰期的 loadaverage 下降到 4，但是還是會集中在其中某一台 TiKV 上不會分散到三台，在 PingCAP 的協助分析下，判斷出可能是業務行為中的 select count(1) 這個 SQL 太過頻繁，涉及該業務數據一直存取在同 1 個 region，通過嘗試在文件上的提高開發度的方式，還是無法解決（最新的 v1.1 版有在對 count(*) 進行最佳化），最後結合數據特性對業務行為進行了變更，loadavg 幾乎都是保持在 1 以下。

比較原本架構與 TiDB 架構，原本架構上是採用多組 DB 的方式來讓使用者分布在不同組 DB 上面，來達到所需的效能。但是當其中某幾組負荷較大時，其他組 DB 並無法協助分擔負荷。採用 TiDB 的架構後，在機器的使用上更有效率，並且在使用後台查找分析資料時，原本的架構下，只要時間一拉長到一個月以上，就會對該組 DB 的效能造成影響；在 TiDB 的架構下，並不會有這樣的問題。

現在運營上最直接的效益就是硬體成本的節約，原架構下每一組 DB 規格都必須符合尖峰期間的運作。但是在 TiDB 的架構下，將全部的機器整合成一體後，只要全部機器加總起來的效能能夠達到尖峰期間即可，在監控上搭配 Prometheus/Grafana 的視覺化系統與能彈性的自訂規則的警示，也免去了原本使用 snmp 自建監視系統的成本。另外由於降低了撰寫程式的複雜度，當運營企劃人員提出新的想得知的分析資料時，能夠更快的從資料庫中取出，而可以有更多的時間來應對與分析使用者偏好。

未來計劃

目前正在評估 TiSpark 的使用，未來計劃將後台分析資料部份，改採用 TiSpark。因為 TiSpark 可以直接操作 TiKV，也能夠應用 Spark 提供的許多現成的函式庫來對收集到的 log 做數據分析。預期利用 Spark 的機器學習來初步判斷系統內的每個功能是否正常運作，並提出警示，例如當使用者的登入頻率異常時等，來協助人工監控遊戲運行狀態。

? 作者：張明塘，FUNYOURS JAPAN 運營系統工程師

推薦閱讀：