manggodb過濾文檔

❶ 如何正確的使用MongoDB並優化其性能

資料庫性能對軟體整體性能的影響是不言而喻的，那麼，當我們使用MongoDB時改如何提高資料庫性能呢？

1.範式化與反範式化

在項目設計階段，明確集合的用途是對性能調優非常重要的一步。

從性能優化的角度來看，集合的設計我們需要考慮的是集合中數據的常用操作，例如我們需要設計一個日誌（log）集合，日誌的查看頻率不高，但寫入頻率卻很高，那麼我們就可以得到這個集合中常用的操作是更新（增刪改）。如果我們要保存的是城市列表呢？顯而易見，這個集合是一個查看頻率很高，但寫入頻率很低的集合，那麼常用的操作就是查詢。

對於頻繁更新和頻繁查詢的集合，我們最需要關注的重點是他們的範式化程度，在上篇範式化與反範式化的介紹中我們了解到，範式化與反範式化的合理運用對於性能的提高至關重要。然而這種設計的使用非常靈活，假設現在我們需要存儲一篇圖書及其作者，在MongoDB中的關聯就可以體現為以下幾種形式：

1.完全分離（範式化設計）

示例1：

View Code
{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
ObjectId("144b5d83041c7dca84416"),
ObjectId("144b5d83041c7dca84418"),
ObjectId("144b5d83041c7dca84420"),
]
}

我們將作者(comment) 的id數組作為一個欄位添加到了圖書中去。這樣的設計方式是在非關系型資料庫中常用的，也就是我們所說的範式化設計。在MongoDB中我們將與主鍵沒有直接關系的圖書單獨提取到另一個集合，用存儲主鍵的方式進行關聯查詢。當我們要查詢文章和評論時需要先查詢到所需的文章，再從文章中獲取評論id，最後用獲得的完整的文章及其評論。在這種情況下查詢性能顯然是不理想的。但當某位作者的信息需要修改時，範式化的維護優勢就凸顯出來了，我們無需考慮此作者關聯的圖書，直接進行修改此作者的欄位即可。
2.完全內嵌（反範式化設計）

示例2：

View Code

{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
{
"name" : "丁磊"
"age" : 40,
"nationality" : "china",
},
{
"name" : "馬雲"
"age" : 49,
"nationality" : "china",
},
{
"name" : "張召忠"
"age" : 59,
"nationality" : "china",
},
]
}

在這個示例中我們將作者的欄位完全嵌入到了圖書中去，在查詢的時候直接查詢圖書即可獲得所對應作者的全部信息，但因一個作者可能有多本著作，當修改某位作者的信息時時，我們需要遍歷所有圖書以找到該作者，將其修改。
3.部分內嵌（折中方案）

示例3：

View Code

{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
{
"_id" : ObjectId("144b5d83041c7dca84416"),
"name" : "丁磊"
},
{
"_id" : ObjectId("144b5d83041c7dca84418"),
"name" : "馬雲"
},
{
"_id" : ObjectId("144b5d83041c7dca84420"),
"name" : "張召忠"
},
]
}

這次我們將作者欄位中的最常用的一部分提取出來。當我們只需要獲得圖書和作者名時，無需再次進入作者集合進行查詢，僅在圖書集合查詢即可獲得。
這種方式是一種相對折中的方式，既保證了查詢效率，也保證的更新效率。但這樣的方式顯然要比前兩種較難以掌握，難點在於需要與實際業務進行結合來尋找合適的提取欄位。如同示例3所述，名字顯然不是一個經常修改的欄位，這樣的欄位如果提取出來是沒問題的，但如果提取出來的欄位是一個經常修改的欄位（比如age）的話，我們依舊在更新這個欄位時需要大范圍的尋找並依此進行更新。

在上面三個示例中，第一個示例的更新效率是最高的，但查詢效率是最低的，而第二個示例的查詢效率最高，但更新效率最低。所以在實際的工作中我們需要根據自己實際的需要來設計表中的欄位，以獲得最高的效率。

❷ mongodb 一個文檔內數組中同一個欄位 同時大於或小於一個值,如何寫查詢條件

