MongoDB開發(fā)規(guī)范與數(shù)據(jù)建模詳解

更新時(shí)間：2024年08月01日 17:30:04 作者：胡尚

在MongoDB中,遵循良好的開發(fā)規(guī)范和數(shù)據(jù)建模技巧可以提升數(shù)據(jù)庫性能,簡(jiǎn)化數(shù)據(jù)管理,并減少潛在的錯(cuò)誤,這篇文章主要介紹了MongoDB開發(fā)規(guī)范與數(shù)據(jù)建模,需要的朋友可以參考下

MongoDB開發(fā)規(guī)范

1.命名原則

數(shù)據(jù)庫名使用小寫字符，集合名稱使用統(tǒng)一命名風(fēng)格?？梢越y(tǒng)一大小寫或者駝峰命名。數(shù)據(jù)庫名和集合名均不能超過64個(gè)字符

2.集合設(shè)計(jì)

對(duì)于少量數(shù)據(jù)的包含關(guān)系，使用嵌套模式有利于讀寫性能和保證原子性的寫入。對(duì)于復(fù)雜的關(guān)系，以及后期可能發(fā)生演進(jìn)變化的情況，建議使用引用模式

3.文檔設(shè)計(jì)

避免使用大文檔，MongoDB的文檔最大不能超過64MB。
如果使用了內(nèi)嵌子文檔或數(shù)組，應(yīng)該保證內(nèi)嵌數(shù)據(jù)不能無限增長(zhǎng)。在文檔結(jié)構(gòu)上，盡可能減少字段名的長(zhǎng)度，MongoDB會(huì)保存文檔中的字段名，因此整個(gè)字段名的長(zhǎng)度會(huì)影響整個(gè)集合的大小和內(nèi)存的需求。一般建議將字段名控制住32字符以內(nèi)

4.索引設(shè)計(jì)

在必要時(shí)使用索引加速查詢。避免建立過多的索引，單個(gè)集合不建議超過10個(gè)索引。mongodb對(duì)數(shù)據(jù)的寫入很可能會(huì)觸發(fā)索引的寫入，從而觸發(fā)更多的I/O操作。無效的索引會(huì)操作內(nèi)存空間的浪費(fèi)，需及時(shí)清理不需要的索引。
遵循索引優(yōu)化原則，如覆蓋索引、優(yōu)先前綴匹配等，使用explain()命令分析索引性能

5.分片設(shè)計(jì)

對(duì)可能出現(xiàn)快速增長(zhǎng)或讀寫壓力較大的業(yè)務(wù)表考慮分片。分片建的設(shè)計(jì)滿足均衡分布的目標(biāo)，業(yè)務(wù)上盡量避免廣播查詢。應(yīng)盡早決定分片策略，建議在集合達(dá)到256GB之前進(jìn)行分片，如果集合中存在唯一索引，則應(yīng)該確保該索引覆蓋分片建，避免沖突。為了降低風(fēng)險(xiǎn)，單個(gè)分片集數(shù)據(jù)量不建議超過2TB

6.升級(jí)設(shè)計(jì)

應(yīng)用上需支持對(duì)舊版本數(shù)據(jù)的兼容性，在添加唯一性索引約束之前，對(duì)數(shù)據(jù)表進(jìn)行檢查并及時(shí)清理冗余的數(shù)據(jù)。新增/修改數(shù)據(jù)庫對(duì)象需經(jīng)過評(píng)審，并保持對(duì)數(shù)據(jù)字典進(jìn)行更新

7.考慮數(shù)據(jù)老化問題

要及時(shí)清理無效、過期的數(shù)據(jù)。優(yōu)先考慮為系統(tǒng)日志、歷史數(shù)據(jù)表添加合理的數(shù)據(jù)老化策略

8.數(shù)據(jù)一致性方面

非關(guān)鍵業(yè)務(wù)使用writeConcern: 1 。對(duì)于關(guān)鍵業(yè)務(wù)類使用writeConcern: majority 。如果業(yè)務(wù)上嚴(yán)格不允許臟讀，則使用ReadConcern：majority

