2014-01-09 29 views
3

假設我想在RethinkDB中建模一些小部件。建立過程開始,獲得一個唯一的ID,開始工作一段時間,然後當它完成時,將數據寫入數據庫,並在它給出的ID下面。有很多類型的小部件,並且這些ID在所有這些小部件中都應該是唯一的。RethinkDb中的唯一整數計數器

如果我在Postgres的做,我可能有一個主要widget表,每個小部件類型(widget_xwidget_y等)從主表繼承一個表。該ID將是主要widget表中的SERIAL類型。當建設過程開始時,我會插入一些數據,獲取我的唯一ID,開始工作,並在建築物完成時更新表格。我可能不會在整個過程中使用交易,因爲建築物可能需要很長時間。

在RethinkDB中如何做到這一點?我真的需要ID是一個遞增的整數,所以我不能使用默認的UUID鍵。我希望每個控件類型都在它自己的表中。

如果我這樣做,查詢每一個部件的建築開始之前:

r.table("counters") 
    .get("some-uuid-key") 
    .update({ widget_counter: r.row("widget_counter").add(1) }, {return_vals: true}) 

會因爲我希望它會,給我的數據庫範圍內唯一的ID,沒有ID衝突的可能性這項工作?

謝謝...

回答

2

你有什麼就會有工作,因爲我覺得這是是接近一個規範的解決這一問題。在羣集環境中,全球唯一的升序id或多或少是不可能的,這就是爲什麼我們沒有將它們作爲默認選項。你在這裏所做的工作是因爲每一個請求都必須通過一臺機器才能得到它的id("counters"表的主機),這有缺點,如果那臺機器死了,每個需要獲取id的查詢都會失敗。

1

有一個數據庫中的表計數器具有更好的HA(高可用性)的成本序列的保證。

如果你不要求絕對增量的數字,只是更喜歡那些記錄的短整型公開曝光,您還可以設置一組票務服務器......每個數字都會給出每個第N個數字。您將獲得冗餘和較低的數字,但您無法獲得訂單保證,並且可能會隨時間出現明顯的偏差我想到了這樣一個系統,每個系統都在哪裏客戶端也可以通過它得到的最後一個id ...這樣,如果漂移大於X,它可以跳過檢查來保持漂移。

如果您有沒有公開的ID(例如在查詢字符串上,甚至是在這種情況下),我發現UUID是大多數類型數據庫記錄的最佳支持選項。