Marklogic：攝取數據時的Genarate主鍵

我使用java-api從CSV攝取數據。我必須維護每個文檔的主鍵。Marklogic：攝取數據時的Genarate主鍵

marklogic是否在插入過程中提供任何唯一的自動生成的ID？

如果marklogic不提供，那麼我可以想到一件事是隨機生成的hexString數字，但問題是如果我有大量的CSV記錄要攝取，有時這個隨機數可能會重複。

請教我如何繼續使用這個用例。

感謝您的閱讀。

2016-06-20 RCS

建議的方法是使用隨機生成的ID值，其長度足以確定碰撞的機會對於您的數據集大小不切實際。因爲你是人類，你仍然很想去檢查碰撞，但是數學說這簡直是浪費。如果你使用的是64位隨機值，那麼你在40億之後有50/50的衝突機率。風險太大？如果這是令人擔憂的，那麼使用128位的隨機值，因爲在18千萬億之後它的賠率是50/50。請參閱「Probability of 64-bit hash code collisions」

來源

2016-06-20 15:01:43 hunterhacker

感謝hunterhacker的回覆。 – RCS

@hunterhacker這在所有情況下都是不正確的。作爲一個數據庫，它應該能夠提供一種生成序列/隨機數的方法。就像在Mongo DB中一樣，它爲每個唯一的插入生成_id對象。 MarkLogic中沒有類似的東西嗎？ – DMA

有沒有辦法可靠地產生一個序列？絕對！你想爲唯一的ID做它嗎？沒有。因爲它增加了沒有好處的開銷，並且有更好的可能性，你的智能代碼有一個錯誤，而不是一個大的隨機值與另一個產生衝突。 MongoDB不會在數據庫檢查，順便說一句。 Mongo _id是*客戶端*和*是一個12字節的值，包含一個4字節的時間戳（自紀元以來的秒數），一個3字節的機器ID，一個2字節的進程ID和一個3字節計數器「每個http://stackoverflow.com/questions/5817795/how-are-mongodbs-objectids-generated。重置你的時鐘，祝你好運... – hunterhacker

xdmp：random（）是具有此類屬性的64位僞隨機生成器（PRNG），使用FIPS兼容實現（如果可用）。它與內部用於生成文檔和片段IDS的內容相同。因此，在實踐中，您無法更好地進行高效的獨特ID生成。是的，這是大多數人起初難以接受的東西（包括我自己）。
現在這不一定與在某些特定上下文中保證相同，並且您使用此方法會生成唯一的URI（這是ML的GUID版本或數據庫範圍的'主鍵'）。要做到這一點，您必須保證唯一的URI來源是您生成的那些URI，並且您可以充分利用所有64位。如果你想向自己證明它的絕對唯一性，不管發生了什麼，那麼你需要一個事務性的原子計數器。這些很容易製作（單個共享文檔的文檔讀取 - 更新 - 寫入 - 提交），但規模可怕極其緩慢。

如果從CSV批量上傳數據，另一種方法是使用記錄的偏移量（行或行號）作爲URL的一部分，以及每個文件的唯一字符，如文件名。
通常CSV數據本身具有一列或多列組合，表示該數據集的主鍵。這也可以使用。

來源

2016-06-20 20:57:43 DALDEI

Marklogic：攝取數據時的Genarate主鍵

回答

相關問題