关系型数据表和向量数据表联合查询问题

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
关系型数据表和向量数据表通过条件过滤再按照向量cosine距离排序取topk为什么检索结果经常少于要取的值，很多结果检索不出来，还会退化成全表扫描，查询速度很慢。有什么解决方案
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

3 个赞
#3

针对您描述的情况，这可能是由于查询优化器选择了非最优的查询计划，或者是因为索引使用不当导致了性能下降。为了解决这个问题，建议先使用 obdiag 工具来收集 SQL 性能相关信息，并根据收集到的数据进行进一步的分析。

推荐使用 obdiag 工具进行日志采集，以获取有关 SQL 性能的问题详细信息，并将采集到的日志提供给我们以便确认问题所在。
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

在此过程中，请确保将实际的数据库连接信息（包括主机地址、端口、用户名、密码及数据库名）替换上述命令中的占位符（-h127.0.0.1 -P2881 -utest@test -p****** -Dtest）。同时，trace_id 参数用于指定追踪ID，您可以将其替换为实际查询过程中生成的trace_id值，以便更精确地定位问题。

另外，为了确定具体的问题，在此需要您提供一些额外的信息：（下面提出几个问题）

  1. 您当前的 OceanBase 版本是什么？
  2. 在您的查询中，是否对关系型数据表和向量数据表都建立了适当的索引？
  3. 查询语句的具体内容是什么？特别是关于条件过滤和排序部分。
  4. 是否启用了任何特定的优化设置或参数调整？
  5. 能否提供一个具体的查询示例及其执行计划（EXPLAIN 输出）？
  6. 您是否有监控系统记录了查询执行时间和资源消耗情况的变化趋势？

通过上述信息，我们可以更好地理解问题的本质，并为您提供更有效的解决方案。

附上敏捷诊断工具 obdiag 使用帮助链接

1 个赞
#4

麻烦能详细给一下场景么 包括查询sql文本，执行计划，结果比对

1 个赞
#5

1. 条件过滤和向量排序的性能瓶颈

  • 条件过滤：如果条件过滤涉及多个字段的复杂逻辑，尤其是过滤条件不适合索引（比如文本字段或范围查询），可能会导致数据库无法有效地利用索引，从而进行全表扫描。
  • 向量排序：对大规模数据进行cosine距离计算和排序是计算量非常大的操作，尤其是在没有适当索引的情况下。对于向量数据，传统的关系型数据库往往不具备优化这类计算的能力，因此会退化为全表扫描。

2. Cosine距离计算效率

  • Cosine距离计算通常是基于向量的内积来进行的，尤其是在高维度的情况下，直接进行这种计算是非常慢的。向量数据通常会存储在高维空间中，在没有专门的索引机制时，计算和排序这些向量的相似度会非常耗时。
  • 如果你的向量表非常大，查询时需要对每个候选向量与查询向量计算cosine距离，这会导致非常低效的查询。

3. 全表扫描

  • 如果你查询的条件不适合索引（例如，过滤条件过于宽泛或复杂），数据库就可能无法利用索引优化查询，导致必须进行全表扫描。
  • 对于高维向量数据，许多关系型数据库可能无法高效地支持这种类型的查询，因此如果向量表非常大，就容易退化成全表扫描，影响查询性能。
1 个赞
#6

专业

#7

优秀