在分布式事务中，全局二级索引（GSI）的维护代价如何评估与优化？

OceanBase 技术问题
#1

大家好，在OceanBase这类分布式数据库中，为了加速查询，我们常会使用全局二级索引。但它也带来了额外的代价：写入数据时，需要同步维护索引表，这可能引入跨机分布式事务。

根据官方资料理解，这个过程可能增加延迟。但在实际应用中，这个代价具体有多大？如何量化评估？

想请教的具体场景和问题：
假设我们有一张按user_id 哈希分区的主表，并为其order_time 字段创建了全局二级索引。

  1. 性能影响量化 ：一次在主表上的INSERT ，相比于无GSI的情况，理论上会增加多少网络往返和事务开销？是否有相关的性能视图（如GV$SQL_AUDIT 中的特定等待事件）可以观测到这个维护过程的耗时？
  2. 设计取舍 ：在什么业务场景下（例如，读远多于写、或对查询延迟要求极高），值得承担GSI的写入代价？反之，何时应该考虑使用局部索引或调整主表分区键来替代？
  3. 优化实践 ：是否有降低GSI维护成本的实践？例如，将索引表与主表放在相同的Locality中，或者使用特定的优化器提示？

期待各位分享在真实业务中设计和使用GSI的经验、教训以及性能测试数据，帮助我们更好地做出架构决策。

【标签】 #分布式索引 #GSI #数据库设计 #性能优化

1 个赞
#4

@论坛小助手

#5

全局二级索引（GSI）确实会引入额外的写入代价，特别是在分布式数据库环境中。以下是针对您的具体问题的回答：

性能影响量化

  1. 网络往返次数：每次插入主表时，除了主表本身的写入外，还需要向索引表中插入一条记录。如果索引表与主表不在同一物理节点上，这将涉及跨机通信，增加网络往返次数。通常情况下，一次插入操作至少会增加一次网络往返。
  2. 事务开销：由于 GSI 的维护涉及跨机分布式事务，因此会增加事务的复杂性和开销。具体开销可以通过观察 GV$SQL_AUDIT 视图中的特定等待事件来评估，例如 gcs_wait_for_log 或 gcs_wait_for_prepare。

设计取舍

  1. 读多于写：如果业务场景中读操作远多于写操作，使用 GSI 是值得的，因为查询性能的提升可以显著优于写入代价。
  2. 查询延迟要求高：如果对查询延迟要求极高，且查询条件主要依赖于 GSI 字段，使用 GSI 也是合理的。
  3. 局部索引或调整主表分区键：如果写入频率较高，可以考虑使用局部索引或调整主表分区键，以减少跨机分布式事务的开销。

优化实践

  1. 索引表与主表同一 Locality：将索引表与主表放在相同的 Locality 中，可以减少跨机通信的次数，降低网络延迟。
  2. 优化器提示：使用特定的优化器提示（如 /*+ INDEX */）来控制查询计划，确保查询利用 GSI。
  3. 批处理写入：如果业务允许，可以考虑批处理写入操作，减少分布式事务的频率。
  4. 预写日志（WAL）：确保预写日志（WAL）的高效性，减少日志同步的延迟。

示例 SQL 查询

-- 查看 GV$SQL_AUDIT 中的等待事件
SELECT sql_id, wait_event, wait_time, total_waits
FROM oceanbase.GV$SQL_AUDIT
WHERE wait_event IN ('gcs_wait_for_log', 'gcs_wait_for_prepare')
ORDER BY total_waits DESC
LIMIT 10;

希望以上信息能帮助您更好地理解和优化 GSI 的使用。

更多信息请查看:

  1. 集群管理 FAQ
  2. 索引概述
  3. OceanBase 数据库性能的影响因素
  4. 索引设计
  5. SQL 性能问题的典型场景和排查思路