應用程式數據平台和 MongoDB 5.0
MongoDB 公司於 2021 年 7 月宣佈 MongoDB 資料庫將朝向「應用程式數據平台」(Application Data Platform)的方向發展，緊接著宣佈 MongoDB 最新一代版本 5.0 的釋出。這其中到底看到了什麼龐大商機，MongoDB 5.0 的展開又代表了什麼節奏？
什麼是「應用程式數據平台」
隨著 2021 年 7 月 MongoDB.live 年度大會，MongoDB 公司宣布關於資料庫的未來定位 — 「應用程式數據平台」(Application Data Platform)。
MongoDB 公司執行長 Dev Ittycheria 在 7月的採訪中表示：「現今企業面對到快速變動的未來下，意識到應用軟體和資料儼然是核心的競爭力。最好的方式就是讓程式開發人員使用符合自身作法的技術，提高生產效率。」「本次的宣布就是減少開發上的摩擦和複雜程度，方便打造創新且高延展性的應用程式的平台。」
簡單來說，企業為了 Go-to-market 和創新，正在採用了許多新的做法和技術，如：敏捷開發、微服務，以達到快速迭代、快速響應以及自我回復和隨需擴充。但是最後往往發現，在後端底層的資料卻仍逃脫不出各種「煙囪式」的技術棧 (各種 RDBM 和各種 NoSQL)，也往往受限於剛性的 schema，因而產生了效能瓶頸、擴充性低、與前端應用程式的彈性脫鉤的情況。
應用數據平台就是要解決以上的問題，如藉由彈性的 schema 達成各種資料模型的存儲、可以輕鬆使用平台上的廣泛的場景替代單獨「煙囪式」的資料技術，既可以開發操作型工作負載(Operational workload)，也可以開發分析型工作負載(Analytical workload)，並快速響應、隨需擴充。如此一來，企業便可專心提供開發的能量、對於數據支持開發的工作交給該平台就好。
不過，怎麼樣做才能讓願景實現呢？
MongoDB 5.0 的釋出是更加完善該平台的第一步
MongoDB 在 2016 年開始每年進行了一個大版本的升級，其中有三件劃時代的突破：
- 2016 年推出了全託管的雲端版本 MongoDB Atlas。這意味著主要的公有雲 (如 AWS、GCP、Azure) 的服務，都可以輕鬆開通部署運行 MongoDB。讓開發者在使用公有雲的同時，能夠直接選擇正宗 MongoDB 的服務，避免使用到原本在雲平台上「相容 MongoDB 的資料庫」 — 部分 API 相容或者功能不齊全。
- 2018 年版本 4.0 開始推出 ACID 的功能，也就是跨文檔且符合交易一致性的功能。另外在高可用、水平擴充上添加了許多增強機制，增強了高可用的韌性以及擴充的彈性。
- 最後，由於 JSON 的廣泛應用，MongoDB 所除了最主要的 Document 文檔資料模型外，也開始支援各種應用場景：Key-Value、圖資料(Graph)、地理位置查詢等，甚至以 Apache Lucene 打造的全文檢索 — Atlas Search。如下圖：
MongoDB 5.0，就是在上述的基礎上推出了三大革命性的功能。
第一個重磅功能就是支持原生的時間序列 (Time Series) 資料模型！
原生的時間序列資料模型
既然是「原生」(native)，必然是十分直覺化的操作。就和建立一般的 collection 一樣 — 先建立一組時間序列 Time series collection。僅需添加一個 time series field 如下：
db.createCollection("weather", {
timeseries: {
timeField: "ts",
},
});當然可以更細化一點：
db.createCollection("weather", {
timeseries: {
timeField: "ts",
metaField: "source",
granularity: "minutes", },
});因為時序性資料筆數通常非常龐大，很多時候需要自動刪除舊的資料。在這裏利用類似於 TTL 的方式，放這個 expireAfterSeconds 的時間即可。如下：
db.createCollection("weather", {
timeseries: {
timeField: "ts",
metaField: "source",
granularity: "minutes"
},
expireAfterSeconds: 9000
});在 MongoDB 上使用時序的好處
解決煙囪式資料技術問題
好處其實很明顯 — 你不需要再造輪子！市面上時序資料庫品項眾多，且具有技術獨特性，再加上現在應用程式的需求不僅僅是時序，還會搭配交易型、分析型資料庫共同使用。換句話說，資料科學家、開發者、維運人員等不需要擁有各式各樣的時序型資料庫和各種交易型、分析型資料庫，只要了解 MongoDB 基本的設計邏輯，就可以輕鬆解決「煙囪式」的問題。這裡看更多企業使用實例。
接下來看擴充彈性的重要性。
簡述擴充彈性的重要
現在有許多技術可以使應用程式端進行擴充甚至自我修復，如 Kubernetes, 雲端 VM 的 Auto-Scale 功能，搭配 object storage 就可輕鬆完成。可是相對地後端資料要進行擴展和自我修復就顯得困難很多。
Oracle 較進階的機種和現在公有雲上許多服務提供了現代化資料儲存及使用方式，甚至將資料儲存層抽象化。
如：GCP 的 BigQuery / Spanner、AWS 的 DynamoDB / Aurora / Redshift、Azure ADX / Synapse 等。同類型的產品相繼而上，推陳出新，為了就是如何讓資料可以更容易被使用。
MongoDB 怎麼做呢？
- 橫向擴充加上高可用：MongoDB 在提升資料量/筆數的同時可作橫向擴展，線性地提升了 throughput，使得效能提升不會往下掉。搭配高可用，即可達到不停機的狀態。不論是支撐操作型負載，或者是分析型負載都是隨需在線變更。
- 線性成本估算：重要的是，由於線性擴展，因此可以簡單地預測多出來一組分片的成本，而非以查詢次數或者讀取寫入次數來計價。
- 便利性和彈性：MongoDB 的分片不需要擔心資料一致性的問題，因為整個分片叢集(Sharding Cluster)內的資料是 “share-nothing”。同時在此次大版本釋出，也可調整片鍵的問題，不需要「打掉重練」。
當然，MongoDB 的野心不僅於此，在去年年底 MongoDB Atlas 宣佈推出多雲部署，是全世界第一座可以真正跨公有雲部署的資料庫，實現企業多雲策略的第一步！
在線的分片重新分配讓擴充更具彈性
分片(Sharding)是 NoSQL 資料庫的特徵，更是 MongoDB 最為常用的擴充方式之一。以往設計完成後，因為服務特性的變動，造成資料後天傾斜，開始影響效能。若要改動片鍵(Shard Key)，可能要冒著 downtime 的風險 — 況且其中牽涉到許多手動的步驟。或許這還不打緊，最可怕的是要承擔資料可能遺失的風險。作法則有可能像下圖一樣：
為了讓開發或維運更為便利，MongoDB 5.0 推出了在線的分片重新分配(Live Resharding)。顧名思義，不必擔心服務會有 downtime，在線即可重新分配 — 沒錯，在線就可以做了！
只要一行程式碼，背景就會幫你開始重新分配
1. MongoDB 複製您現有的集合 (Collection)
2. 開始將所有新的 oplog 更新從現有集合實施到新集合，並使資料庫能夠跟上傳入的應用程式寫入
3. 當兩個集合同步時，MongoDB 會自動切入新集合並在背景移除舊集合
但是事情總不會都是美好的，在執行前我們仍需考慮幾點：
1. 需要開通更大的硬碟容量因應複製集合
2. 需要額外的 I/O 因應資料搬移
3. 對於重新分配的集合，效能會稍稍下降
4. 對於效能影響的部分，日後會有 benchmark！
資料庫版本更新問題
前面提到 5.0 的兩大新功能，回應了MongoDB 公司定位了資料庫的未來應該是「應用程式數據平台」的樣貌 。如果您也認同這個方向，或許會思考一件事情：「我該如何升級到 5.0？」「升級 5.0 或更往後的版本會有哪些考量？」。
這些 MongoDB 公司都幫您想好了，而且還要簡單
版本升級 API
MongoDB 一直致力於讓開發人員提升生產效率、幫助維運人員降低維運風險。本次劃時代的創舉是利用版本升級 API (Versioned API)，使資料庫進行快速升級。今後 MongoDB 5.0 開始，維持每一年大版本更新 — 針對 community、企業版、Atlas 所有產品適用，如：5.0、6.0 等：
同時，每一季也會有快速版本釋出 (Rapid Release) — 僅 MongoDB Atlas 自動適用，其他產品若要進行快速版本升級需要前往下載中心使用。
或許會擔心「哇！這樣不是要常常改動版本？會不會發生問題？」
1. 上述每一個大版本 EOL 時間皆與現在相同，使用約 3–4 年才會 EOL。
2. 快速釋出版本是針對變化更頻繁的雲端環境所設計，更新 patch 提升產品品質和功能補強。
3. 版本升級時都會建議先進行測試，但是使用版本升級 API 的最大好處就是不再需要動到應用程式，且所有向下相容！Driver 還有您的程式碼跟資料庫的版本 decouple 了！
結論
本篇隆重介紹了「應用程式數據平台」的發展願景和 MongoDB 5.0 的三大劃時代的功能。我們知道這並非一蹴可及，但是資料時代的洪流就是往這個方向移動，讓我們期待更多豐富的技術在 MongoDB 上實現，解決更多實務上有待解決的問題吧！
如果有任何疑問，MongoDB 的技術專家和 MongoDB 台灣臉書社群將協助你使用 MongoDB 實現下一個重要計畫。
p.s. 台灣辦公室的電話：(02) 7743–0622
