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