去分库分表的亿级数据NewSQL实践之旅
http://dbaplus.cn/news-11-1931-1.html
背景?
?
2017 年初，公司用戶中心體系面臨迭代和重構，當時數據庫有數億多的核心數據通過 HashKey?分為了 1024 張表在 64 個數據庫中來存儲，使用自研的代碼框架來進行對應 HashKey?的 seek 操作。
?
這時，非 HashKey 的查詢、DDL 變更等業務需求、分表分庫邏輯代碼框架的局限讓研發和運維都面臨較高的數據庫使用成本，數據庫不能靈活高效的支撐業務需求。
?
圖1：分庫分表方案架構圖
?
為了解決上述問題，我們的技術團隊急需一套同時滿足如下的條件的數據庫分布式集群：
-
能夠提供實時的 OLTP 的一致性數據存儲服務；
-
彈性的分布式架構；
-
配套的監控備份方案；
-
穩定的高可用性；
-
較低的遷移重構成本。
?
前期選擇?
?
最開始先考察了幾個方案，但都有相對來說的不足：
?
1方案一：
?
將整個分表分庫邏輯剝離到開源分表分庫中間件上：
?
-
基于 2PC 的 XA 弱事務的一致性保證不盡如人意
-
高可用架構更加復雜，單分片的局部不可用會對全局產生影響
-
備份恢復的復雜度高
-
這些方案引入了新的 sharding key 和 join key 的設計問題，整體的遷移難度不降反升
?
2方案二：
?
官方的 MySQL Cluster 集群：
?
-
NDB?引擎不同于 InnoDB，需要修改表引擎，且實際使用效果未知
-
NDB的高可用有腦裂風險
-
監控備份的方案需要另作整理
-
國內生產用例不多、資料缺乏，非企業版運維流程復雜
?
探索?
?
機緣巧合下，我們發現NewSQL特性可以提供很好的支持，于是受 Google Spanner 的論文啟發設計而來的開源分布式 NewSQL 數據庫 TiDB 進入了我們的視線，它具備如下 NewSQL 特性：
?
-
SQL支持 （TiDB 是 MySQL 兼容的）
-
水平線性彈性擴展
-
分布式事務
-
跨數據中心數據強一致性保證
-
故障自恢復的高可用
-
海量數據高并發寫入及實時查詢（HTAP 混合負載）
?
所以說，上述的特點非常契合目前我們在數據庫應用設計上碰到的問題。經過評估，我們開始著手安排部署和測試，在備份、監控、故障恢復和擴展幾個方面有以下的一些心得：
?
-
官方提供了一套基于 mydumper 和 myloader 的工具套件，是基于邏輯備份的方式，對于遷移來說是很便捷的；
-
監控用的是應用內置上報 Prometheus 的方案，可以寫腳本與自有的監控系統對接；
-
有狀態的KV層采用的是 Raft 協議來保證高可用，Leader 的選舉機制滿足了故障自恢復的需求；
-
無狀態的?TiDB-Server 查詢層可以在前段搭建LVS 或HAProxy來保證故障的切換；
-
KV?層的 Region 分裂保證了集群無感知的擴展。
?
測試之后發現數據庫運維中比較重要的幾項都已經閉環的解決了，但有得有失，實測結論是：
?
-
TiDB 是分布式結構，有網絡以及多副本開銷，導致 Sysbench OLTP 測試中 單 server 的讀性能不如 MySQL，但在大數據量下性能相較于MySQL不會產生明顯下滑，且彈性擴展能力評估后可以滿足業務的峰值需求；
-
TiDB 的 OLAP 能力在大數據量下優于 MySQL，且能看到持續的大幅提升；
-
由于 TiDB-Server 是無狀態的，后續可以添加 Load Balance 來擴展 Server 層的支撐。
?
持續引入?
?
在性能和需求滿足的前提下，我們開始著手業務層的接入和改造，因為兼容MySQL 協議，所以遷移成本大大降低，同時 TiDB 官方也提供的工具 Syncer ，部分遷移在業務層就是一次 MySQL 的主從切換。
?
于是用戶積分系統的擴展便不再采用分表分庫的方案，分表邏輯回歸到多個獨立的單表，數億的數據在 OLTP 的業務場景下表現十分出色，沒有 sharding key 的約束后，整個使用邏輯在上層看來和 MySQL 單表沒有不同，更加靈活的索引也提供了一部分低開銷的 OLAP 的查詢能力，總體來說，整體的遷移改造流程比較順利，業務契合度也很高。
?
隨著上述系統的成功應用后，后面符合場景的 OLTP 項目也開始逐漸使用，當然在和業務結合的過程中也需要一些定制和改造，主要涉及登錄態系統、補包碼系統、用戶軌跡項目和存儲層。
?
-
登錄態系統：原先是在 MySQL 采用 Replace 保留最后一條數據，而遷移到NewSQL ??的模式后，由于表的伸縮能力獲得了很大的提升，故將 Replace 改為了 Insert 保留了所有的登錄情況，單表數據量十億以上，業務上支持了更多維度的記錄，沒有碰到性能和擴展性問題。
-
禮包碼系統：禮包碼的主流程為復雜度 O(1) 的 hash seek OLTP業務，經過改造后，將原來的 100 個表的分表模式集中成單表歸檔式管理，單表數據預計會達到 20 億+。
-
用戶軌跡項目：數據庫彈性能力增長后的新需求，一些重要的用戶行為數據的記錄。
?
在KV存儲層沒有瓶頸時，采用復用了集群的KV?層的策略，在無狀態的 Server 層做了業務隔離，間接的提升了整個集群的使用率，類似一個 DBaaS 的服務。如下圖所示：
?
圖2：多套業務系統 TiDB 部署圖
?
目前的情況和期望?
?
從 RC2.2 版本到 GA1.0，游族平臺部的生產環境已經有 3 套 TiDB 集群在運行，共計支撐了 6 個 OLTP 業務的穩定運行快一年的時間。 期間在集群部署策略、BUG 響應和修復、升級方案協助、遷移工具方面，廠商和開源社區都可以給予全面的支持。在后期對于分析型的需求上，我們也會嘗試使用重 OLAP 需求的 TiSpark 計算層。
?
NewSQL給了大庫大表業務一個全新的選擇方向，相信以后能在更多的業務選型和設計方案上給出新的思路和方向。
轉載于:https://www.cnblogs.com/davidwang456/articles/8995041.html
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的去分库分表的亿级数据NewSQL实践之旅的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 利用spring session解决共享
- 下一篇： 大众点评订单分库分表实践之路