mongodb中使用aggregate可以返回數組欄位數組的指定索引的元素
參考語句：
{$match:{'id':15}},
{$project:{id:1,"default":1}},
{$unwind:"$default.styles"},
{$match:{'default.styles.status':1}},
{$group:{_id:"$_id","defaults":{$push:"$default.styles"}}}
解釋：
1：過濾數據{$match:{'id':15}}
2：獲取想要的列{$project:{id:1,"default":1}}
3：獲取展開後數組欄位{$unwind:"$default.styles"}
4：條件查詢數組元素{$match:{'default.styles.status':1}}
5：分組後保存結果{$group:{_id:"$_id","defaults":{$push:"$default.styles"}}}
數據結構如下：
{
"_id" : ObjectId("55dad346ea23e7c11beefce5"),
"id" : 11.0,
"default" : {
"style" : "普通會診",
"alias" : "",
"money" : "0",
"styles" : [{
"code" : 1,
"style" : "普通會診",
"alias" : "一般會診",
"money" : 100,
"status" : 1,
"remark" : "需要患者親自來到醫院"
} {
"code" : 6,
"style" : "夜間門診",
"alias" : "夜間門診",
"money" : 100,
"status" : 0,
"remark" : "夜間門診"
}, {
"code" : 7,
"style" : "其他門診",
"alias" : "其他門診",
"money" : 10,
"status" : 0,
"remark" : "其他門診"
}]
}
}

❸ mongodb 集合中 數據 文檔 什麼意思

簡介MongoDB1是一個基於分布式文件存儲的資料庫。由C++語言編寫。旨在為WEB應用提供可擴展的高性能數據存儲解決方案。 MongoDB2是一個介於關系資料庫和非關系資料庫之間的產品，是非關系資料庫當中功能最豐富，最像關系資料庫的。他支持的數據結構非常鬆散，是類似json的bson格式，因此可以存儲比較復雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關系資料庫單表查詢的絕大部分功能，而且還支持對數據建立索引。3特點它的特點是高性能、易部署、易使用，存儲數據非常方便。主要功能特性有： *面向集合存儲，易存儲對象類型的數據…

例句:
1.
Some, like mongodb, help to develop open source technologies.
一些工具，比如MongoDB，能夠幫助開發開源技術。

❹ mongodb的基本概念

（1）文檔
文檔是 MongoDB 中數據的基本單位，類似於關系資料庫中的行（但是比行復雜）。多個鍵及其關聯的值有序地放在一起就構成了文檔。不同的編程語言對文檔的表示方法不同，在JavaScript 中文檔表示為：
{「greeting」:「hello,world」}
這個文檔只有一個鍵「greeting」，對應的值為「hello,world」。多數情況下，文檔比這個更復雜，它包含多個鍵/值對。例如：
{「greeting」:「hello,world」,「foo」: 3}
文檔中的鍵/值對是有序的，下面的文檔與上面的文檔是完全不同的兩個文檔。
{「foo」: 3 ,「greeting」:「hello,world」}
文檔中的值不僅可以是雙引號中的字元串，也可以是其他的數據類型，例如，整型、布爾型等，也可以是另外一個文檔，即文檔可以嵌套。文檔中的鍵類型只能是字元串。
（2）集合
集合就是一組文檔，類似於關系資料庫中的表。集合是無模式的，集合中的文檔可以是各式各樣的。例如，{「hello,word」:「Mike」}和{「foo」: 3}，它們的鍵不同，值的類型也不同，但是它們可以存放在同一個集合中，也就是不同模式的文檔都可以放在同一個集合中。既然集合中可以存放任何類型的文檔，那麼為什麼還需要使用多個集合？這是因為所有文檔都放在同一個集合中，無論對於開發者還是管理員，都很難對集合進行管理，而且這種情形下，對集合的查詢等操作效率都不高。所以在實際使用中，往往將文檔分類存放在不同的集合中，例如，對於網站的日誌記錄，可以根據日誌的級別進行存儲，Info級別日誌存放在Info 集合中，Debug 級別日誌存放在Debug 集合中，這樣既方便了管理，也提供了查詢性能。但是需要注意的是，這種對文檔進行劃分來分別存儲並不是MongoDB 的強制要求，用戶可以靈活選擇。
可以使用「.」按照命名空間將集合劃分為子集合。例如，對於一個博客系統，可能包括blog.user 和blog.article 兩個子集合，這樣劃分只是讓組織結構更好一些，blog 集合和blog.user、blog.article 沒有任何關系。雖然子集合沒有任何特殊的地方，但是使用子集合組織數據結構清晰，這也是MongoDB 推薦的方法。
（3）資料庫
MongoDB 中多個文檔組成集合，多個集合組成資料庫。一個MongoDB 實例可以承載多個資料庫。它們之間可以看作相互獨立，每個資料庫都有獨立的許可權控制。在磁碟上，不同的資料庫存放在不同的文件中。MongoDB 中存在以下系統資料庫。
● Admin 資料庫：一個許可權資料庫，如果創建用戶的時候將該用戶添加到admin 資料庫中，那麼該用戶就自動繼承了所有資料庫的許可權。
● Local 資料庫：這個資料庫永遠不會被負責，可以用來存儲本地單台伺服器的任意集合。
● Config 資料庫：當MongoDB 使用分片模式時，config 資料庫在內部使用，用於保存分片的信息。

❺ 如何刪除MongoDB資料庫中的文件

一、Insert操作

