我有一個應用程序不斷地將文檔插入到MongoDB集合中。MongoDB - 反映插入順序的字段
我正在尋找一種方法來查詢其插入順序後的文檔。
候選人我想用:
- 的
_id
場 - 創建日期域
- 序列號(自動遞增)
的_id
領域是不是一個好候選人作爲文檔說。創建日期字段可能是一個很好的候選字段,但時鐘可能不同步的事實可能會破壞訂單。關於序列號,文件提出了兩種方法:計數器和樂觀循環。由於文檔D1
可能會插入另一個文檔D2
,即使D1.seq < D2.seq
,計數器方法也不能保證插入順序。例如,如果D1
獲取序列號5,則D2
獲取序列號6,然後插入D2
,然後插入D1
。樂觀循環的方法是瘋狂的情況下,沉重的插入環境。
有沒有另一種方法?
編輯:
使用計數器的方法是有問題的。考慮以下情況。我有一個應用程序A
,它不斷地將文檔插入到一個集合中。我還有另一個應用程序B
,它不斷地輪詢來自同一個集合的文檔。應用程序A
是多線程的。兩個線程T1
和T2
分別將插入文檔D1
和D2
。在插入過程中,應用程序B
要求提供更多文檔。假設以下的操作順序:
- 主題
A-T1
抓住下一個序列號N
- 主題
A-T2
抓住下一個序列號N+1
- 主題
A-T2
插入D2
- 應用
B
詢問與seq >= N
文件(假設最後處理的文件有seq號N-1
)並且收到D2
(D1
還沒有恩插入尚) - 主題
A-T1
插入D1
- 應用
B
詢問與seq >= N+2
文件(自上次處理的文檔具有序列號N+1
)
在這種情況下,D1
將永遠不會被處理。
如果我正確地理解了你,你需要一種方式來知道文件創建和保存的順序。我建議你自己生成_id。例如,當服務器啓動時,你插入最後一個_id(或最大的一個,就像1505)。然後你只需在每個文件上增加計數器。你很好走。即使某些文檔無法保存,您可以將其保存到某個JSON文件並稍後重新保存。當時會生成_id,您將擁有訂單系統。希望這可以幫助。 –
我不明白你的方法與問題中的第三種方法不同。 –
是的,這裏只有更多的單詞。 –