我打算使用Riak作为存储用户会话数据的服务的后端。用于检索数据的主键（二进制blob）名为UUID，实际上是一个uuid，但有时可以使用一个或两个其他键（例如用户的电子邮件）检索数据。
自然选择是选择leveldb后端，有可能在这种情况下使用二级索引，但由于二级索引搜索不常见（大约10％ - 20％的查找），我想知道它是不是最好有一个单独的“索引”桶，这样的映射电子邮件 - ＆gt; uuid将被存储。
在这种情况下，当使用“二级”索引查找时，我首先会在“索引”桶中查找uuid，然后通常使用主键读取数据。
当谈到延迟并且可能更快时，知道bitcask更容易预测，你会推荐这样的设计，还是应该坚持使用leveldb和二级索引？
答案 0 :(得分：1)
我认为这两种情况都有效。选择使用哪种方案的一种方法是您是否需要过期。我想你会希望用户会话到期。如果是这样，那么我会选择第二种情况，因为bitcask提供了一个非常好的过期功能，完全可以自定义。
如果您走这条路，您将不得不清理用于二级索引的元数据存储桶（在eleveldb中）。这可以通过具有元数据键的最后修改的索引来容易地完成。然后运行批处理以执行2i查询以获取旧元数据并删除它们。确保使用最新的Riak，它支持在leveldb中积极删除和回收磁盘空间。
也就是说，也许你可以拥有bitcask中的所有内容，并完全避免使用二级索引。考虑一下这个数据设计：
一个＆＃34;数据＆＃34; bucket：keys是uuid，value是会话 一个＆＃34; mapping_email＆＃34; bucket：密钥是电子邮件，值是uuid 一个＆＃34; mapping_otherstuff＆＃34; bucket：其他属性相同
如果符合以下条件，则可以正常工作：
您可以从这开始，因为它在管理，簿记，批量创建（无）和性能（二级索引查询可能很昂贵）方面更容易。
如果需要，稍后再添加leveldb路由。确保从一开始就使用multi_backend。