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