Riak后端選擇：bitcask與leveldb

Question

我打算將Riak用作存儲用戶會話數據的服務的后端。 用於檢索數據的主鍵（二進制Blob）名為UUID，實際上是一個uuid，但有時可能會使用一個或兩個其他鍵（例如，用戶的電子郵件）來檢索數據。

自然的選擇是選擇leveldb后端，並且可以在這種情況下使用二級索引，但是由於二級索引搜索不是很常見（大約占查詢的10％-20％），我想知道是否會有更好的選擇一個單獨的“索引”存儲桶，將在其中存儲此類映射email-> uuid。

在這種情況下，當使用“二級”索引查找時，我將首先在“索引”存儲區中查找uuid，然后通常使用主鍵讀取數據。

知道比特桶在延遲方面可能更具可預測性，並且可能更快。您會推薦這種設計嗎？還是我應該堅持使用leveldb和二級索引？

Answer 1

我認為這兩種情況都行得通。 選擇要使用哪種方案的一種方法是是否需要到期。 我想您會希望用戶會話過期。 如果真是這樣，那么我會考慮第二種情況，因為比特桶提供了一個非常好的到期功能，可以完全自定義。

如果走那條路，就必須清理用於二級索引的元數據存儲區（在eleveldb中）。 通過還具有元數據密鑰的最后修改的索引，可以輕松完成此操作。 然后運行批處理進行2i查詢，以獲取舊的元數據並將其刪除。 確保使用最新的Riak，它支持在leveldb中主動刪除和回收磁盤空間。

就是說，也許您可​​以將所有內容都存儲在桶中，並且完全避免使用二級索引。 考慮以下數據設計：

一個“數據”存儲桶：鍵是uuid，值是會話一個“ mapping_email”存儲桶：鍵是電子郵件，值是uuid一個“ mapping_otherstuff”存儲桶：其他屬性相同

如果：

• 大多數情況下，您讓數據過期。 這意味着您無需簿記
• 您沒有太多的映射，因為添加更多的圖很麻煩
• 您已准備好正確實現可管理3個存儲桶的客戶端庫，例如在創建/更新/刪除新值時

您可以從此開始，因為在管理，簿記，批量創建（無）和性能（二級索引查詢可能會很昂貴）上更容易。

然后，如果需要，可以稍后添加leveldb路由。 確保從一開始就使用multi_backend。