9.使用update、findAndUpdate對(duì)數(shù)據(jù)進(jìn)行更新時(shí)，如果使用過了upset: true，則必須使用唯一性索引避免產(chǎn)生重復(fù)數(shù)據(jù)

10.業(yè)務(wù)上盡量避免短連接，使用官方最新驅(qū)動(dòng)的連接池實(shí)現(xiàn)，控制客戶端連接的數(shù)量，最大不建議超過200

11.對(duì)大量數(shù)據(jù)寫入使用Bulk Write批量化API，建議使用無序批次更新

12.優(yōu)先使用單文檔事務(wù)保證原子性，如果需要使用多文檔事務(wù)，則必須保證事務(wù)盡可能小，一個(gè)事務(wù)的執(zhí)行時(shí)間最長(zhǎng)不超過60s

13.在條件允許的情況下，使用讀寫分離降低primary節(jié)點(diǎn)的壓力。對(duì)于一些統(tǒng)計(jì)分析類的查詢可優(yōu)先從節(jié)點(diǎn)上讀取

14.考慮業(yè)務(wù)數(shù)據(jù)的隔離，例如將配置項(xiàng)數(shù)據(jù)、歷史數(shù)據(jù)存放在不同的數(shù)據(jù)庫中，微服務(wù)之間使用單獨(dú)的數(shù)據(jù)庫，盡量避免垮庫訪問

15.維護(hù)數(shù)據(jù)字典文檔，并保持更新，提前按不同的業(yè)務(wù)進(jìn)行數(shù)據(jù)容量規(guī)劃

MongoDB數(shù)據(jù)建模

嵌入式文檔一對(duì)一關(guān)系模型

嵌入式文檔模型

以下映射客戶和地址關(guān)系的示例。對(duì)于這種數(shù)據(jù)量較小的文檔使用嵌入式文檔更好

// patron document
{
   _id: "joe",
   name: "Joe Bookreader"
}
// address document
{
   patron_id: "joe", // reference to patron document
   street: "123 Fake Street",
   city: "Faketon",
   state: "MA",
   zip: "12345"
}

如果經(jīng)常將address數(shù)據(jù)與name信息一起檢索，更好的Realm 數(shù)據(jù)模型是將address數(shù)據(jù)嵌入到patron數(shù)據(jù)中，如以下文檔所示：

{
   _id: "joe",
   name: "Joe Bookreader",
   address: {
              street: "123 Fake Street",
              city: "Faketon",
              state: "MA",
              zip: "12345"
            }
}

子集模式

嵌入式文檔模型的一個(gè)潛在問題是，它可能會(huì)導(dǎo)致大型文檔包含應(yīng)用程序不需要的字段。這些不必要的數(shù)據(jù)可能會(huì)給服務(wù)器造成額外負(fù)載，并減慢讀取操作的速度。相反，可以使用子集模式來檢索在單個(gè)數(shù)據(jù)庫調(diào)用中訪問最頻繁的數(shù)據(jù)子集。

考慮一個(gè)顯示電影信息的應(yīng)用程序。 movie數(shù)據(jù)庫包含具有以下模式的collection集合：

{
  "_id": 1,
  "title": "The Arrival of a Train",
  "year": 1896,
  "runtime": 1,
  "released": ISODate("01-25-1896"),
  "poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
  "plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
  "fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
  "lastupdated": ISODate("2015-08-15T10:06:53"),
  "type": "movie",
  "directors": [ "Auguste Lumière", "Louis Lumière" ],
  "imdb": {
    "rating": 7.3,
    "votes": 5043,
    "id": 12
  },
  "countries": [ "France" ],
  "genres": [ "Documentary", "Short" ],
  "tomatoes": {
    "viewer": {
      "rating": 3.7,
      "numReviews": 59
    },
    "lastUpdated": ISODate("2020-01-09T00:02:53")
  }
}

如果應(yīng)用程序顯示電影簡(jiǎn)單概述時(shí)不需要的多個(gè)字段，我們就可以將該collection分割為兩個(gè)collection，而不是將所有電影數(shù)據(jù)存儲(chǔ)在單個(gè)collection中：

