這是TokyoCabinet的錯誤嗎？

這基本上是一個二叉樹對哈希首先搜索，以決定它是否是其left或right：這是TokyoCabinet的錯誤嗎？

if(hash > rec.hash){ 
    off = rec.left; 
    entoff = rec.off + (sizeof(uint8_t) + sizeof(uint8_t)); 
} else if(hash < rec.hash){ 
    off = rec.right; 
    entoff = rec.off + (sizeof(uint8_t) + sizeof(uint8_t)) + 
    (hdb->ba64 ? sizeof(uint64_t) : sizeof(uint32_t)); 
} else { 
    if(!rec.kbuf && !tchdbreadrecbody(hdb, &rec)) return false; 
    int kcmp = tcreckeycmp(kbuf, ksiz, rec.kbuf, rec.ksiz); 
    if(kcmp > 0){ 
    off = rec.left; 
    ... 
    } else if(kcmp < 0){ 
    off = rec.right; 
    ...

這裏的哈希如何計算出來的：

static uint64_t tchdbbidx(TCHDB *hdb, const char *kbuf, int ksiz, uint8_t *hp){ 
    ... 
    uint32_t hash = 751; 
    const char *rp = kbuf + ksiz; 
    while(ksiz--){ 
    ... 
    hash = (hash * 31)^*(uint8_t *)--rp; 
    } 
    *hp = hash; 
    ... 
}

但似乎哈希計算不能的方式確保密鑰的有序性，

它是一個錯誤？

來源

2011-10-18 Je Rog

它並不是試圖通過鍵本身的值來排序鍵。它首先通過哈希來排序，然後通過哈希碰撞的關鍵值排序。

所以不，它不是一個錯誤。除非您可以引用文檔說明這種類型的表按關鍵值進行排序。

來源

2011-10-18 11:35:23

這不是一種類型的樹，這只是對按鍵的排序。所以操作的性質將取決於樹的類型。 –

平衡安全嗎？IMO重新平衡後可能找不到一些記錄。 –

那麼平衡是什麼意思呢？通常，平衡一棵樹時，記錄不會丟失，也不會重新排序。平衡一棵樹實際上是透明的。 –

這是TokyoCabinet的錯誤嗎？

回答

相關問題