为什么直接路由不能用于有二级索引的分布式数据？
Why can't direct routing be used for distributed data with a secondary index?
我正在阅读以下文章：Elements of Scale: Composing and Scaling Data platforms
我无法理解以下句子：
A secondary index is an index that isn’t on the primary key. This means the data will not be partitioned by the values in the index. Directed routing via a hash function is no longer an option. We have to broadcast requests to all machines.
谁能解释一下为什么会这样？我是数据平台的初学者，但到目前为止已经理解了这篇文章。
具体来说，为什么我们不能在二级索引中查找主键的值，然后通过主键上的哈希函数查找它们的位置？为什么要向所有机器广播请求？
感谢您的宝贵时间
对于他们提供的示例，数据已分布在 4 个节点上。每个节点都有一个二级索引，但仅针对该节点上的值。二级索引没有所有节点上的所有记录。所以想要搜索的调用者需要发送到所有节点。
例如只有 2 个节点
节点 1 有 (1,a) (2,a) (3,b)
节点 2 有 (100,a) (105,c)
节点 1 的主索引为 1,2,3。和二级索引 a,a,b
节点 2 的主索引为 100,105。和二级索引 a,c
想要搜索 'c' 的调用者需要广播到两个节点以搜索两个二级索引。
但是，如果您在某处维护二级索引 a、a、a、b、c 的完整副本，您可以查询该索引，然后直接转到目标节点。但这在实践中比你想象的要复杂得多。
编辑 6 月 22 日。当您尝试在第三个节点上维护二级索引时，您需要考虑以下复杂情况。
Insert/edit 操作现在涉及 2 个甚至 3 个节点，因此您需要实施某种两阶段提交协议或替代方案。
随着涉及的节点越来越多，您可能会发现总体可靠性随着 MTBF 的降低而降低。
您需要考虑网络分区会发生什么。
维护操作可能会更难。例如，如何在不产生过多网络流量的情况下有效地验证索引是否正确。
更新将如何编辑索引节点？是客户端负责，还是主存储节点更新索引节点？
复习 CAP 定理，研究 2 阶段提交方案，并可能查看发表在分布式系统期刊上的一些 IEEE 论文是了解更多信息的好地方。
以Cassandra为例，数据写入由分区键的哈希值确定的节点副本（在table模式中定义，它通常是主键的第一部分）。
二级索引是不在该分区键中的数据，假设索引写入保存原始数据的同一节点，在查询二级索引时您无法确定包含特定数据的节点通过对新的 'key' 的值进行散列来计算该索引中的值，因为它位于原始分区键（主数据）的节点上。
我正在阅读以下文章：Elements of Scale: Composing and Scaling Data platforms
我无法理解以下句子：
A secondary index is an index that isn’t on the primary key. This means the data will not be partitioned by the values in the index. Directed routing via a hash function is no longer an option. We have to broadcast requests to all machines.
谁能解释一下为什么会这样？我是数据平台的初学者，但到目前为止已经理解了这篇文章。
具体来说，为什么我们不能在二级索引中查找主键的值，然后通过主键上的哈希函数查找它们的位置？为什么要向所有机器广播请求？
感谢您的宝贵时间
对于他们提供的示例，数据已分布在 4 个节点上。每个节点都有一个二级索引，但仅针对该节点上的值。二级索引没有所有节点上的所有记录。所以想要搜索的调用者需要发送到所有节点。
例如只有 2 个节点
节点 1 有 (1,a) (2,a) (3,b)
节点 2 有 (100,a) (105,c)
节点 1 的主索引为 1,2,3。和二级索引 a,a,b
节点 2 的主索引为 100,105。和二级索引 a,c
想要搜索 'c' 的调用者需要广播到两个节点以搜索两个二级索引。
但是，如果您在某处维护二级索引 a、a、a、b、c 的完整副本，您可以查询该索引，然后直接转到目标节点。但这在实践中比你想象的要复杂得多。
编辑 6 月 22 日。当您尝试在第三个节点上维护二级索引时，您需要考虑以下复杂情况。
Insert/edit 操作现在涉及 2 个甚至 3 个节点，因此您需要实施某种两阶段提交协议或替代方案。
随着涉及的节点越来越多，您可能会发现总体可靠性随着 MTBF 的降低而降低。
您需要考虑网络分区会发生什么。
维护操作可能会更难。例如，如何在不产生过多网络流量的情况下有效地验证索引是否正确。
更新将如何编辑索引节点？是客户端负责，还是主存储节点更新索引节点？
复习 CAP 定理，研究 2 阶段提交方案，并可能查看发表在分布式系统期刊上的一些 IEEE 论文是了解更多信息的好地方。
以Cassandra为例，数据写入由分区键的哈希值确定的节点副本（在table模式中定义，它通常是主键的第一部分）。
二级索引是不在该分区键中的数据，假设索引写入保存原始数据的同一节点，在查询二级索引时您无法确定包含特定数据的节点通过对新的 'key' 的值进行散列来计算该索引中的值，因为它位于原始分区键（主数据）的节点上。