山东大学软件学院创新实训开发日志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。