摘要：但是當其中某幾組負荷較大時，其他組并無法協助分擔負荷。未來計劃目前正在評估的使用，未來計劃將后臺分析資料部份，改采用。

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

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

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

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

使用 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 版中就修復了。

初期上線采用了 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 運營系統工程師