電影的基本信息。應(yīng)用程序默認(rèn)加載的數(shù)據(jù)如下：

// movie collection
{
  "_id": 1,
  "title": "The Arrival of a Train",
  "year": 1896,
  "runtime": 1,
  "released": ISODate("1896-01-25"),
  "type": "movie",
  "directors": [ "Auguste Lumière", "Louis Lumière" ],
  "countries": [ "France" ],
  "genres": [ "Documentary", "Short" ],
}

每部電影的其他不常訪問的數(shù)據(jù)：

// movie_details collection
{
  "_id": 156,
  "movie_id": 1, // 通過這個(gè)字段進(jìn)行關(guān)聯(lián)
  "poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
  "plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
  "fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
  "lastupdated": ISODate("2015-08-15T10:06:53"),
  "imdb": {
    "rating": 7.3,
    "votes": 5043,
    "id": 12
  },
  "tomatoes": {
    "viewer": {
      "rating": 3.7,
      "numReviews": 59
    },
    "lastUpdated": ISODate("2020-01-29T00:02:53")
  }
}

嵌入式文檔一對(duì)多關(guān)系模型

嵌入式文檔模型

客戶和多個(gè)地址關(guān)系的示例如下

// patron document
{
   _id: "joe",
   name: "Joe Bookreader"
}
// address documents
{
   patron_id: "joe", // reference to patron document
   street: "123 Fake Street",
   city: "Faketon",
   state: "MA",
   zip: "12345"
}
{
   patron_id: "joe",
   street: "1 Some Other Street",
   city: "Boston",
   state: "MA",
   zip: "12345"
}

如果經(jīng)常檢索帶有name信息的address數(shù)據(jù)，那么就需要發(fā)出多個(gè)查詢來解析引用。更優(yōu)化的模式是將address數(shù)據(jù)實(shí)體嵌入到patron數(shù)據(jù)中，如以下文檔所示：

{
   "_id": "joe",
   "name": "Joe Bookreader",
   "addresses": [
                {
                  "street": "123 Fake Street",
                  "city": "Faketon",
                  "state": "MA",
                  "zip": "12345"
                },
                {
                  "street": "1 Some Other Street",
                  "city": "Boston",
                  "state": "MA",
                  "zip": "12345"
                }
              ]
 }

借助嵌入式數(shù)據(jù)模型，應(yīng)用程序可以通過一次查詢檢索完整的客戶信息。

子集模式

嵌入式文檔模式的一個(gè)潛在問題是，它可能導(dǎo)致文檔過大，尤其是在嵌入式字段沒有限制的情況下。在這種情況下，您可以使用子集模式僅訪問應(yīng)用程序所需的數(shù)據(jù)，而不是訪問整個(gè)嵌入數(shù)據(jù)集

例如，產(chǎn)品評(píng)論列表的電商站點(diǎn)，reviews字段中保存著所有的評(píng)論數(shù)據(jù)：

{
  "_id": 1,
  "name": "Super Widget",
  "description": "This is the most useful item in your toolbox.",
  "price": { "value": NumberDecimal("119.99"), "currency": "USD" },
  "reviews": [
    {
      "review_id": 786,
      "review_author": "Kristina",
      "review_text": "This is indeed an amazing widget.",
      "published_date": ISODate("2019-02-18")
    },
    {
      "review_id": 785,
      "review_author": "Trina",
      "review_text": "Nice product. Slow shipping.",
      "published_date": ISODate("2019-02-17")
    },
    ...
    {
      "review_id": 1,
      "review_author": "Hans",
      "review_text": "Meh, it's okay.",
      "published_date": ISODate("2017-12-06")
    }
  ]
}

評(píng)論按時(shí)間倒序排列。用戶訪問產(chǎn)品頁面時(shí)，應(yīng)用程序會(huì)加載最近十條評(píng)論。

您可以將該集合拆分為兩個(gè)集合，而不存儲(chǔ)該產(chǎn)品的所有評(píng)論：

