database - Riak 后端选择 : bitcask vs leveldb

Question

我计划将 Riak 用作存储用户 session 数据的服务的后端。用于检索数据(二进制 blob)的主键名为 UUID，实际上是一个 uuid，但有时可能会使用一个或两个其他键(例如用户的电子邮件)检索数据。

自然的选择是选择 leveldb 后端，有可能在这种情况下使用二级索引，但由于二级索引搜索不是很常见(大约 10% - 20% 的查找)，我想知道它是否不会最好有一个单独的“索引”存储桶，其中将存储此类映射 email->uuid。

在这种情况下，当使用“二级”索引查找时，我会先在“索引”存储桶中查找 uuid，然后通常使用主键读取数据。

知道 bitcask 在延迟方面更可预测并且可能更快，您会推荐这样的设计，还是我应该坚持使用 leveldb 和二级索引？

Answer 1

我认为这两种情况都可行。选择使用哪种方案的一种方法是是否需要过期。我想您会希望用户 session 过期。如果是这样的话，那么我会选择第二种情况，因为 bitcask 提供了一个非常好的到期功能，完全可定制。

如果你走那条路，你将不得不清理你用于二级索引的元数据桶(在 eleveldb 中)。这可以通过还具有元数据键的最后修改的索引来轻松完成。然后你运行一个批处理来做一个 2i 查询来获取旧的元数据并删除它们。确保您使用最新的 Riak，它支持在 leveldb 中主动删除和回收磁盘空间。

也就是说，也许您可​​以将所有内容都放在 bitcask 中，并完全避免二级索引。考虑这种数据设计:

一个“数据”桶:键是uuid，值是 session 一个“mapping_email”桶:键是电子邮件，值是uuid一个“mapping_otherstuff”桶:与其他属性相同

这在以下情况下工作正常:

• 大多数时候您会让数据过期。这意味着您无需记账
• 您没有太多映射，因为添加更多映射很麻烦
• 您已准备好正确实现可管理 3 个存储桶的客户端库，例如在创建/更新/删除新值时

您可以从它开始，因为它在管理、簿记、批量创建(无)和性能(二级索引查询可能很昂贵)方面更容易。

然后如果你需要的话，你可以添加 leveldb 路由。确保从一开始就使用 multi_backend。