核心特性—全局二级索引

简介: 全局二级索引(Global Secondary Index,GSI)是PolarDB-X中的一项重要特性,相比于本地二级索引,全局二级索引中的数据按照指定的拆分方式分布在各个存储节点上。通过全局二级索引,用户能够按需增加拆分维度、提供全局唯一约束等。

每个GSI对应一张分布式索引表,和其他分布式表一样,按照指定的分区规则水平拆分为多张物理表。PolarDB-X使用分布式事务维护主表和索引表之间数据强一致。p325029.png

全局二级索引还支持以下特性:

  • 支持选择覆盖列,减少回表操作开销。
  • 在线表结构变更,添加GSI不锁主表。
  • 支持通过HINT指定索引,自动判断是否需要回表。

示例1:增加拆分维度。例如,对于在线商城的订单表,假设按照买家用户维度拆分,那么对于卖家查询(例如,查询某个卖家的本月所有订单)就需要扫描所有分区。但是借助全局二级索引,可以仅仅扫描相应卖家所在的索引表分区,快速找到所需的订单信息。

示例2:全局唯一约束。例如,假设用户表是一张分布式表,按照用户ID分区。若要求用户手机号需要全局唯一,那么本地索引无法满足,必须构建一个以手机号作为索引键(同时也是分区键)的唯一索引。

相关文章
|
2月前
|
存储 canal
分库分表优化:引入中间表
【7月更文挑战第12天】
43 10
|
10月前
|
SQL 存储 分布式数据库
分库分表索引设计:二级索引、全局索引的最佳设计实践
对主键来说,要保证在所有分片中都唯一,它本质上就是一个全局唯一的索引。如果用大部分同学喜欢的自增作为主键,就会发现存在很大的问题。
|
11月前
|
SQL 存储 分布式数据库
分库分表索引设计:分布式环境下的 主键索引、二级索引、全局索引的最佳设计实践
分库分表索引设计:分布式环境下的 主键索引、二级索引、全局索引的最佳设计实践
107 0
|
存储 缓存 算法
短链系统设计性能优化-分片键选型及全局自增 ID 策略
若一个 long 可对应多个 short 使用 cache 缓存所有 long2short 在为一个 long url 创建 short url 时,若 cache miss,则创建新 short
77 0
|
分布式数据库 数据库 索引
《事务、全局索引、透明分布式》电子版地址
分布式数据库通常按照“分区键” 切分数据,由不同节点处理不同分区的数据,以较低的成本获得良好的性能和可扩展性。但 “如何选择分区键” 会引出一连串疑问,“跨分区事务,多维度查询,哪些表需要分区...”,这些疑问显著增加了用户从单机数据库迁移到分布式数据库的难度。透明分布式允许用户不需要指定分区键,其核心技术是分布式事务与全局索引,能够极大的降低用户使用 PolarDB-X 的成本。
85 0
《事务、全局索引、透明分布式》电子版地址
|
SQL 存储 算法
事务、全局索引、透明分布式,再见,分区健!
在刚刚发布的PolarDB-X 2.1.0版本中,开源了透明分布式能力,能带给用户完全不同的透明分布式数据库使用体验。其中,一个最明显的不同,就是用户不再需要关注分区健这个概念,这也是副标题《再见,分区健》的来由。
1213 0
事务、全局索引、透明分布式,再见,分区健!
|
存储 算法 NoSQL
高并发分布式环境中获取全局唯一ID[分布式数据库全局唯一主键生成]
高并发分布式环境中获取全局唯一ID; 分布式数据库全局唯一主键生成
2985 0
|
消息中间件 容灾 关系型数据库
核心特性—全局日志变更
MySQL binlog是MySQL记录变更数据的“二进制日志”,它可以看做是一个消息队列,队列中按顺序保存了MySQL中详细的增量变更信息,通过消费队列中的变更条目,下游系统或工具实现了与MySQL的实时数据同步,这样的机制也称为CDC(Change Data Capture,增量数据捕捉)。
120 0
核心特性—全局日志变更
|
存储 NoSQL 算法
分布式全局唯一ID方案这么多?
前段时间阿粉想着如何去优化我们公司中已经存在的分布式中的唯一ID,而提起唯一的ID,相信如果不是从事传统行业的人,肯定都有所了解,分布式架构下,唯一ID生成方案,是我们在设计一个系统,尤其是数据库使用分库分表的时候常常会遇见的问题,尤其是当我们进行了分库分表之后,对这个唯一ID的要求也就越来越高。那么唯一ID方案都有哪些呢?
分布式全局唯一ID方案这么多?
|
存储 负载均衡 算法
分库分表后全局ID生成方案(下)
分库分表后全局ID生成方案(下)
132 0
分库分表后全局ID生成方案(下)