2015-09-02 18 views

回答

4

在v1.4.0之前elasticsearch使用基於UUID的ID。這些ID是由RFC4122定義的與版本4.0兼容的UUID的Base64編碼版本。爲了對id進行編碼,使用了URL安全的Base64編碼(參見RFC3548的第4部分),並且刪除了最後兩個「=」符號(因爲16字節的Base64編碼總是會在末尾生成兩個「=」)。

不幸的是,從performance perspective完全隨機ID是不那麼理想。因此,從版本1.4.0開始,elasticsearch切換到基於時間的ID。新的id格式基本上是flake ids的一個版本,除了它使用時間戳的6(不是8)字節和序列號的3(非2)字節。

的問題AU9HiR3lEVul15o3bNYl ID雖然那是在2015年8

1

自動生成的ID是22個字符長,URL安全,Base64編碼的字符串通用唯一標識符或UUID,儘管它看起來像您的ID是20個字符。

更多.NET信息在這裏我認爲,看起來像Guid.NewGuid將工作。 What is the string length of a GUID?

+0

中間我覺得格式很眼熟,但不能把它放在什麼地方產生時基ID。 –

+0

我看到他們砍掉了最後2'=='以節省空間。顯然,當guid變成base64時,它總是在最後加上2'=='。 http://madskristensen.net/post/A-shorter-and-URL-friendly-GUID –

相關問題