gpt4 book ai didi

数据系统分区设计 - 分区与二级索引

转载 作者:知者 更新时间:2024-03-12 19:51:40 28 4
gpt4 key购买 nike

目前的分区方案都依赖KV数据模型。KV模型简单,都是通过K访问记录,自然可根据K确定分区,并将读写请求路由到负责该K的分区。

但若涉及二级索引,就很复杂。二级索引通常并不能唯一标识一条记录,而是一种加速特定值的查询,如查询用户JavaEdge的所有操作,查找包含词语 java 的所有博客等。

许多KV存储(如HBase)为了减少实现复杂度而放弃二级索引,但一些(如 Riak)已开始支持它们,二级索引也是 Solr 和 ES 等搜索服务器的根本。

二级索引的主要挑战是不能整齐地映射到分区。有两种方案支持对二级索引进行分区:

  • 基于文档的分区(document-based)
  • 基于关键词(term-based)的分区

3.1 基于文档的二级索引进行分区

二手车销售网(如图-4)。 每个列表都有个唯一的文档ID,以此对DB进行分区,如分区0 中的ID 0~499,分区1中的 ID 500~999。

用户搜车,可按颜色和厂商过滤,所以需要在颜色和厂商设置二级索引(在文档DB中这些是字段(field),关系DB中这些是列(column))。每当将一辆红色汽车添加到DB,DB分区都会自动将其添加到索引条目 color:red 的文档ID列表。

这种索引方法中,每个分区完全独立,各自维护自己的二级索引,且只负责自己分区内的文档,而不关心其他分区的数据。每当需要写DB(添加,删除或更新文档),只需处理包含你正在编写的目标文档ID的分区。因此,文档分区索引也被称为本地索引,而非全局索引。

但读时注意:除非对文档ID特别处理,否则不太可能将所有特定颜色或品牌的汽车放在同一分区。图-4中,红车出现在分区0、1。因此,若搜索红车,就需将查询发送到所有分区,然后合并所有返回的结果。

这种查询分区DB的方法有时称为分散/聚集(scatter/gather),显然这种二级索引的查询代价高昂。即使并行查询分区,分散/聚集也容易导致尾部读延迟显著放大。但它依旧被广泛使用:MongoDB,Cassandra,ES都直至基于文档分区的二级索引。大多DB供应商建议用户自己构建合适的分区方案,尽量由单个分区满足二级索引查询,但这并不总是可行,尤其是当查询中使用多个二级索引时(例如同时需按颜色、制造商两个条件查询)。

3.2 基于词条(Term)的二级索引分区

可对所有的数据构建全局索引,而非每个分区维护自己的二级索引(本地索引)。为避免成为瓶颈,不能将全局索引存储在一个节点,否则就破坏了设置分区均衡的目的。所以,全局索引也必须分区,但可以采用与K不同的分区策略。

如图-5,所有数据分区的红车收录在索引color:red,而索引本身也是分区的,如从 ar 开始的颜色在分区 0,sz 分区 1。类似的,汽车制造商的索引也被分区(两个分区的边界分别是 fh)。

这种索引称为 词条分区(term-partitioned),以待寻找的关键词本身作为索引。如颜色:color:red。关键词(Term)这个名称源于全文索引(一种特殊的二级索引),term指文档中出现的所有单词集合。

可直接通过 关键词 本身来全局划分索引,或对其hash。根据关键词本身分区对范围扫描很有用(如对数值类的属性,e.g. 车报价),而对关键词hash分区可更均匀划分分区。

全局的词条分区 V.S 文档分区索引
  • 它使读更高效,即无需分散 / 收集对所有分区都执行一遍查询。相反,客户端只需向含词条的分区发出读请求
  • 全局索引的缺点,写速度较慢且复杂,因为单个文档的更新是,可能影响多个二级索引,而二级索引的分区可能位于不同分区或不同节点,

理想情况下,索引应时刻保持最新,即写入的每个数据要立即反映在最新的索引。但对词条分区,这需要跨分区的分布式事务,写入速度将受到极大影响,所以现有 DB 都不支持同步更新二级索引。

实践中,对全局二级索引的更新都是异步(即若在写入后马上读索引,则更新可能尚未反映在索引中)。

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com