product collection 存儲(chǔ)每個(gè)產(chǎn)品的信息，包括該產(chǎn)品的 10 條最新評(píng)論：

{
  "_id": 1,
  "name": "Super Widget",
  "description": "This is the most useful item in your toolbox.",
  "price": { "value": NumberDecimal("119.99"), "currency": "USD" },
  "reviews": [
    {
      "review_id": 786,
      "review_author": "Kristina",
      "review_text": "This is indeed an amazing widget.",
      "published_date": ISODate("2019-02-18")
    }
    ...
    {
      "review_id": 777,
      "review_author": "Pablo",
      "review_text": "Amazing!",
      "published_date": ISODate("2019-02-16")
    }
  ]
}

review collection 存儲(chǔ)所有評(píng)論。每條評(píng)論都包含對(duì)相應(yīng)產(chǎn)品的引用。

{
  "review_id": 786,
  "product_id": 1, // 通過該字段進(jìn)行關(guān)聯(lián)
  "review_author": "Kristina",
  "review_text": "This is indeed an amazing widget.",
  "published_date": ISODate("2019-02-18")
}
{
  "review_id": 785,
  "product_id": 1,
  "review_author": "Trina",
  "review_text": "Nice product. Slow shipping.",
  "published_date": ISODate("2019-02-17")
}
...
{
  "review_id": 1,
  "product_id": 1,
  "review_author": "Hans",
  "review_text": "Meh, it's okay.",
  "published_date": ISODate("2017-12-06")
}

文檔引用一對(duì)多關(guān)系模型

以下示例展示如何映射出版商和圖書關(guān)系。該示例說明在避免出版商信息冗余方面，引用比嵌入更有優(yōu)勢(shì)。

將出版商文檔嵌入圖書文檔會(huì)導(dǎo)致出版商數(shù)據(jù)重復(fù)，如以下文檔所示：

// 各個(gè)文檔中都保存publisher 出版商信息，造成了出版商信息冗余
{
   title: "MongoDB: The Definitive Guide",
   author: [ "Kristina Chodorow", "Mike Dirolf" ],
   published_date: ISODate("2010-09-24"),
   pages: 216,
   language: "English",
   publisher: {
              name: "O'Reilly Media",
              founded: 1980,
              location: "CA"
            }
}
{
   title: "50 Tips and Tricks for MongoDB Developer",
   author: "Kristina Chodorow",
   published_date: ISODate("2011-05-06"),
   pages: 68,
   language: "English",
   publisher: {
              name: "O'Reilly Media",
              founded: 1980,
              location: "CA"
            }
}

使用引用并將出版商信息保存在圖書集合之外的單獨(dú)集合中。

使用引用時(shí)，關(guān)系的增長(zhǎng)將決定引用的存儲(chǔ)方式。

如果每個(gè)出版商的圖書數(shù)量較少且增長(zhǎng)有限，則將圖書引用存儲(chǔ)在出版商文檔中有時(shí)可能十分有用。相反，當(dāng)每個(gè)出版商的圖書數(shù)量沒有限制時(shí)，此數(shù)據(jù)模型將導(dǎo)致可變且不斷增長(zhǎng)的數(shù)組，如以下示例所示：

// 出版商信息
// 如果出版商的圖書數(shù)量沒有限制時(shí)，那么下面的books數(shù)組將會(huì)非常大
{
   name: "O'Reilly Media",
   founded: 1980,
   location: "CA",
   books: [123456789, 234567890, ...]
}
// 圖書信息
{
    _id: 123456789,
    title: "MongoDB: The Definitive Guide",
    author: [ "Kristina Chodorow", "Mike Dirolf" ],
    published_date: ISODate("2010-09-24"),
    pages: 216,
    language: "English"
}
{
   _id: 234567890,
   title: "50 Tips and Tricks for MongoDB Developer",
   author: "Kristina Chodorow",
   published_date: ISODate("2011-05-06"),
   pages: 68,
   language: "English"
}

為避免出現(xiàn)可變且不斷增長(zhǎng)的數(shù)組，請(qǐng)將出版商的引用存儲(chǔ)在圖書文檔中：

