2013-11-01 38 views
1

每當我們做db.Collection.find()排序(),只有我們的輸出進行排序,而不是集合本身,排序永久收藏在MongoDB中

即如果我做db.collection.find(),然後我看到原始集合,而不是排序的集合。

有什麼辦法來排序集合本身insted只是排序輸出?

將排序後的結果導出到整個新集合中也可以。

+0

您可以使用orderby對您的收藏進行排序 – LHH

+3

您是否有某個特定的原因需要這樣做?存儲的文檔沒有固有的「訂單」。如果您想要經常對特定字段進行排序,請爲其創建索引。 –

+0

@rubyist與做sort()相同。他所問的是,如果有一種方法可以將訂單文件永久排序存儲在集合中,情況並非如此。 –

回答

1

此外,我看不出有任何理由這樣做(在其上你要排序它會幫助你獲得這種快速的領域指數),這裏是你的問題的解決方案:

你有你的測試集這樣

{ "_id" : ObjectId("5273f6987c6c502364ddfe94"), "n" : 5 } 
{ "_id" : ObjectId("5273f6e57c6c502364ddfe95"), "n" : 14} 
{ "_id" : ObjectId("5273f6ee7c6c502364ddfe96"), "n" : -5} 

然後用下面的命令創建一個有序集合你

db.test.find().sort({n : 1}).forEach(function(e){ 
    db.testSorted.insert(e); 
}) 

完全同樣的方式你可以用這個實現(我假設可能會執行得更快,但我沒有做任何測試):

db.testSorted.insert(db.test.find().sort({n : 1}).toArray()); 

而只是爲了讓這個完整的答案,我也明白,這是矯枉過正,你可以用aggregation framework option $out做到這一點。

只需突出顯示:所有這些都可以解決更大的問題:保存到另一個集合中某種修改/之前集合的子集。

+0

插入順序僅爲[ (http://docs.mongodb.org/manual/core/capped-collections/),所以這個建議不會像你所建議的那樣保持一個真正的排序集合。正常集合中的文檔以[自然順序](http://docs.mongodb.org/manual/reference/glossary/#term-natural-order)存儲,受文檔移動的影響(當文檔長於記錄空間分配)和刪除(自由空間可以重新用於插入/移動的文檔)。索引是以期望的排序順序返回文檔的適當方式。 – Stennie

+0

@Stennie謝謝你告訴我關於移動的可能問題。但是我沒有告訴過,這會創建一個集合,隨後將被排序。我剛纔告訴說,手術完成後,收集將被分類。如果您要在集合中進行更新或新插入,則不會保留該訂單。我還強調,唯一的辦法就是做一些排序。 –

0

集合中的文檔被存儲在natural order這是由文件移動的影響(當文檔長得比當前分配的記錄間隔大)和缺失(自由空間可再用於插入/移動文檔)。目前(如MongoDB 2.4)除了使用capped collection之外無法控制磁盤上文檔的順序,這是一個固定大小的集合,用於維護插入順序,但受制於number of restrictions

索引是以期望的排序順序有效返回文檔的適當方式。欲瞭解更多信息,請參閱:MongoDB手冊中的Using Indexes to Sort Query Results

一個相關的功能是clustered index,它將文件存儲在磁盤上以匹配索引排序。這不是MongoDB的當前功能,儘管它已被請求(請參閱SERVER-3294)。