在写入Riak的对象中包含二级索引（2i）会对性能产生什么影响？
让我们考虑两个场景，一个桶中有大量对象。每个对象都有一个二级索引，我们称之为example_bin（但它也可以是一个整数索引）：
example_bin的每个值几乎都是不同的值。对索引的一个特定值的查询仅返回一个或几个对象。这样的索引可以是电子邮件地址或注册时间（作为unix时间戳）。example_int索引只有几个可能的值。因此，查询特定索引值会返回大量对象。这样的索引可以代表一类用户，例如“管理员”和“管理员”。或者＆＃39;客户＆＃39;。更新这些对象时会对性能产生什么影响？我知道每次更新对象时都需要检查索引。上述任何一个例子都可以为Riak做一个耗费时间或资源的任务吗？
答案 0 :(得分：5)
使用LevelDB作为后端时更新Riak中对象的性能影响不应受每个索引中有多少条目的影响。但是，它可能会受到每个分区中存储的总数据量的影响，以及自上次更新密钥以来已写入的数据量，以及为该单个对象指定了多少个不同的索引条目。
将值写入LevelDB时，会将其添加到顶级的.log文件中。当.log文件达到一定大小时（我认为1Mb，不记得该大小是否可配置），文件将被切断并开始新文件。这些文件未排序。
当顶层有多个文件（级别0）时，会触发压缩。压缩将组合一个或多个顶级文件，对它们包含的键进行排序，并将这些排序列表与级别1中的相应.sst文件合并。为每个排序级别创建清单文件，指示存储在每个.sst文件中的密钥范围。
对于较低级别，此过程也会根据需要重复进行，每个级别可以存储大约前一级别数据量的10倍。
当为已存在的密钥写入新值时，它只是写入顶层，屏蔽任何先前写入的较低级别的值。之前的值将被替换，因为正常的压缩会将新值降低到较低的水平。
当请求密钥时，LevelDB从0级开始并检查那里的每个文件以查看它是否包含密钥。如果不是，则向下移动到级别1并检查清单指示将包含密钥的文件。对于连续较低的级别重复此操作，直到找到密钥或达到最低级别。因此，返回最近写入的密钥值。 随着每个LevelDB后端中存储的数据总量的增加，使用的级别数，必须搜索的文件数以及读取最旧数据的时间也会增加。
在LevelDB后端存储值时，后端使用的原始密钥是{o,Bucket,Key}的sext编码。
如果在对象中指定了任何索引条目，则对于每个索引，将存储另一个密钥，即{i,Bucket,IndexName,IndexValue,Key}的sext编码。
为了在更新值时删除任何过时的索引条目，必须在每个PUT或DELETE之前执行GET，将前一个对象的索引规范与正在存储的对象的索引规范进行比较，以及任何过时的{已删除{1}}个密钥并添加了新密钥。
由于LevelDB以排序方式存储数据，因此索引查询实现为从密钥{i,...}到{i,Bucket,IndexName,FirstValue,<<>>}开始的折叠（二进制{i,Bucket,IndexName,LastValue,<<255,255,255,255>>}是指示最后一个的理论值排序顺序中的可能键）。
我们会查阅每个排序级别的清单，因此只需要打开包含要折叠的部分范围的数据文件。
example_bin的每个值几乎都是不同的值。对索引的一个特定值的查询仅返回一个或几个对象。这样的索引可以是电子邮件地址或注册时间（作为unix时间戳）。
查询和单个值所需的索引条目可能完全落在每个排序级别的单个文件中，因此该查询将需要打开并搜索级别0中的所有文件，并且每个文件中的1个文件水平。存在的级别数量取决于存储的数据量，将是最大的决定因素。
example_int索引只有几个可能的值。因此，查询特定索引值会返回大量对象。这样的索引可以代表一类用户，例如“管理员”和“管理员”。或者＆＃39;客户＆＃39;。
查询单个值的索引条目范围越大，就越有可能需要为每个排序级别查询多个文件。此查询将比前一个查询花费更长的时间，因为折叠中包含的索引条目数量较多，可能需要打开的文件数量较多。
更新这些对象时会对性能产生什么影响？我知道每次更新对象时都需要检查索引。上述任何一个例子都可以为Riak做一个耗费时间或资源的任务吗？
此处所需的时间取决于检索任何旧对象所需的时间以及索引条目的更改次数。在此过程中，整个索引永远不会被视为一个整体，只有前一个对象上的条目和新对象上的条目。因此，性能不会受到任何索引中条目数的影响，而是受此对象拥有或具有条目的索引数的影响。