建站
咨詢
售后
建站咨詢
新聞中心
這幾天抱怨MongoDB的帖子相當(dāng)受追捧。大多是關(guān)于在特定的數(shù)據(jù)集，可靠性和分片問(wèn)題上表現(xiàn)不佳。其中一些博客文章可能是正確的，其他的只是說(shuō),***的NoSQL的解決方案并沒(méi)有滿足他們的需求。
東港網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),東港網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為東港上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的東港做網(wǎng)站的公司定做！
這篇文章不是其中之一，雖然大多數(shù)的文章關(guān)注操作部分,基準(zhǔn)測(cè)試和性能特征，而我想談?wù)凪ongoDB查詢接口。沒(méi)錯(cuò)——編程接口，特別是關(guān)于Node.js的，但這個(gè)在不同語(yǔ)言平臺(tái)和Mongo-shell上都差不多。
免責(zé)聲明：我努力不去恨MongoDB。事實(shí)上我每個(gè)工作日都在使用MongoDB，它已經(jīng)成為我全職工作的一部分。我也參與Minimongo的 開(kāi)發(fā)，使用內(nèi)存緩存用純javascript克隆MongoDB的API。我沒(méi)有任何理由嘲笑Mongo只是警告大家這些意想不到的問(wèn)題。他們大多數(shù)由 David Glasser發(fā)現(xiàn)。本文假定您熟悉MongoDB的API。
1. 哈希對(duì)象中key的順序
比如，你要存儲(chǔ)一個(gè)簡(jiǎn)單的文字對(duì)象：:
- > db.books.insert({ title: "Woe from Wit", meta: { author: "A. Griboyedov", year: 1823 } });
太棒了！現(xiàn)在我們有了一條書籍記錄。再比如，以后我們會(huì)想找所有1823年出版的作者是 A. Griboyedov 的書。這里不太可能返回多個(gè)結(jié)果，但至少應(yīng)該有《 Woe from Wit 》這本書，因?yàn)槲覀儎倓偛迦肓诉@條記錄，對(duì)不對(duì)？
- > db.books.find({ meta: { year: 1823, author: "A. Griboyedov" } });
- < No results returned
發(fā)生了什么？我們不是剛剛插入了這本書的數(shù)據(jù)嗎？讓我們嘗試調(diào)換key的順序：
- > db.books.find({ meta: { author: "A. Griboyedov", year: 1823 } });
- < { _id: ..., title: "Woe from Wit", meta: { ... } }
搞定了!
陷阱: 在MongoDB中key的順序非常重要，{ a: 1, b: 2 } 和 { b: 2, a: 1 }是不匹配的。
為什么: MongoDB使用叫做BSON的二進(jìn)制數(shù)據(jù)格式。在BSON中key的順序非常重要。注意，JSON對(duì)象是一個(gè)無(wú)序的鍵/值對(duì)集合。
那么在JavaScript里是怎樣的呢？ECMA-262可沒(méi)有規(guī)定（JS屬性順序）這件事。在某些瀏覽器下（通常是舊的）對(duì)屬性的順序不會(huì)太在意，這意味著它們可以是任何順序（只要存在就行）。值得慶幸的是大多數(shù)現(xiàn)代瀏覽器的JavaScript引擎在維護(hù)JS屬性的順序（有時(shí)甚至在數(shù)組中也維護(hù)） ，因此實(shí)際上我們可以使用node.js來(lái)控制它。
更多內(nèi)容請(qǐng)參閱 John Resig's blog.
問(wèn)題的答案是：要么給出規(guī)范形式（鍵按字典順序排序） ，要么就使得你自己的代碼中是一致的。
當(dāng)然，這里有其它的解決方法。使用另一種查詢方法（selector），即指定那些特定的屬性項(xiàng)（key-path），而不是比較對(duì)象的文本信息：
- > db.books.find({ 'meta.year': 1823, 'meta.author': 'A. Griboyedov' });
這種特殊情況下這樣的查詢方式是有效地，但請(qǐng)注意，這個(gè)查詢語(yǔ)句的含義是不同的。
陷阱: 每當(dāng)你想建立一個(gè)擁有多鍵值索引的數(shù)據(jù)的時(shí)候這種行為是很危險(xiǎn)的。
- > db.books.ensureIndex({ title: 1, 'meta.year': -1 });
這樣的命令會(huì)使得title的優(yōu)先級(jí)會(huì)比 meta.year 的優(yōu)先級(jí)高。這在MongoDB中是一個(gè)很重要的分析數(shù)據(jù)的方式。更多內(nèi)容請(qǐng)參閱MongoDB docs.
2. undefined, null and undefined
想必很多人都還記得那個(gè)undefined, null 的關(guān)系、特性很混亂的時(shí)候吧！在JavaScript的世界中undefined、null代表著兩個(gè)不同的值，嚴(yán)格來(lái)說(shuō)它們是不一樣 的：undefined！== NULL。當(dāng)然，在非嚴(yán)格的情況下他們確實(shí)相等：undefined == null。有些人很小心的使用它們，而另一部分人將兩者隨意交替使用。說(shuō)到底我們的問(wèn)題是：JavaScript確實(shí)存在兩個(gè)不同但很相似的值。
MongoDB的帶來(lái)了它帶到一個(gè)新的水平。BSON里將未定義規(guī)定為"deprecated"。 BSON spec規(guī)定undefined為“deprecated”.
然而Node.js中的node-native-driver for MongoDB卻沒(méi)有實(shí)現(xiàn)它。
Node.js目前的版本（2.4.8）特性表明null和undefined是兩個(gè)相同的值。
- > db.things.insert({ a: null, b: 1 });
- > db.things.insert({ b: 2 }); // the 'a' is undefined implicitly
- > db.things.find({ a: null });
- < { a: null, b: 1 }
- < { b: 2 }
我不確定node driver for MongoDB中的實(shí)現(xiàn)情況，不過(guò)看起來(lái)像是node driver直接將undefined轉(zhuǎn)換為null，但是這在mongo-shell里是被限制的（因?yàn)樵贛ongoDB里undefined和 null本來(lái)就是兩個(gè)值--譯者注）。
- // from node.js code with mongo/node-native-driver
- db.things.insert({ a: null, b: 1 });
- db.things.insert({ b: 2 });
- db.things.insert({ a: undefined, b: 3 });
- console.log(db.things.find({ a: null }).fetch())
- console.log(db.things.find({ a: undefined }).fetch())
然而，在mongo-shell中你只能使用null來(lái)查詢，注意，我們所使用的三個(gè)對(duì)象和上面的是一樣的。
- // from mongo-shell
- > db.things.find({a: undefined});
- < error: { "$err" : "can't have undefined in a query expression", "code" : 13629 }
- > db.things.find({a: null});
- < { "a" : null, "b" : 1, "_id" : "wMWNPm7zrYXTNJpiA" }
- < { "b" : 2, "_id" : "RjrYvmZF5EukhpuAY" }
- < { "a" : null, "b" : 3, "_id" : "kethQ2khbyfFjJ7Sa" }
我們可以看到，mongo/node-native-driver 顯式的將undefined轉(zhuǎn)換null但實(shí)際上左邊隱式的那個(gè)才是我們真正想要的（我們期望的真實(shí)結(jié)果）。
當(dāng)我們使用mongo-shell顯式的插入undefined的時(shí)候，有趣的事情發(fā)生了：
- // from mongo-shell
- > db.things.insert({ a: undefined, b: 4 });
- > db.things.find({ a: null })
- < { "a" : null, "b" : 1, "_id" : "wMWNPm7zrYXTNJpiA" }
- < { "b" : 2, "_id" : "RjrYvmZF5EukhpuAY" }
- < { "a" : null, "b" : 3, "_id" : "kethQ2khbyfFjJ7Sa" }
我們得到相同的三個(gè)值，但并沒(méi)有我們剛才在mongo-shell里插入的 b=4的對(duì)象。undefined不是和null相等嗎？好吧，讓我們來(lái)看看這個(gè)新的對(duì)象：
- > db.things.find({ b: 4 });
- < { "_id" : ObjectId("52ca134f3e47d3d91146f2b5"), "a" : null, "b" : 4 }
它仍然在那里，雖然a屬性的值很像是null，但與我們的選擇器卻不匹配。
陷阱：有2個(gè)以上的值在MongoDB中看起來(lái)像null： null，undefined以及隱式的向mongo-shell里插入的undefined，雖然看起來(lái)像null但在實(shí)際情況下和BSON（第6版） 中的undefined 相匹配。***一個(gè)在選擇器上并不和null匹配，前兩者都匹配undefined和null。這也說(shuō)明了沒(méi)有值同樣可以匹配前兩者。
原始問(wèn)題請(qǐng)參閱 GitHub issue。
#p#
3. Soft limits, hard limits and no limits
你有一個(gè)項(xiàng)目的輸入并且允許用戶指定數(shù)字項(xiàng)目返回。你應(yīng)該把問(wèn)題的結(jié)果像這樣返回：
- db.items.find({ ... }).limit(N);
N值是由 用戶供給的。我們當(dāng)然希望小心的將用戶限制在50之內(nèi)，否則網(wǎng)絡(luò)上的任何人只需簡(jiǎn)單地提供一個(gè)非常大的N值都可以下載我們的應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)。
- function getItems (N) {
- if (N > 50)
- N = 50;
- return db.items.find({}).sort({ year: 1 }).limit(N);
- }
看起來(lái)是個(gè)有道理運(yùn)行在你的node.js app上的代碼。
陷阱：如果用戶提供0作為一個(gè)項(xiàng)目的值，他希望MongoDB可以理解為把所有都給他。
這在文檔里寫的很清楚，但很多情況下并不是那么顯然：在MongoDB中零表示無(wú)限制。我猜想MongoDB的代碼可能將undefined, null, 0等等所有的false值當(dāng)做無(wú)限制對(duì)待。
這沒(méi)關(guān)系，我們可以對(duì)0進(jìn)行單獨(dú)處理：
- function getItems (N) {
- if (N > 50 || !N) // check if N is falsy ("no limit")
- N = 50;
- return db.items.find({}).sort({ year: 1 }).limit(N);
- }
看上去不錯(cuò)？但是如果用戶輸入一個(gè)負(fù)值怎么辦？這可能么？這又意味著什么？
事實(shí)上像 db.items.find().limit(-1000000000000)這類的語(yǔ)句可能返回非常多的項(xiàng)。很難找到相關(guān)的文檔，但幾個(gè)月前我在 node.js的驅(qū)動(dòng)文檔中看到一篇文章描述了這種行為，它將其表述為“硬”限制和“軟”限制。我不知道這是什么意思。 那么我們服務(wù)器端方法的最終版就是這樣了：
- function getItems (N) {
- if (N < 0) N = -N;
- if (N > 50 || !N) // check if N is falsy ("no limit")
- N = 50;
- return db.items.find({}).sort({ year: 1 }).limit(N);
- }
總結(jié)： 限制可以是負(fù)數(shù)。它在廣義上和正數(shù)是一樣的但是負(fù)數(shù)限制是“軟限制”。
4.數(shù)組的特殊待遇
很多人并不知道這個(gè)特性，但數(shù)組確實(shí)是經(jīng)過(guò)特殊處理的。
- > db.c.insert({ a: [{x: 2}, {x: 3}], _id: "aaa"})
- > db.c.find({'a.x': { $gt: 1 }})
- < { "_id" : "aaa", "a" : [ { "x" : 2 }, { "x" : 3 } ] }
- > db.c.find({'a.x': { $gt: 2 }})
- < { "_id" : "aaa", "a" : [ { "x" : 2 }, { "x" : 3 } ] }
- > db.c.find({'a.x': { $gt: 3 }})
- < Nothing found
因此每當(dāng)有一個(gè)數(shù)組對(duì)象，選擇器都會(huì)“分發(fā)”給每一個(gè)元素，這就像“如果其中一個(gè)元素匹配，那么整個(gè)文檔（document)都會(huì)被匹配”。
值得注意的是，它并不適用于嵌套數(shù)組：
- > db.x.insert({ _id: "bbb", b: [ [{x: 0}, {x: -1}], {x: 1} ] })
- > db.x.find({ 'b.x': 1 })
- < { "_id" : "bbb", "b" : [ [ { "x" : 0 }, { "x" : -1 } ], { "x" : 1 } ] }
- > db.x.find({ 'b.x': 0 })
- < Nothing found
- > db.x.find({ 'b.x': -1 })
- < Nothing found
同樣也適用于預(yù)測(cè)數(shù)組中字段（field）的一些特性：
- > db.z.insert({a:[[{b:1,c:2},{b:2,c:4}],{b:3,c:5},[{b:4, c:9}]]})
- > db.z.find({}, {'a.b': 1})
- < { "_id" : ObjectId("52ca24073e47d3d91146f2b7"), "a" : [ [ { "b" : 1 }, { "b" : 2 } ], { "b" : 3 }, [ { "b" : 4 } ] ] }
如果我們?cè)谶x擇器上將以上特性與使用數(shù)字鍵做更多的組合，那么這個(gè)特性將變得越來(lái)越難以預(yù)測(cè)：
- > db.z.insert({a: [[{x: "00"}, {x: "01"}], [{x: "10"}, {x: "11"}]], _id: "zzz"})
- > db.z.find({'a.x': '00'})
- < Nothing found
- > db.z.find({'a.x': '01'})
- < Nothing found
- > db.z.find({'a.x': '10'})
- < Nothing found
- > db.z.find({'a.x': '11'})
- < Nothing found
- > db.z.find({'a.0.0.x': '00'})
- < { "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
- > db.z.find({'a.0.0.x': '01'})
- < Nothing found
- > db.z.find({'a.0.x': '00'})
- < { "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
- > db.z.find({'a.0.x': '01'})
- < { "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
- > db.z.find({'a.0.x': '10'})
- < Nothing found
- > db.z.find({'a.0.x': '11'})
- < Nothing found
- > db.z.find({'a.1.x': '00'})
- < Nothing found
- > db.z.find({'a.1.x': '01'})
- < Nothing found
- > db.z.find({'a.1.x': '10'})
- < { "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
- > db.z.find({'a.1.x': '11'})
- < { "_id" : "zzz", "a" : [ [ { "x" : "00" }, { "x" : "01" } ], [ { "x" : "10" }, { "x" : "11" } ] ] }
好的，我們?cè)賮?lái)稍作改動(dòng)。這個(gè)和上一個(gè)案例的區(qū)別僅僅是內(nèi)部值的改動(dòng)：在上一個(gè)案例中是一個(gè)對(duì)象，在下面的案例中將會(huì)是一個(gè)數(shù)字。這足以讓數(shù)組的特性發(fā)生改變：
- > db.p.insert({a: [0], _id: "xxx"})
- > db.p.find({'a': 0})
- < { "_id" : "xxx", "a" : [ 0 ] }
- > db.q.insert({a: [[0]], _id: "yyy"})
- > db.q.find({a: 0})
- < Nothing found
- > db.q.find({'a.0': 0})
- < Nothing found
- > db.q.find({'a.0.0': 0})
- < { "_id" : "yyy", "a" : [ [ 0 ] ] }
陷阱: 盡可能的避免數(shù)組或者嵌套數(shù)組以及其他一對(duì)多關(guān)系的數(shù)據(jù)存在于文檔之中，并且在需要查詢的時(shí)候，通常我們傾向 于按照一對(duì)一關(guān)系去查詢。然而對(duì)于使用數(shù)字鍵（例如{ 'a.0.x': Y }意味著字段a的***個(gè)元素的x字段必須為Y）的混合型文檔很可能會(huì)讓人感覺(jué)非常別扭，當(dāng)然這也取決于數(shù)據(jù)的復(fù)雜程度。
#p#
5. 地理定位操作符$near
這個(gè)操作符很簡(jiǎn)單。你擁有大量包含位置字段的文檔。位置字段表示的是地理位置信息。技巧就是MongoDB可以對(duì)兩種不同類型的位置信息進(jìn)行索引，每種類型都有稍微不同的API和行為。
***種類型如下：
- db.c.find({
- location: {
- $near: [12.3, 32.1],
- $maxDistance: 777
- }});
第二種類型如下：
- db.c.find({
- location: {
- $near: {
- $geometry: {
- type: "Point",
- coordinates: [ 12.3, 32.1 ]
- },
- $maxDistance: 777
- }
- }});
對(duì)每個(gè)被索引類型來(lái)說(shuō)，地理信息查詢語(yǔ)法稍稍有些不同。在通常所用的地理位置信息配對(duì)中$maxDistance與$near處于同等地位，而在Geo-JSON表示的地理位置信息配對(duì)中$maxDistance就是$near的子元素。
然而，還不止這些！有時(shí)你在結(jié)果集中會(huì)兩次獲得同一個(gè)位置點(diǎn)！為了能夠理解這一點(diǎn)，我們需要回想一下前一個(gè)嵌套數(shù)組里存在的缺陷?？纯聪旅娲a：
- > db.c.insert({ location: [[1, 2], [1, 0]] }); // inserting an array of two points> db.c.ensureIndex({ location: "2d" });
- > db.c.find({ location: { $near: [0, 0], $maxDistance: 500 } });
- < { "_id" : ObjectId("52ca30ec3e47d3d91146f2b8"), "location" : [ [ 1, 2 ], [ 1, 0 ] ] }
- < { "_id" : ObjectId("52ca30ec3e47d3d91146f2b8"), "location" : [ [ 1, 2 ], [ 1, 0 ] ] }
從匹配給定選擇子的數(shù)組里返回同一個(gè)位置點(diǎn)兩次，認(rèn)為是兩個(gè)位置點(diǎn)。
在我開(kāi)始使用Javascript編程的時(shí)候這些陷阱給提了醒。這里有一些我們平時(shí)不容易察覺(jué) 的情況，其中一些跨瀏覽器效果不一致，還有一些你幾乎用不到的特性，因此在某些情況下你要格外小心。以上這些都是眾所周知的JavaScript領(lǐng)域中的 問(wèn)題，但在MongoDB領(lǐng)域中也沒(méi)有處理的那么好。
幾乎所有怪異的特性都在模擬MongoDB的過(guò)程中發(fā)現(xiàn)，然后整理并列舉在這里，這個(gè)模擬MongoDB的項(xiàng)目叫做Minimongo, 主要由 David Glasser貢獻(xiàn).
如果有新的缺陷，這里（這篇文章）還會(huì)持續(xù)更新。
標(biāo)題名稱：MongoDB在語(yǔ)法上的5大缺陷
標(biāo)題鏈接：http://www.fisionsoft.com.cn/article/djssjhd.html
