如何把数据库的数据同步到向量数据库

Question

老师，

关于向量数据库，我有以下几个问题：

1. 您介绍的几种向量数据库，您推荐哪几种呢？视频中您提到了您比较喜欢chroma，它能存储大约多少数据呢？如果我用的是google cloud platform，是需要自己安装吗？

2. 向量数据库的数据是长时间保存的吗？还是只是当前运行有效（课程中，我看您都是用 from_document 临时加载数据进到chroma）

3. 如果我想导入现在sql 数据库里的部分 table 数据到向量数据库里，一般应该怎么做呢？
   我个人的想法：

• 最开始执行一次性的数据搬运
• 每次sql 数据库数据发生变化，更新向量数据库 （例如，每次api的crud，都处罚向量数据库的相应操作）。

这个想法正确吗？如果正确，应该怎么实现呢？

• 对于开始的一次性搬运，一般来说要写一个单独程序来实现吗？
• 对于以后的数据同步，是实时方式实现（每次数据变化，都更新向量数据库）？还是阶段性的更新（schedule一个任务，每过一段时间更新最近的变化数据）？
• 一个更宽泛的问题是，生产环境中，我们一般怎么向向量数据库里更新数据呢？是定时更新的？还是实时处理的？
  如果不正确，应该怎么做呢？

4. 比如说，我现在有api 可以进行keyword 搜索然后返回部分包含搜索相关词的json数据，我是“现”加载到向量数据库中，然后进行similarity_search 呢？还是按我上面说的，平时就实现向量数据库与sql 数据库的同步，这个样的话，就直接进行similarity_search？如果您是我，您会怎么选择呢？

Answer 1

tomiezhang 2024-09-29 17:33:27

1. 看数据量看部署方式，chroma适合中小型在本地部署向量数据库的项目，本地安装的话理论上存储空间是无限的，但是可能数据量非常大的话，搜索精度会有问题，而如果你的项目数据量很大，建议使用类似Pinecone这样的商业产品，如果像你说的你经常使用google系产品，那么如果你不想本地部署的话，其实他们家也有向量数据库Google Cloud SQL for MySQL，也支持向量搜索。事实上向量数据库发展很快，如果生产环境建议用商业的，毕竟有保障，各家的差距主要在内置的索引方法和支持的查询方式。

2. 长期保存，课程里为了方便很多时候演示的是写内存的，事实上向量数据库之所以这一次突然崛起，就是因为它的持久化能力和LLM可以很好的配合。

3. 一部分数据迁移，建议写一个脚本跑就好了；以后的数据同步，其实跟过去做数据库同步没什么区别，用脚本同步写就好，在生产环境里的更新策略看你的应用设计，如果你的场景是类似存储用户个人的聊天记录，那肯定要实时进向量库，如果不是这种场景，而是类似文档查询之类，那可以可以定时同步。

4. 这个其实要看你的业务场景，如果你的业务对于数据筛选的精准度要求很高，那么我建议你先用SQL搜索出来，再放进向量库进行查询，按照之前做过的实验，“大海捞针”这一类的搜索测试，向量库+LLM还是会有遗漏、多选的概率，所以一般而言在向量搜索之前有一个已经预处理过的数据(范围越小越好)是最好的。当然，如果你的业务对精度不那么敏感，更加看中的是模糊匹配的能力，那么直接数据库同步，仅使用向量搜索就好。事实上，在实际开发中RAG这块的核心，就是不断的优化检索策略，提升检索的效果，包括现在最前沿的已经使用类似知识图谱来增强向量检索能力了。

谷歌云向量库使用方式：https://python.langchain.com/docs/integrations/vectorstores/google_cloud_sql_mysql/

