山东大学软件学院创新实训开发日志1-数据库选型

本周我主要针对数据库选型做了研究工作。首先看我们的业务需要：不仅包括账密登录、用户信息这些结构化数据，还包括非结构化数据（如：带有 ABCD 选项的单选题、长文本解析、错题本），之后还需要做RAG增强检索、构建知识图谱、接入大模型实现智能答疑等。此前的课程设计经验中比较熟悉的是MySQL，但如果无脑MySQL注定会在后期的 AI 接入和复杂查询中遭遇严重的性能瓶颈和架构重构，众所周知，错误发现的越迟，纠正错误的成本越高，于是我首先谨慎地对数据库选型做了一些研究。

一、关系型数据库选型

为了实现用户信息存储、做题记录等业务逻辑，我们首先需要一个关系型数据库。在参考了一些技术博客和github上的项目之后，准备在PostgreSQL和MySQL中二选一。一开始准备用PostgreSQL，主要是因为之后要做RAG，需要用到向量检索，而Postgre有个扩展插件pgvector可以支持我们对于向量数据库的需求。但之后发现pgvector来单独当作一个向量数据库还是有不妥（详见下文），于是转入单纯比较Postgre和MySQL。

1.首先由于我们要存储408题库，对于选择题的答案存储其实是非结构化的。Postgre和MySQL都能支持json格式，下图是MySQL数据类型选择页面：

json格式极大程度上满足了我们的需求，不同点在于MySQL对于json格式的数据操作功能比较有限，主要是可以提取、更新json数据中的值，例如 JSON_EXTRACT() 函数可以提取json文档中指定路径的值，JSON_SET() 函数可以更新json文档中的值；而Postgre则提供了更强大的处理功能，不过实际业务上MySQL针对json数据的操作已经够用了。

2.其次在使用成本上，MySQL相对Postgre架构更简单，使用起来更容易上手，而且我们团队也比较熟悉；Postgre虽然有众多的特性和功能，但需要具备更高的技术水平和经验，而且配置参数多，对服务器硬件资源（比如内存、CPU）要求可能更高，它的使用场景是地理信息系（GIS）、企业资源规划（ERP）、金融系统等这些对复杂查询、数据一致性有高要求的企业级应用。

3.综合考量之下，最终还是选择了MySQL。

二、向量数据库

主要是pgvector和ChromaDB的二选一。我们使用向量数据库主要是为了实现RAG。

1.pgvector是Postgre的插件，如果使用它的话可以省去维护两个独立数据库可能造成数据不一致风险等麻烦。但仔细阅读技术博客后发现，pgvector其实不能看作一个独立的向量数据库，它只是把向量当作了一种字段类型，让向量检索融入了SQL体系，它更适合做带负责业务条件的语义检索。pgvector做的是内容检索，一个内容检索系统通常至少包含向量、状态过滤、分类、排序、分页等，​​它把搜索逻辑转到了应用层，我们要在应用层写if/for代码，造成代码复杂、难以维护等，根本不适合做纯向量数据库。

2.而Chroma是向量数据库，它是为RAG（检索增强生成）而生的！Chroma更适合RAG/LLM问答、纯语义召回这些场景，而且查询模式非常简单（TopK）。这与我们的任务目标完全匹配。

3.综上所述，我们选择了ChromaDB。说回前面，Postgre显然就失去了当初考虑它的最大优势。

三、缓存

对于408历年经典必考真题，短时间内会有大量重复查询。引入Redis可以将这些高频数据的读取从磁盘 I/O 转移到内存，极大减轻MySQL 的压力。缓存选择了Redis。但过早优化是大忌，所以打算前期先不用Redis，待到项目中后期再引入。

四、图数据库

后续计划构建408知识图谱，需要引入图数据库，将知识点作为节点（Nodes），将依赖关系作为边（Relationships）。这里选择了经典图数据库Neo4j。