本文适合資料庫解決方案工程師（DA）、資料庫傳遞工程師、資料庫一線&二線從業者、以及對DDS感興趣的使用者，希望讀者可以通過本文通過華為雲資料庫DDS産品深度賦能課程的學習，加強DA、傳遞、一線、二線對資料庫産品的了解和技能提升。
本文分為4個章節展開講解：
第1章 華為雲資料庫DDS産品介紹
第2章 DDS業務開發使用基礎
第3章 了解DDS核心原理
第4章 快速使用分片叢集
一、 華為雲資料庫DDS産品介紹
1. DDS 概述
首先我們要了解一下DDS的一些基礎資訊：
文檔資料庫 DDS(Document Database Service)完全相容 MongoDB 協定，也就是正常MongoDB如何使用，DDS就如何使用，在華為雲高性能、高可用、高安全、可彈性伸縮的基礎上，提供了一鍵部署，彈性擴容，容災，備份，恢複，監控等服務能力。目前支援分片叢集(Sharding)、副本集(ReplicaSet)、單節點(Single)三種部署架構。
MongoDB的資料結構
MongoDB存儲結構
• 文檔(Document):MongoDB中最基本的單元，由BSON鍵值對(key-value)組成。
相當于關系型資料庫中的行(Row)。
• 集合(Collection):一個集合可以包含多個 文檔，相當于關系型資料庫中的表(Table)
• 資料庫(Database):等同于關系型資料庫中的資料庫概念，一個資料庫中可以包含多個集合。您可以在MongoDB中建立多個資料庫。
2. DDS 部署形态及關鍵特性
2.1DDS服務部署形态-單節點(Single)
架構特點
1.超低成本，僅需支付一個節點的費用
2.支援10GB-1000GB 的資料存儲;
3.較副本集/叢集可用性不高:當節點故障，業務不可用;
适用場景
非核心資料存儲
學習實踐;
測試環境的業務;
2.2 DDS服務部署形态--副本集(Replica Set)
上圖為一個經典的三副本形态
架構特點
1. 三節點高可用架構:當主節點故障時，系統自動選出
新的主節點
2.支援10GB-3000GB 資料存儲;
3. 具備擴充到5節點，7節點副本集的能力。
适用場景
有高可用需求，資料存儲<3T
2.3 DDS服務部署形态--叢集(sharding)
架構特點
1. 元件構成:由mongos(路由)、config(配置)、shard(分片)三種類型的節點構成
2. Shard 分片:每個shard都是一個副本集架構，負責存儲業務資料。可建立2-16個分片，每個分片10GB-2000GB。是以，叢集空間範圍( 2-16)*(10GB-2000GB)
3. 擴充能力:線上規格變更、線上橫向擴充
适用場景
要求高可用，資料量大且未來橫向擴充要求
2.4 DDS關鍵特性
文檔資料庫 DDS 主要特性集
• 資料庫類型及版本:相容 MongoDB 3.4/4.0 版本
• 資料安全:多種安全政策保護資料庫和使用者隐私，例如:VPC、子網、安全組、SSL等
• 資料高可靠:資料庫存儲支援三副本備援，資料庫資料可靠性高;備份資料可靠性高
• 服務高可用(同城容災):叢集/副本集執行個體支援跨AZ部署，服務可用性高
• 執行個體通路:多種通路方式，包括:内網IP 通路、公網IP 通路
• 執行個體管理:支援執行個體的建立、删除、規格變更、節點擴容、磁盤擴容、重新開機等生命周期管理
• 執行個體監控:支援監控資料庫執行個體OS及DB引擎的關鍵性能名額，包括CPU/記憶體/存儲容量使用率、1/O活動、資料庫連接配接數等
• 彈性伸縮:水準伸縮:增删 shard 分片(最多 16個);垂直伸縮:執行個體規格變更，存儲空間擴容(最大n*2TB)
• 備份與恢複:備份:自動備份、手動備份，全量備份、增量備份，備份檔案的增、删、查、複制等生命周期管理。恢複:副本集支援恢複到備份保留期内任意時間點(Point-In-Time Recovery, PITR)/某個全量備份時間點，恢複到新執行個體/原執行個體。備份儲存周期高達 732天
• 日志管理:支援慢SQL日志、錯誤日志的檢視、以及審計日志下載下傳
• 參數配置:可以根據監控和日志等資訊，通過管理控制台對資料庫執行個體的參數進行自定義設定，進而優化資料庫。另外管理控制台對參數組提供了增、删、改、查、重置、比較、複制等一系列的參數管理的能力。
3. DDS 産品優勢及應用場景
3.1 DDS 的産品優勢
MongoDB
• 100%相容 MongoDB
• 具備無需業務改造，直接遷移上雲的能力
• 支援社群3.4/4.0版本
3種架構
• 叢集、副本集、單節點
• 叢集:nTB存儲、線上擴容
• 副本集:2TB存儲
• 單節點:高成本效益
高可用
• 架構高可用、跨AZ 部署
• 支援副本集，Shard高可用架構(叢集)
• 副本集多節點(三、五、七)
• 叢集、副本集支援跨AZ部署
高可靠
• 自動/手動備份，資料恢複
• 每天自動備份，保留732天
• 手動備份，永久儲存
• 備份恢複
高安全
• 具備多層安全防護
• 網絡:VPC網絡隔離
• 傳輸:SSL安全連接配接
• 通路:安全組出、入限制
管理、監控
• 可視化監控:CPU、記憶體、10、網絡等
• 執行個體一鍵擴容、規格變更
• 錯誤日志、慢日志管理
• 參數組配置
3.2 DDS 應用場景
靈活多變的業務場景
DDS采用No-Schema的方式，避免變更表結構的痛苦，非常适用于初創型的業務需求。
遊戲應用
作為遊戲伺服器的資料庫存儲使用者資訊，使用者的遊戲裝備、積分等直接以内嵌文檔的形式存儲，友善進行查詢與更新。
視訊直播
存儲使用者資訊，禮物資訊等
3.3 DDS 使用場景舉例：業務彈性擴充，資料結構靈活
遊戲行業業務和資料特點
1.使用者資訊和交易資料存儲在MySQL中。
2.角色裝備資料及遊戲的過程日志存儲在 DDS 中
3.遊戲業務變化頻繁，對于資料表需要做結果變更DDS修改表結構對業務無影響。
客戶痛點(私有雲部署)
1.資源不具備彈性伸縮，需要停服然後手工操作，風險極高。
2.沒有資料庫的故障自動切換機制或能力不足，主執行個體故障，修改應用配置，停服時間長。
3.很少設定專職 DBA 崗位，遇見資料回檔場景，很難滿足營運的訴求。
4.遊戲玩法變化快，資料模型靈活變化
華為雲資料庫的解決方案
1.高性能
RDS MySQL和DDS性能超越阿裡雲。
2.彈性伸縮
RDS和DDS支援磁盤的彈性擴容，對業務無影響。
3.一鍵回檔(遊戲業務資料訴求)
RDS和DDS支援表級和執行個體别任意時間點的回檔。
4. 快讀開服
RDS和DDS，可使用備份建立新執行個體，實作快速開服。
5.故障切換
RDS 和 DDS 主備故障秒級别切換，對業務透明，應用配置無需改動。
4. DDS 管理控制台及運維指南
DDS 服務首頁
DDS 執行個體建立-1
DDS 執行個體建立-2
DDS 執行個體詳情
二、 DDS業務開發使用基礎
1. DDS 高可用連接配接方式
| 參數 | 說明 |
| rwuser:**** | 啟動鑒權的使用者名和密碼。 |
| 192168.0148:8635 192.168.0.96:8635 | 副本集主、備節點的IP及端口号 |
| test | 待連接配接的資料庫名稱。 |
| authSource=admin | 表示鑒權時，使用者名所屬的資料庫。 |
| replicaSet=replica | 副本集執行個體類型名稱。 |
分片叢集高可用址：
mongodb://wuser;****@192.168.0.204:8635.192.168.0.94:8635/test?authSource=admin
多個mongosIP配置在用戶端Driver進行負載均衡
單個mongos故障，其他mongos正常運作
副本集和分片叢集執行個體連接配接失敗場景:
• 網絡端口不通，安全組，跨 vpc
• 是否開啟SSL安全連接配接
• 連接配接參數錯誤，使用者名、密碼錯誤
• DDS執行個體連接配接占滿，無法建立新連接配接
• DDS執行個體記憶體、CPU過高
• 更多詳情參考官方指南:
https://support.huaweicloud.com/dds fa/dds_faq_0218.html
2. DDS 使用者認證及建立
2.1使用者認證
使用者，角色，權限，對象 模型 ---- 基于admin庫建立并管理使用者角色
使用者:userA，userB，userC，角色:role1，role2，role3 權限:userAdmin，readWrite.…
對象:db，collection(action)
檢視目前使用者及角色:
use admin
db.runCommand({rolesinfo: 1});
db.runCommand({ userslnfo: 1} );
舉例幾個常用使用者角色:
管理使用者及角色賬号:userAdminAnyDatabase
db.createUser({user:"user_admin,pwd:"YourPwd_234",roles:[{role:"userAdminAnyDatabase",db:"admin")
管理資料庫賬号:dbAdminAnyDatabase
db.createUser(fuser:"dbadmin"pwd:"YourPwd 234"roles:[{role:"dbAdminAnyDatabase",db:"admin"}l})
·指定庫的管理賬号:dbAdmin
db.createUser({user:"db_admin_db1",pwd:"YourPwd_234",roles:[{role:"dbAdmin",db:"db1"}I})
全庫的隻讀賬号:readAnyDatabase
db.createUser({user:"db_read",pwd:"YourPwd_234",roles:{role: "readAnyDatabase",db:"admin"}})
·指定庫的讀寫賬号:readWrite
db.createUser({user:"db_rw_db2",pwd:"YourPwd_234",roles:[{role:"readWrite",db:"db2"}l})
2.2建立權限使用者
管理使用者登入後可管理庫表不可讀寫資料
隻讀使用者登入後可讀不可寫
3. DDS 用連接配接參數讀寫分離
3.1 讀寫分離場景的選擇
• 生産環境的高可靠運轉，核心元件高可用，提高系統整體可用性及服務品質
• 結合節點部署形态了解 :
•https://supporthuaweicloud.com/bestpractice-dds/dds_0003.html
• 讀寫分離的使用場景
• 怎麼選擇讀參數 Read Preference
primary(隻主)隻從 primary節點讀資料，這個是預設設定
primaryPreferred(先主後從)優先從primary讀取，primary不可服務，從 secondary讀 secondary(隻從)隻從scondary節點讀資料
secondaryPreferred (先從後主)優先從secondary讀取，沒有secondary成員時，從primary讀取 nearest(就近)根據網絡距離就近讀取，根據用戶端與服務端的PingTime實作
3.2 讀寫分離配置使用舉例
讀寫分離配置使用舉例:
可以通過uri連接配接參數配置，也可以再單次查詢操作的時候配置讀取偏好 mongodb://db_rw_db2:YourPwd_234@IP1:port1,IP2:port2/db2?
authSource=admin&replicaSet=replica&readPreference=secondaryPreferred
replica:PRIMARY> db.coll1.find().readPref("secondary");
2021-12-29T11:56:09.435+0000 I NETWORK [js] Successfully connected to 192.168.2
"id":0bjectId("61cc2b7270efbd76daa54891"),"age": 13 }
id" ObjectId("61cc2b7970efbd76daa54892")，"age": 14 }
4. DDS 寫政策配置
一緻性和可用性的一場較量----- 可調一緻性參數
• 寫入政策writeConcern參數使用及預設值
·db.collection.insert({x:1}，{writeConcern:{w:1}})
·mongodb://db_rw_db2:YourPwd 234@IP1:port1P2:port2/db2?
authSource=admin&replicaSet=replica&w=majority&wtimeoutMS=5000
• 分區容錯不可避免
• 業務資料一緻性:實時一緻性，最終一緻性{w:n} {w:“majority"}w預設是1
• 系統服務可用性:讀寫操作的延遲容忍度多節點資料同步依賴oplog複制到備節點
• 業務特征來平衡選擇以上參數取值
寫操作政策再連接配接參數中指定
寫操作政策再單次操作參數中指定
三、 了解DDS核心原理
1. DDS 服務部署模型概述
架構特點
1.高可用服務方式，自動故障轉移，讀寫分離場景
2.支援10GB-3000GB 資料存儲;
3.具備擴充到5節點，7節點副本集的能力。
适用場景
有高可用需求，資料存儲<3T
2. DDS心跳及選舉
2.1 DDS心跳及選舉
• 副本集内，節點之間
• 預設情況，間隔 2s
• 10s未收到主節點響應主動選舉
• 實作自動故障轉移
勝選:
資料相對最新的節點獲得大多數節點選票
2.2 DDS自動故障轉移
副本集節點角色:
• Primary
• Secondary
• Hidden
• Arbiter
故障轉移
• Primary發生異常(節點心跳未正常)
• Secondary發起選舉，主動接管
• Driver連接配接副本集正常業務讀寫
2.3 DDS副本集管理
副本集管理:
• 副本集配置初始化rs.initiate()
• 副本集添加成員 rs.add()
• 副本集删除成員rs.remove()
• 副本集配置檢視rs.config()副本集配置重置rs.reconfig()
• 副本集狀态檢視rs.status()
3. DDS資料同步和複制
3.1 DDS資料同步
多個副本集内資料同步:
• 副本集内，一個Primary，多個Secondary
• 備節點可以承載讀取能力
• 備節點選擇同步源:主節點or其他比自己資料更新的節點
• 允許鍊式複制，減緩主節點壓力
• 資料通過操作記錄重放在備節點
• 随着資料複制推移備節點最新操作時間戳
3.2 DDS資料同步詳解
複制資料關鍵技術點:
• 主節點寫入資料後，記錄oplog
• 備節點拉取oplog√備節點應用oplog
• voplog是固定大小的集合，自然序寫入，無索引
• 多線程并行應用oplog:
• 一個線程内部操作串行執行
• 一個集合的oplog會被一個線程處理
• 不同集合的oplog會被配置設定到不同線程處理
• 更新資料庫狀态，更新最新時間戳
3.3 DDS資料同步注意事項
關于複制的注意事項:
• 副本集内oplogsize固定，寫入資料會淘汰舊的oplog資料
• 空載業務的資料庫執行個體，通過noop特殊操作推移
• noop操作每次間隔10s寫入oplog，少于10s則不寫入
• 業務過載，寫入速度過快導緻複制脫節
• 可以通過write Concern確定寫入多數節點
• 可以指定讀寫分離readPreference
4. DDS 查詢計劃和其他機制
4.1 DDS查詢計劃及索引建議
索引類型:
• 單字段索引
• 組合字段索引
{userid: 1,score:-1}
• 嵌套字段索引
{“addr.zip”}
• 地理位置索引
2dsphere indexes
• 文本索引
• hash索引
索引屬性:
• 唯一索引
• 部分索引
• 稀疏索引
• TTL索引(Time to Live)
通過查詢計劃診斷查詢效果:
• explain計劃分析:傳回文檔、掃描文檔、是否覆寫索引、是否記憶體排序
• queryPlanCache檢視查詢計劃方案緩存情況
4.2 DDS訂閱資料變更場景
訂閱資料變更:
• 通過watch對于一個集合的資料變更進行監聽
• 通過cursor的next持續傳回該集合的資料變更
• full_document='updateLookup’傳回update全文檔
• db.bar.watch(0.{“resumeAfter”:<\_id>})從斷點恢複
• readConcern=true
• 斷點時間可恢複，同理與oplog可用視窗
Change Stream限制:
• 部分DDL操作不支援
• fullDocument傳回的update全文可能被後續操作更改的
• 全量資訊(在頻繁快速更改前提下)
• change stream傳回體限制16M，則原始資料修改需要更小
4.3 DDS其他機制注意事項
文檔&集合建議:
• JSON資料模型(對象模型内聚資料關聯)
• 文檔Size限制16MB
• 一個集合中不建議存儲過量資料
• 有效使用固定集合(size，max)
• 删除資料庫快速釋放記憶體
• 集合總體數量過多導緻記憶體占用過高
四、 快速使用分片叢集
1.DDS服務部署模型概述
DDS服務集部署形态
架構特點
1.元件構成:由mongos(路由)、config(配置)、shard(分片)三種類型的節點構成
2.Shard 分片:每個shard 都是一個副本集架構，負責存
儲業務資料。可建立 2-32個分片，每個分片10GB-2000GB。是以，叢集空間範圍(2-32)*(10GB-2000GB)
3. 擴充能力:線上規格變更、線上橫向擴充
适用場景
要求高可用，資料量大且未來橫向擴充要求
2. DDS分片叢集基本使用
2.1 DDS選擇叢集規模
• 分片叢集部署方式，水準分表，橫向擴充存儲和讀寫能力
• 2個mongos以上，路由子產品提供高可用的接入
• 2個shard以上，具備分片擴充能力
• 一個shard内部以副本集方式服務，具備副本集所有屬性
• 使用者資料庫預設建立非分片，需要指定分庫及分表方式
2.2 DDS選擇片鍵關聯索引
分片鍵建議
類似索引選擇，取值選擇性強的字段、可以是組合字段索引取值單個關聯文檔過多，容易導緻Jumbo chunk確定查詢包含shard key，避免scatter-gather查詢片鍵類型區分HashedRange
>sh.shardCollection("database.collection"{<field>:"hashed"})>sh.shardCollection("database.collection",{<shard key>})
分片鍵舉例:海量裝置日志類型資料
| timestemp range | 時間趨勢導緻新資料集中一個shard 寫請求并不均衡 | 不建議 |
| Timestemp hashed | 根據device id 查詢會廣播到每個shard上、mongos上記憶體排序 | 不建議 |
| Device id hashed | 同一個device 的資料可能帶來Jumbo chunk | 不建議 |
| device_id+timestamp range | 寫入均勻到多個 shard、精細化 chunk 的劃分、支撐範圍查詢 | 建議 |
2.3 DDS 預置chunk及其他建議
• 預置chunk能夠最有效降低均衡帶來的性能消耗
• chunksize預設64MB、資料聚集的邏輯機關
• shard key優選，避免Jumbo chunk
• shard key 取值不超過 512 Bytes
• db.colname.getShardDistribution()#可以檢視資料分布
• scatter-gather查詢産生mongos輸入網卡流量過高
• hash分片方式，建立集合指定預置初始chunks數量
mongos> sh.enableSharding("<database>") mongos> use admin
mongos>db.runCommand({shardcollection:“<database>.<collection>”,key:{“keyname”:“hashed”), numinitialChunks: 1000})
• range分片方式，通過采用分裂點初始化chunks數量
mongos>db.adminCommand({split:"test.coll2middle:{username:1900}})(多次尋找合适切分點，建議采用DRS完整遷移功能)
3. DDS config 及管理操作
3.1DDS config server 及中繼資料
• config database # mongos> use config
• config.shards #db.shards.find()
• config.databases #db.databases.find()
• config.collections #分片集合
• config.chunks #所有chunks的記錄
• config.settings #shard cluster配置資訊
• mongos>db.settings.find()
("id" : "chunksize”, "value": NumberLong(64)}
{"id" : "balancer", "stopped": false )
• config server 存儲整個分片叢集中繼資料
• 以副本集為機關、高可用部署方式
3.2 DDS 叢集管理及最佳實踐
• 添加分片
db.runCommand({addShard:"repl0/mongodb3examplenet:27327"})
• 删除分片 removeShard 會影響chunks的重新配置設定、運作時間過長
• 檢視均衡
mongos>sh.getBalancerState()#檢視是否開啟均衡
mongos>sh.isBalancerRunning0 #檢視是否正在均衡遷移chunk
• 備份時停止、開啟均衡sh.stopBalancer()
sh.setBalancerState(true)
• 重新整理路由資訊
db.adminCommand({flushRouterConfig:"<db.collection>"}) db.adminCommand({ flushRouterConfig: "<db>" } )
db.adminCommand( { flushRouterConfig: 1 })
4.DDS分裂和均衡的基本原理
4.1 DDS分裂基本原理
• 分裂指令
sh.splitFind("records.people"{"zipcode":"63109"})
#比對 zipcode:63109的chunk，分裂為2個或多個chunk sh.splitAt( “records.people”,{ “zipcode”: “63109”))#以zipcode:63109為分裂點，分裂為2個 chunk
• 分裂基本過程
sharding.autoSplit自動分裂預設開啟
插入、更新、删除資料時，mongos判斷chunk是否超過門檻值，觸發chunk分裂
chunk分裂是邏輯動作，基于中繼資料進行标記資料邊界左開右閉[)
chunk内資料shard key是相同的一個值，則無法分裂形成Jumbo chunk
4.2 DDS均衡基本原理
• 遷移指令
db.adminCommand{moveChunk:<namespace>
find : <query>.
to: <string>,
_secondaryThrottle<boolean>，
writeConcern:<document>,
• 遷移指令
db.adminCommand{moveChunk:<namespace>
find : <query>.
to: <string>,
_secondaryThrottle<boolean>，
writeConcern:<document>,
_waitForDelete<boolean>})
• 遷移基本過程
• 由config server 通知發送方shard，并指定遷移chunk任務(一時遷移一個chunk)
• 發送方shard 通知接收方shard主動分批次拷貝資料、增量應用到接收方
• 發送方判斷chunk資料遷移完畢後進入臨界區，寫入操作挂起直到退出臨界區
• 接收方最後拷貝chunk 最後一次增量資料完成commit，完成後接受方退出臨界區
• 接收方最後進行異步删除本地chunk(孤兒chunk)
• 均衡視窗