MongoDB開發系列-欄位存儲長度使用探討

  • 2019 年 10 月 11 日
  • 筆記

圖-1 場景圖-機場

針對MongoDB中資料庫欄位的存儲字元長度的疑問，本文採用提出問題假設，描述使用場景，給出對應的接入方案的方式，探討MongoDB數據建模中欄位存儲和展示相關的問題，為基於MongoDB的資料庫建模提供參考。

How to improve performance via reduce length of fild in MongoDB

Motivation

提出問題

MongoDB store BSON document in Memery.For most cases, in application development, you will want to use mongoDB databse,specially storing big data.

These are many ways for impving performance of MongoDB Appliction， shoud filed shorter and shorter

1 如何合理的進行MongoDB模式下的資料庫設計與業務建模？

對MongoDB與關係型資料庫在數據建模即資料庫設計的深入理解，不斷在探索合理的進行資料庫設計。

既要符合MongoDB資料庫的設計規範又要兼顧業務程式和應用設計的便利性，同時又要脫離傳統關係型資料庫設計的思維局限和思維慣性。

2 MongoDB設計規範追求的欄位級簡模式是否具有實際意義？

基於MongoDB是基於記憶體的文檔資料庫，出於節約記憶體存儲的考慮，MongoDB中的集合欄位是否應該越短越好。如果欄位越短越好那就失去了欄位本身的語義化作用。

MongoDB設計規範追求的極簡模式更準確的使用場景和實際意義

3 如何在統一系統的不同資訊調用階段對於業務欄位的長短描述做到平衡？

語義化缺失的問題，導致欄位描述與其他資料庫表欄位和程式設計語言中的變數命名規範有衝突。

異構系統介面服務通訊時，同一業務實體的欄位描述風格之間的轉化和平衡問題。

Example Problem

描述問題

以下圖-2【前後端深度分離】的系統開發模式為例，假設node程式開發的一些功能需要藉助MongoDB存儲，而其中的部分數據需要藉助Java的API介面提供，我們可以理解 Node層也是一個業務層，起到承上啟下的作用。

也就是我之前文章中提到的BFF層。介紹一個架構新詞-BFF（這個和微服務也有關係）

這一層基於外部介面做業務，業務數據持久化到MongoDB，那麼在node程式層面就會出現如何將業務變數的命名欄位和MongoDB資料庫集合的欄位相互對應，轉化和存儲的問題。

圖-2 前後端深度分離

通常我們有以下兩種解決方式

第一種：API介面遵守通用的API介面通訊方式，入參採用駝峰命名，返回值採用小寫和下劃線命名。node採用其本身規範，在MongoDB存儲時，程式內部映射為長度較短的key。MongoDb集合中存儲為較短字元的欄位。

數據結構如下

{      "_id" : ObjectId("58b95ceea3ebf44aee3bb995"),      "dt" : ISODate("2017-03-02T00:00:00.000+08:00"),      "pid" : 440000,      "prov" : "廣東省",      "etype" : 1,      "dtime" : ISODate("2017-03-02T02:56:40.000+08:00"),      "ct" : ISODate("2017-03-03T20:09:15.000+08:00"),      "edit" : ISODate("2017-03-03T20:09:15.000+08:00")  }

第二種：對於前端應用本身的數據遵守MongoDB的集合欄位極簡原則，API數據不考慮轉化，直接存儲，數據結構如下

{   "_id" : ObjectId("58b95ceea3ebf44aee3bb995"),  "dateTime" : ISODate("2017-03-02T00:00:00.000+08:00"),  "provinceId" : 440000,  "province" : "廣東省",  "excelType" : 1,  "dateTime" : ISODate("2017-03-02T02:56:40.000+08:00"),  "createTime" : ISODate("2017-03-03T20:09:15.000+08:00"),  "updatetime" : ISODate("2017-03-03T20:09:15.000+08:00"),  }

My Idea

所見即所得

評估系統數量級，保證功能穩定性，簡化應用程式開發難度，這種方式也是業界對於MongoDB所見即所得的高開發效率的一種應用，也就是前端傳遞的欄位可以直接毫無轉化的存入資料庫。

MongoDB欄位長度有限制嗎？

值得注意的是業界資料，官方文檔說明和Mongo社區的線下分享中，關於MongoDB欄位的長度規範，都沒有特別的作為一個重點指出。而且官方的文檔Example中。欄位大多是語義化的，下面的數據集結構摘自官方文檔

{      sku: "00e8da9b",      type: "Audio Album",      title: "A Love Supreme",      description: "by John Coltrane",      asin: "B0000A118M",      shipping: {        weight: 6,        dimensions: {          width: 10,          height: 10,          depth: 1        },      },      pricing: {        list: 1200,        retail: 1100,        savings: 100,        pct_savings: 8      },      details: {        title: "A Love Supreme [Original Recording Reissued]",        artist: "John Coltrane",        genre: ["Jazz", "General"],        ...        tracks: [          "A Love Supreme Part I: Acknowledgement",          "A Love Supreme Part II - Resolution",          "A Love Supreme, Part III: Pursuance",          "A Love Supreme, Part IV-Psalm"        ],      },    }

圖-3 嵌套數據集 

{      sku: "00e8da9b",      type: "Audio Album",      title: "A Love Supreme",      description: "by John Coltrane",      asin: "B0000A118M",      shipping: {        weight: 6,        dimensions: {          width: 10,          height: 10,          depth: 1        },      },      pricing: {        list: 1200,        retail: 1100,        savings: 100,        pct_savings: 8      },      details: {        title: "A Love Supreme [Original Recording Reissued]",        artist: "John Coltrane",        genre: ["Jazz", "General"],        ...        tracks: [          "A Love Supreme Part I: Acknowledgement",          "A Love Supreme Part II - Resolution",          "A Love Supreme, Part III: Pursuance",          "A Love Supreme, Part IV-Psalm"        ],      },    }

在最開始使用MongoDb做系統存儲的很長時間內，我傾向於資料庫存儲欄位應該越短越好，並且不惜犧牲欄位的語義化描述，也就是上文提到的解決方案中的第一種。

隨著對MongoDb設計思路的理解和使用場景的細緻分析，結合應用數據量級，現階段的我認為 所見即所得，語義化的欄位存儲並沒有明顯的劣勢。

在MongoDb數據模型設計時，應該被推薦。不需要刻意的強調欄位越短越優。參看我之前的總結 MongoDB最佳實踐系列-幾個問題梳理和復盤

Tags:

VirMach 便宜 VPS