Insert操作是MongoDB插入數據的基本方法，對目標集合使用Insert操作，會將該文檔添加到MongoDB並自動生成相應的ID鍵。文檔結構採用類似JSON的BSON格式。常見的插入操作主要有單條插入和批量插入兩種形式。插入時只是簡單地將文檔存入資料庫中，不進行額外的驗證，也不會執行代碼，所以不存在注入式攻擊的可能。

1、單條插入

四、瞬間完成

上面的插入，刪除和更新操作都是瞬間完成的，不需要等待資料庫響應。這樣的實現可以獲取高性能，速度非常快，只會受客戶端發送速度和網路速度的制約。但由於不會獲取伺服器狀態，所以不能保證操作順利完成。這對於付費系統，安全性較高的系統是不可行的，此時對這些操作需要使用的安全版本。安全版本會在操作執行後立即運行getLastError命令，來檢查是否執行成功。如果失敗一般會拋出可捕獲的異常，然後可以在代碼中處理。

❻ 如何保證文檔內容唯一 mongodb

在MongoDB中，如果不特別指定，每個文檔都會生成一個唯一的ObjectId作為其主鍵_id的值。這個值是一個看似隨機的串。這個串到底是什麼值？為什麼MongoDB要使用這個值作為默認主鍵？它內部又包含了什麼樣的信息？如果你還不了解，就請看下面文章吧。

MongoDB中數據的基本單元稱為文檔(Document)。文檔是MongoDB的核心概念，多個鍵極其關聯的值有序的放置在一起便是文檔。

在一個特定集合內部，需要唯一的標識文檔。因此MongoDB中存儲的文檔都由一個」_id」鍵，用於完成此功能。這個鍵的值可以是任意類型的，默認試ObjectId對象。ObjectId對象的生成思路是本文的主題，也是很多分布式系統可以借鑒的思路。

為了考慮分布式，「_id」要求不同的機器都能用全局唯一的同種方法方便的生成它。因此不能使用自增主鍵（需要多台伺服器進行同步，既費時又費力），因此選用了生成ObjectId對象的方法。

ObjectId使用12位元組的存儲空間，其生成方式如下：

0 1 2 3 4 5 6 7 8 9 10 11
時間戳 機器ID PID 計數器
前四個位元組時間戳是從標准紀元開始的時間戳，單位為秒，有如下特性：

時間戳與後邊5個位元組一塊，保證秒級別的唯一性；
保證插入順序大致按時間排序；
隱含了文檔創建時間；
機器ID是伺服器主機標識，通常是機器主機名的散列值。

同一台機器上可以運行多個mongod實例，因此也需要加入進程標識符PID。

前9個位元組保證了同一秒鍾不同機器不同進程產生的ObjectId的唯一性。後三個位元組是一個自動增加的計數器（一個mongod進程需要一個全局 的計數器），保證同一秒的ObjectId是唯一的。同一秒鍾最多允許每個進程擁有（256^3 = 16777216）個不同的ObjectId。

總結一下：時間戳保證秒級唯一，機器ID保證設計時考慮分布式，避免時鍾同步，PID保證同一台伺服器運行多個mongod實例時的唯一性，最後的計數器保證同一秒內的唯一性（選用幾個位元組既要考慮存儲的經濟性，也要考慮並發性能的上限）。

「_id」既可以在伺服器端生成也可以在客戶端生成，在客戶端生成可以降低伺服器端的壓力。

❼ mongodb 索引是什麼數據結構

MongoDB索引使用B-tree數據結構。

索引支持MongoDB中查詢的高效執行。如果沒有索引，MongoDB必須執行集合掃描，即掃描集合中的每個文檔，以選擇與查詢語句匹配的文檔。如果查詢存在適當的索引，MongoDB可以使用索引來限制它必須檢查的文檔數。

(7)manggodb過濾文檔擴展閱讀

MongoDB索引的類型

1、單欄位索引（Single Field Index）

這個是最簡單最常用的索引類型，比如我們上邊的例子，為id建立一個單獨的索引就是此種類型。

2、復合索引（Compound Index）

索引field的先後順序很關鍵，影響有兩方面：

（1）MongoDB在復合索引中是根據prefix排序查詢，就是說排在前面的可以單獨使用。

（2）過濾出的document越少的field越應該放在前面，比如此例中id如果是唯一的，那麼就應該放在最前面，因為這樣通過id就可以鎖定唯一一個文檔。而如果通過city或者score過濾完成後還是會有大量文檔，這就會影響最終的性能。

索引的排序順序不同：復合索引最末尾的field，其排序順序不同對於MongoDB的查詢排序操作是有影響的。

3、多key索引（Multikey Index）：主要針對數據類型為數組的類型。

4、其它類型索引：另外，MongoDB中還有其它如哈希索引，地理位置索引以及文本索引，主要用於一些特定場景。