Question

​ 到目前为止，我们讨论的分区方案依赖于键值数据模型。如果只通过主键访问记录，我们可以从该键确定分区，并使用它来将读写请求路由到负责该键的分区。

​ 如果涉及次级索引，情况会变得更加复杂（参考 其他索引结构 ）。辅助索引通常并不能唯一地标识记录，而是一种搜索记录中出现特定值的方式：查找用户 123 的所有操作，查找包含词语 hogwash 的所有文章，查找所有颜色为红色的车辆等等。

​ 次级索引是关系型数据库的基础，并且在文档数据库中也很普遍。许多键值存储（如 HBase 和 Volde-mort）为了减少实现的复杂度而放弃了次级索引，但是一些（如 Riak）已经开始添加它们，因为它们对于数据模型实在是太有用了。并且次级索引也是 Solr 和 Elasticsearch 等搜索服务器的基石。

​ 次级索引的问题是它们不能整齐地映射到分区。有两种用二级索引对数据库进行分区的方法： 基于文档的分区（document-based） 和 基于关键词（term-based）的分区 。

按文档的二级索引

​ 假设你正在经营一个销售二手车的网站（如 图 6-4 所示）。 每个列表都有一个唯一的 ID——称之为文档 ID——并且用文档 ID 对数据库进行分区（例如，分区 0 中的 ID 0 到 499，分区 1 中的 ID 500 到 999 等）。

​ 你想让用户搜索汽车，允许他们通过颜色和厂商过滤，所以需要一个在颜色和厂商上的次级索引（文档数据库中这些是 字段（field） ，关系数据库中这些是 列（column） ）。 如果您声明了索引，则数据库可以自动执行索引ⁱⁱ 。例如，无论何时将红色汽车添加到数据库，数据库分区都会自动将其添加到索引条目 color：red 的文档 ID 列表中。

ⁱⁱ. 如果数据库仅支持键值模型，则你可能会尝试在应用程序代码中创建从值到文档 ID 的映射来实现辅助索引。 如果沿着这条路线走下去，请万分小心，确保您的索引与底层数据保持一致。 竞争条件和间歇性写入失败（其中一些更改已保存，但其他更改未保存）很容易导致数据不同步 - 参见 多对象事务的需求 。 ↩

图 6-4 按文档分区二级索引

​ 在这种索引方法中，每个分区是完全独立的：每个分区维护自己的二级索引，仅覆盖该分区中的文档。它不关心存储在其他分区的数据。无论何时您需要写入数据库（添加，删除或更新文档），只需处理包含您正在编写的文档 ID 的分区即可。出于这个原因， 文档分区索引 也被称为 本地索引（local index） （而不是将在下一节中描述的 全局索引（global index） ）。

​ 但是，从文档分区索引中读取需要注意：除非您对文档 ID 做了特别的处理，否则没有理由将所有具有特定颜色或特定品牌的汽车放在同一个分区中。在 图 6-4 中，红色汽车出现在分区 0 和分区 1 中。因此，如果要搜索红色汽车，则需要将查询发送到所有分区，并合并所有返回的结果。

​ 这种查询分区数据库的方法有时被称为 分散/聚集（scatter/gather） ，并且可能会使二级索引上的读取查询相当昂贵。即使并行查询分区，分散/聚集也容易导致尾部延迟放大（参阅 实践中的百分位点 ）。然而，它被广泛使用：MonDBDB，Riak 【15】，Cassandra 【16】，Elasticsearch 【17】，SolrCloud 【18】和 VoltDB 【19】都使用文档分区二级索引。大多数数据库供应商建议您构建一个能从单个分区提供二级索引查询的分区方案，但这并不总是可行，尤其是当在单个查询中使用多个二级索引时（例如同时需要按颜色和制造商查询）。

根据关键词(Term) 的二级索引

​ 我们可以构建一个覆盖所有分区数据的 全局索引 ，而不是给每个分区创建自己的次级索引（本地索引）。但是，我们不能只把这个索引存储在一个节点上，因为它可能会成为瓶颈，违背了分区的目的。全局索引也必须进行分区，但可以采用与主键不同的分区方式。

​ 图 6-5 述了这可能是什么样子：来自所有分区的红色汽车在红色索引中，并且索引是分区的，首字母从 a 到 r 的颜色在分区 0 中， s 到 z 的在分区 1。汽车制造商的索引也与之类似（分区边界在 f 和 h 之间）。

图 6-5 按关键词对二级索引进行分区

​ 我们将这种索引称为 关键词分区（term-partitioned） ，因为我们寻找的关键词决定了索引的分区方式。例如，一个关键词可能是： 颜色：红色 。 关键词(Term) 来源于来自全文搜索索引（一种特殊的次级索引），指文档中出现的所有单词。

​ 和之前一样，我们可以通过 关键词 本身或者它的散列进行索引分区。根据它本身分区对于范围扫描非常有用（例如对于数字,像汽车的报价），而对关键词的哈希分区提供了负载均衡的能力。

​ 关键词分区的全局索引优于文档分区索引的地方点是它可以使读取更有效率：不需要 分散/收集 所有分区，客户端只需要向包含关键词的分区发出请求。全局索引的缺点在于写入速度较慢且较为复杂，因为写入单个文档现在可能会影响索引的多个分区（文档中的每个关键词可能位于不同的分区或者不同的节点上） 。

​ 理想情况下，索引总是最新的，写入数据库的每个文档都会立即反映在索引中。但是，在关键词分区索引中，这需要跨分区的分布式事务，并不是所有数据库都支持（请参阅 第 7 章 和 第 9 章 ）。

​ 在实践中，对全局二级索引的更新通常是 异步 的（也就是说，如果在写入之后不久读取索引，刚才所做的更改可能尚未反映在索引中）。例如，Amazon DynamoDB 声称在正常情况下，其全局次级索引会在不到一秒的时间内更新，但在基础架构出现故障的情况下可能会有延迟【20】。

​ 全局关键词分区索引的其他用途包括 Riak 的搜索功能【21】和 Oracle 数据仓库，它允许您在本地和全局索引之间进行选择【22】。我们将在 第 12 章 中涉及实现关键字二级索引的话题。