• 提问者 zhazi #1

  谢谢老师的回复！！对于您的回复，我还有如下问题： 
  
  1. 针对于第4点，我如果每次用filter 过滤再放到向量数据库里，那岂不是每一次程序运行，都在向量数据库里存储一次数据？例如，我这次搜索“Tom“，api 返回四条数据，存到向量数据库里进行similarity search。下次再搜索”Tom“，还会再向向量数据库存储一遍，然后进行近似搜索？或者我搜索”John“，向量数据库存储含有John 的数据。也就是说这种情况下，向量数据库的存储岂不成了针对每次特定操作的了吗？我的理解对吗？
  还是说您是指，仍然用script 把sql 的数据copy 到向量数据库（不是每次程序运行都存），先对向量数据库进行一次搜索，把其中含有关键词的数据取出，再进行similarity search？但simiarity_search不都是作用在vector_store上的吗？怎么作用在filtered data上呢？
  
  2. 对于第1点，如果我选用google cloud sql for postgres，因为我的sql 数据库已经在google cloud 上了，那么google cloud sql 是直接作用于我现有的sql 数据库的table上呢？还是说它把sql 数据库变成可存储vector embedding data 的存储空间， 从而进行存储 / 检索 - 也就是说，不是直接检索现有的sql db table，而还是操作另外的vector 空间，只不过这个另外的空间是基于现有的sql 数据库的。 如果是前者，那我就无法进行您第四步中提到的 api search的数据筛选了吧？

• tomiezhang 回复 提问者 zhazi #2

  你好，你的问题其实是一个架构设计问题，这么说吧，你可以有两种设计：
  1. 【将SQL库全部同步到向量数据库】这样的优点在于：a)搜索速度快，所有数据都在向量数据库，可以直接进行语义相似性搜索，不需要额外的SQL查询步骤 b) 实时性好，只要保持两个库的同步，向量数据库中的数据总是最新的 c) 灵活，可以进行全库范围的语义搜索，不受SQL查询的限制。 缺点也很明显：a) 全量存储成本高，尤其你使用商业托管的向量库 b) 同步问题，需要实现和维护完整的数据同步机制，脚本或者类似kafka之类 c)冗余，并不是所有数据都需要语义搜索，所以全量的话可能会导致浪费。
  2. 【先SQL搜索相关内容，再将这些内容放进向量库】优点：a) 存储效率比较高，只需要存储部分数据的向量表示 b)灵活性好，可以根据具体需求动态选择需要进行语义搜索的数据 c) 减少复杂度,只需要同步部分数据。缺点：a) 搜索过程可能会比较慢，需要经历SQL查询->向量化->向量搜索的过程. b) 可能错过潜在内容，第一步的SQL查询可能无法捕捉到所有语义相关内容 c) 实时性差，见a点，需要再查询的时候动态生成向量。
  你第一个问题里所谓的向量数据库的存储针对每次特定操作的理解，其实就是方案二的缺点，需要实时生成向量。至于说google cloud的问题，官方的文档明确说了你的数据库version 必须 >= 8.0.36 以及 cloudsql_vector 这个配置项必须设置为 "On"。
  如果我来做的话，我更倾向于一种【混合策略】：
  1. 核心数据全量同步：将经常要进行语义搜索的核心数据全量同步到向量数据库。这部分数据通畅是你业务中最重要、最常用的内容。
  2. 动态索引非核心内容：对不太常用或不太重要的数据，采用动态索引的方式。即在需要的时候，通过SQL查询筛出潜在的相关数据，然后动态生成向量并进行语义搜索。
  3. 设置缓存： 实现一个缓存层，用来存储最近生成的向量。这样可以减少重复的向量生成操作，提高效率。
  4. 定期更新：定期分析搜索模式和频率，根据情况动态调整上面2个策略。
  核心在于，你将向量数据库视为什么，不要被数据库三个字给迷惑了，它的确可以持久化，但是不代表它非要像SQL那样，我认为它最大的作用还是做语音搜索，而且大部分主流向量库其实都不会做类似去重的动作，所以你存两个“Tom”相关的数据进去，它们都会以唯一ID被管理起来，用户可以在入库的时候(比如前面提到的缓存层)去手动管理这种情况(类似先查ID再存)