// 出版商信息
{
   _id: "oreilly",
   name: "O'Reilly Media",
   founded: 1980,
   location: "CA"
}
// 圖書信息
{
   _id: 123456789,
   title: "MongoDB: The Definitive Guide",
   author: [ "Kristina Chodorow", "Mike Dirolf" ],
   published_date: ISODate("2010-09-24"),
   pages: 216,
   language: "English",
   publisher_id: "oreilly"  // 將出版商的引用存儲(chǔ)在圖書文檔中
}
{
   _id: 234567890,
   title: "50 Tips and Tricks for MongoDB Developer",
   author: "Kristina Chodorow",
   published_date: ISODate("2011-05-06"),
   pages: 68,
   language: "English",
   publisher_id: "oreilly"    // 將出版商的引用存儲(chǔ)在圖書文檔中
}

物聯(lián)網(wǎng)時(shí)序數(shù)據(jù)建模

需求

美國(guó)州際公路的流量統(tǒng)計(jì)。數(shù)據(jù)庫需要提供的能力：

存儲(chǔ)事件數(shù)據(jù)
提供分析查詢能力
理想的平衡點(diǎn)：
- 內(nèi)存使用
- 寫入性能
- 讀取分析性能
可以部署在常見的硬件平臺(tái)上

每個(gè)事件用一個(gè)獨(dú)立的文檔存儲(chǔ)

{
    segId: "I80_mile23",
    speed: 63,
    ts: ISODate("2013-10-16T22:07:38.000-0500")
}

非常“傳統(tǒng)”的設(shè)計(jì)思路，每個(gè)事件都會(huì)寫入一條同樣的信息。多少的信息，就有多少條數(shù)據(jù)，數(shù)據(jù)量增長(zhǎng)非?？臁?/li>
數(shù)據(jù)采集操作全部是Insert語句；

每分鐘的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)（存儲(chǔ)平均值）

{
    segId: "I80_mile23",
    speed_num: 18,
    speed_sum: 1134,
    ts: ISODate("2013-10-16T22:07:00.000-0500")
}

對(duì)每分鐘的平均速度計(jì)算非常友好（speed_sum/speed_num）；
數(shù)據(jù)采集操作基本是Update語句；
數(shù)據(jù)精度降為一分鐘；

每分鐘的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)（秒級(jí)記錄）

{
    segId: "I80_mile23",
    speed: {0:63, 1:58, ... , 58:66, 59:64},
    ts: ISODate("2013-10-16T22:07:00.000-0500")
}

每秒的數(shù)據(jù)都存儲(chǔ)在一個(gè)文檔中；
數(shù)據(jù)采集操作基本是Update語句；

每小時(shí)的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)（秒級(jí)記錄）

{
    segId: "I80_mile23",
    speed: {0:63, 1:58, ... , 3598:54, 3599:55},
    ts: ISODate("2013-10-16T22:00:00.000-0500")
}

相比上面的方案更進(jìn)一步，從分鐘到小時(shí)：

每小時(shí)的數(shù)據(jù)都存儲(chǔ)在一個(gè)文檔中；
數(shù)據(jù)采集操作基本是Update語句；
更新最后一個(gè)時(shí)間點(diǎn)（第3599秒），需要3599次迭代（雖然是在同一個(gè)文檔中）

進(jìn)一步優(yōu)化

{
    segId: "I80_mile23",
    speed: {
        0:  {0:47, ..., 59:45},
        ...,
        59: {0:65, ... , 59:56}
    }
    ts: ISODate("2013-10-16T22:00:00.000-0500")
}

用了嵌套的手法把秒級(jí)別的數(shù)據(jù)存儲(chǔ)在小時(shí)數(shù)據(jù)里；
數(shù)據(jù)采集操作基本是Update語句；
更新最后一個(gè)時(shí)間點(diǎn)（第3599秒），需要59+59次迭代；

嵌套結(jié)構(gòu)正是MongoDB的魅力所在，稍動(dòng)腦筋把一維拆成二維，大幅度減少了迭代次數(shù)；

