在本文中，我们继续探索有效的数据库索引策略，我们在 7 月 6 日那一期开始了这个讨论。我们将讨论索引如何在非关系型
数据库中使用，并通过实际用例和最佳实践来完成我们对通用数据库索引策略的讨论。
在 7 月 6 日那一期，我们专注于关系数据库的索引用例，其中记录存储为单独的行。还有其他流行的数据库类型，其中也
使用某些形式的索引。我们将简要讨论索引如何在其他常见形式的数据库中使用——NoSQL。
NoSQL 数据库是一类广泛的数据库系统，设计用于灵活性、可扩展性和处理大量结构化和非结构化数据的能力。某些类型的
NoSQL 数据库（特别是键值存储和宽列存储）中使用的一种流行数据结构是日志结构合并树（LSM 树）。与传统的基于 B 树
的索引结构不同，LSM 树针对写密集型工作负载进行了优化，使它们成为数据摄入率高的应用的理想选择。
LSM 树本身就是一种索引。它在单独的结构中维护数据，每个结构都是基于树的排序索引。较小的结构驻留在内存中（称为
MemTable），而较大的结构存储在磁盘上（称为 SSTables）。写操作首先在 MemTable 中进行。当 MemTable 达到一定大小时
，其内容被刷新到磁盘作为 SSTable。LSM 树的真正魔力在读操作期间发挥作用。虽然读路径更复杂，因为数据分布在不同的
结构中，但 LSM 树采用布隆过滤器和分区索引等技术来快速定位所需数据。
LSM 树是在主键上执行点查找和范围查询的有效方式。然而，对非主键进行查询需要全表扫描，这是低效的。
这就是二级索引有用的地方。二级索引，顾名思义，是在主键字段以外的字段上创建的索引。与基于键索引数据的主索引不
同，在二级索引中，数据基于非键属性进行索引。它为数据库系统提供了访问数据的替代路径，允许更高效地处理不涉及键
的查询。
在基于 LSM 树的数据库中创建二级索引涉及创建一个新的 LSM 树，其中键是创建索引的字段的值，值是相应记录的主键。当
执行涉及索引字段的查询时，数据库使用二级索引快速定位相关记录的主键，然后从主索引检索完整记录。
然而，LSM 树数据库中二级索引的复杂性之一是处理更新。由于 LSM 树的写优化特性，这些数据库中的数据通常是不变的，
这意味着更新作为写（用于记录的新版本）和删除（用于旧版本）的组合来处理。为了保持一致性，主数据存储和二级索引
需要同时更新。这可能导致性能权衡并增加维护索引一致性的复杂性。
现在我们讨论了索引如何在不同类型的数据库系统中使用，让我们转向一些常见的索引用例。
索引最简单的用例是加速对特定属性或键的搜索。让我们考虑一个例子：一家汽车经销商有一个包含列”car_id”和”color”的
表。“Car_id”是主键，因此具有固有的聚簇索引。如果我们需要通过”car_id”查找汽车，数据库可以快速定位信息。
然而，如果我们需要查找特定颜色的所有汽车怎么办？如果没有”color”列上的索引，数据库将不得不扫描表中的每一行。
这对于大表来说是一个耗时的过程。在”color”列上创建非聚簇索引允许数据库高效地检索特定颜色的所有汽车，将原来的
全表扫描转变为更快的索引扫描。
索引还可用于高效检索值范围。考虑一个博客平台，其中”post_id”是主键，“created_time”是另一个属性。如果没有索引，
要找到 20 篇最新的帖子，数据库需要扫描所有记录并按”created_time”排序。
然而，如果”created_time”被索引，数据库可以使用这个索引快速识别最新的帖子。这是因为”created_time”上的索引按照
它们创建的顺序存储 post_id 值，允许数据库高效地找到最新的条目，而无需扫描整个表。
由于其排序特性，索引对前缀搜索也很有用。想象一个场景，搜索引擎保留一个之前搜索的术语及其相应流行度分数的表。
当用户开始输入搜索词时，引擎希望建议以给定前缀开头的最流行术语。搜索词上的 B 树索引允许引擎高效地找到具有给定
前缀的所有术语。找到这些术语后，它们可以按流行度分数排序以提供最相关的建议。
在这种情况下，前缀搜索可以通过使用 trie 或前缀树（一种特殊类型的树，其中每个节点代表某个字符串的前缀）进一步
优化。
Geohashes 是一种空间索引形式，将地球划分为网格。网格中的每个单元格都被分配一个唯一的哈希，同一单元格内的点共
享相同的哈希前缀。这使得 geohashes 非常适合查询一定邻近范围内的位置。
要找到某个位置一定半径内的所有点，我们只需要搜索与目标位置共享 geohash 前缀的点。这比计算到数据库中每个点的距
度要快得多。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：Database Indexing Strategies - Part 2。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。