每個(gè)事件用一個(gè)獨(dú)立的文檔存儲(chǔ)VS每分鐘的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)

從寫入上看：后者每次修改的數(shù)據(jù)量要小很多，并且在WiredTiger引擎下，同一個(gè)文檔的修改一定時(shí)間窗口下是可以在內(nèi)存中合并的；

從讀取上看：查詢一個(gè)小時(shí)的數(shù)據(jù)，前者需要返回3600個(gè)文檔，而后者只需要返回60個(gè)文檔，效率上的差異顯而易見；

從索引上看：同樣，因?yàn)榉€(wěn)定數(shù)量的大幅度減少，索引尺寸也是同比例降低的，并且segId，ts這樣的冗余數(shù)據(jù)也會(huì)減少冗余。容量的降低意味著內(nèi)存命中率的上升，也就是性能的提高；

每小時(shí)的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)VS每分鐘的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)

從寫入上看：因?yàn)閃iredTiger是每分鐘進(jìn)行一次刷盤，所以每小時(shí)一個(gè)文檔的方案，在這一個(gè)小時(shí)內(nèi)要被反復(fù)的load到PageCache中，再刷盤；所以，綜合來看后者相對(duì)更合理；

從讀取上看：前者的數(shù)據(jù)信息量較大，正常的業(yè)務(wù)請(qǐng)求未必需要這么多的數(shù)據(jù)，有很大一部分是浪費(fèi)的；

從索引上看：前者的索引更小，內(nèi)存利用率更高；

總結(jié)

那么到底選擇哪個(gè)方案更合理呢？從理論分析上可以看出，不管是小時(shí)存儲(chǔ)，還是分鐘存儲(chǔ)，都是利用了MongoDB的信息聚合的能力。

每小時(shí)的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)：設(shè)計(jì)上較極端，優(yōu)勢(shì)劣勢(shì)都很明顯；
每分鐘的信息用一個(gè)獨(dú)立的文檔存儲(chǔ)：設(shè)計(jì)上較平衡，不會(huì)與業(yè)務(wù)期望偏差較大；

落實(shí)到現(xiàn)實(shí)的業(yè)務(wù)上，哪種是最優(yōu)的？最好的解決方案就是根據(jù)自己的業(yè)務(wù)情況進(jìn)行性能測(cè)試，以上的分析只是“理論”基礎(chǔ)，給出“實(shí)踐”的方向，但千萬不可以此論斷。

到此這篇關(guān)于MongoDB開發(fā)規(guī)范與數(shù)據(jù)建模的文章就介紹到這了,更多相關(guān)MongoDB數(shù)據(jù)建模內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章:

MongoDB 數(shù)據(jù)庫的命名、設(shè)計(jì)規(guī)范詳解

欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MongoDB開發(fā)規(guī)范與數(shù)據(jù)建模詳解

目錄

MongoDB開發(fā)規(guī)范

MongoDB數(shù)據(jù)建模

嵌入式文檔一對(duì)一關(guān)系模型

嵌入式文檔模型

子集模式

嵌入式文檔一對(duì)多關(guān)系模型

嵌入式文檔模型

子集模式

文檔引用一對(duì)多關(guān)系模型

物聯(lián)網(wǎng)時(shí)序數(shù)據(jù)建模

總結(jié)

相關(guān)文章

最新評(píng)論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具

欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MongoDB開發(fā)規(guī)范與數(shù)據(jù)建模詳解

目錄

MongoDB開發(fā)規(guī)范

MongoDB數(shù)據(jù)建模

嵌入式文檔 一對(duì)一關(guān)系模型

嵌入式文檔模型

子集模式

嵌入式文檔 一對(duì)多關(guān)系模型

嵌入式文檔模型

子集模式

文檔引用 一對(duì)多關(guān)系模型

物聯(lián)網(wǎng)時(shí)序數(shù)據(jù)建模

總結(jié)

相關(guān)文章

最新評(píng)論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具

嵌入式文檔一對(duì)一關(guān)系模型

嵌入式文檔一對(duì)多關(guān)系模型

文檔引用一對(duì)多關(guān)系模型