Jakarta NoSQL：为何在AI时代仅有JPA不够
呈现这一构想的最佳方式是从架构师面临的挑战入手：AI已经彻底改变了持久化格局。企业应用曾几乎完全基于关系型数据库构建，这使得JPA成为Jakarta EE的基石。如今，现代系统融合了关系型数据库、文档存储、缓存、图引擎，以及日益普及的支撑语义搜索、检索增强生成（RAG）与AI驱动应用的向量数据库。多语言持久化已成为行业标准。尽管Jakarta EE通过JPA实现了关系型持久化的标准化，但它仍缺乏针对非关系型持久化的厂商中立标准。这一空白迫使开发者依赖碎片化的专有解决方案，从而在可移植性、生产力与创新方面制造了障碍。
AI的兴起使得这一空白变得至关重要。向量数据库已成为智能系统的核心，支撑着语义搜索、嵌入与上下文检索。为了让Jakarta EE在AI时代继续保持领先的企业Java平台地位，它必须像对待关系型数据库那样，为NoSQL持久化提供标准化的方法。Jakarta NoSQL并非又一份规范；它是对生态系统未来的战略性投资。通过提供熟悉的编程模型、降低供应商锁定风险，并与AI工作负载集成，Jakarta NoSQL确保了Jakarta EE能够在下一代企业应用中保持相关性与竞争力。
AI时代的NoSQL：理解现代数据格局
多年来，企业数据持久化一直聚焦于关系型数据库。系统依赖表、行、外键与SQL，使关系型技术成为业务应用的标准。尽管关系型数据库依然不可或缺，但现代架构已采用多语言持久化，即多种数据库类型共存，每种类型满足特定需求。如今，NoSQL并非仅指文档数据库，而是指一系列数据库范式，每种范式针对特定工作负载和架构需求而设计。
- 键值数据库：以键值对形式存储数据，支持快速查找与低延迟。典型用途包括缓存、用户会话、功能开关及临时应用状态。
- 文档数据库：将数据存储为结构化文档，如JSON或BSON。适用于具有层次或动态模式的应用，包括Web应用、电商平台及内容管理系统。
- 列族数据库：按列而非行组织数据，支持高写入吞吐量与水平扩展。用于物联网遥测、事件日志、分析以及大规模分布式系统。
- 图数据库：将实体与关系建模为节点和边。该结构非常适合社交网络、欺诈检测、推荐引擎、依赖分析以及关系至关重要的知识图谱。
- 向量数据库：存储来自机器学习模型与大型语言模型（LLM）的高维嵌入。它们通过理解语义而非精确文本匹配，实现语义搜索、相似性匹配、检索增强生成（RAG）、推荐平台及其他AI驱动功能。
- 时间序列数据库：专用于随时间变化的时间戳数据。用于可观测性、监控、金融市场、工业传感器以及需要高性能时序数据存储与分析的操作指标。
[LOADING...]
这些数据库类型通常在同一架构内共存。现代应用可能使用PostgreSQL处理事务、Redis用于缓存、MongoDB处理文档、Neo4j管理关系、InfluxDB收集遥测数据，以及Milvus、Pinecone或Weaviate等向量数据库提供AI驱动的搜索与检索。这种方法被称为多语言持久化，现已成为企业系统的标准。
行业已接受这一转变。Stack Overflow开发者调查显示，尽管关系型数据库仍主导企业工作负载，但NoSQL技术已成为开发者的标准工具。Redis、MongoDB与Elasticsearch等技术正与PostgreSQL和MySQL一起被使用。组织不再需要在SQL与NoSQL之间二选一；它们会组合多种持久化技术以发挥各自优势。多语言持久化已成为现代软件系统的基线。
在NoSQL类别中，向量数据库尤为重要，因为它们是现代人工智能系统的基础。与存储显式业务数据的传统数据库不同，向量数据库存储称为“嵌入”的数值表示。这些嵌入由机器学习模型生成，将单词、文档、图像或其他内容的语义含义编码为数学向量。这使得软件能够基于含义而非精确文本匹配来搜索和检索信息。
词汇搜索与语义搜索的区别凸显了向量数据库的重要性。例如，传统SQL搜索“宠物”会返回包含该精确术语的记录（如“宠物店”），但会忽略“狗”或“小狗”等相关表达。而语义搜索通过比较嵌入，能够检索关于狗、小狗或动物伙伴的文档，因为它识别出了它们之间的语义关系。搜索引擎匹配的是含义，而不仅仅是语法。
[LOADING...]
这一功能对于现代AI架构至关重要。大型语言模型并不直接处理关系型表；它们使用嵌入以及概念之间的上下文连接。诸如检索增强生成（RAG）、企业知识搜索、推荐引擎与智能助手等系统，都依赖于数百万向量之间的相似性搜索。虽然关系型数据库可以通过扩展支持部分向量操作，但向量数据库是为此类工作负载专门构建的，为大规模语义检索提供了优化的索引与相似性算法。随着AI应用的普及，向量数据库正成为企业架构的战略性组件。
认识到NoSQL的重要性，多个Java生态系统已开发出自己的解决方案。Spring提供了Spring Data MongoDB、Spring Data Redis和Spring Data Cassandra等独立项目。这些集成提供了高效的编程模型，但与Spring生态系统紧密耦合。Quarkus通过Panache和数据库特定集成支持NoSQL持久化，强调开发者生产力与云原生部署。Micronaut Data支持多种NoSQL引擎，利用编译时代码生成与提前处理来提升性能并降低执行开销。
尽管这些解决方案很有效，但它们仍是框架特定的，而非平台标准。开发者在切换框架时会遇到不同的API、抽象、注解与操作模型，即使是在解决相似的持久化挑战时也是如此。Jakarta EE通过Jakarta Persistence（JPA）为关系型持久化提供了标准化的、供应商无关的编程模型。随着NoSQL技术的扩展以及AI工作负载越来越依赖向量数据库，Jakarta生态系统中缺乏供应商中立的NoSQL标准已成为一个显著空白。
Java标准化之路
在Java生态系统中标准化NoSQL解决方案的需求已讨论了多年。在Java EE时代，曾有多个提案试图将非关系型数据库集成到企业平台中。随着NoSQL技术在2010年代日益流行，开发者们在JavaOne大会上期待着一份专用规范，能够伴随传统的企业API出现。尽管需求明确，但Java EE内部并未出现这样的倡议。该平台仍然通过JPA专注于关系型持久化，而NoSQL的采用则依赖于特定供应商的库和框架集成。
Java EE向Eclipse Foundation的过渡为解决这一挑战提供了契机。社区没有等待平台级的解决方案，而是发起了Eclipse JNoSQL项目，这是一个为NoSQL数据库提供统一编程模型的开源项目。借鉴JPA的成功经验，Eclipse JNoSQL引入了映射注解、Repository、模板以及支持文档、键值、列族和图数据库的通信API。该项目证明，在不损害每种数据库模型独特特性的前提下，可以实现一致的开发者体验。
随着Jakarta EE的成熟，Eclipse JNoSQL成为了新标准化工作——Jakarta NoSQL的基础。Jakarta NoSQL是首个完全在Jakarta EE流程内创建的持久化规范。与从Java EE迁移而来的早期规范不同，Jakarta NoSQL是在Eclipse Foundation治理模型下构思、开发并发布的。它是首批从构思到发布完整完成Jakarta规范流程的规范之一。
Jakarta NoSQL的影响超出了其最初的范围。在开发过程中，专家组发现关系型和非关系型数据库都面临一个共同挑战：开发者需要一种独立于底层持久化引擎的一致Repository抽象。这促成了一项独立规范——Jakarta Data的诞生。标准化NoSQL访问模式的需求，直接影响了Jakarta Data以Repository为导向的编程模型的发展，该模型适用于多种持久化技术。
这些规范之间的关系突显了Jakarta NoSQL对Jakarta EE生态系统的更广泛影响。Jakarta NoSQL专注于与非关系型数据库的映射与交互，而Jakarta Data则提供了适用于关系型和NoSQL实现的统一Repository抽象。两者结合，显著减少了企业持久化中的碎片化。这一演变并未止步于Jakarta Data。对现代持久化需求进行标准化的驱动，催生了新的规范，如Jakarta Query，旨在为多种持久化技术提供可移植、类型安全且富有表现力的查询语言。
随着Jakarta生态系统的发展，Jakarta NoSQL成为了一个关键里程碑。它填补了长期存在的NoSQL标准空白，并为Jakarta EE中下一代持久化规范奠定了基础。
Jakarta NoSQL：专为NoSQL构建，而非适配而来
当架构师考虑在Jakarta EE中标准化NoSQL开发时，一个常见问题浮现：为什么不扩展Jakarta Persistence（JPA）以支持NoSQL数据库？长久以来，JPA为Java生态系统中关系型数据库提供了统一的编程模型。答案基于一个核心架构原则：工具应针对其预期用途进行优化。
第一个挑战在于，JPA是专门为关系型数据库设计的，依赖于表、列、连接、外键和事务一致性等概念。这些不仅是实现细节，更是规范的核心元素。强制将文档、图、键值或向量数据库融入此模型会造成摩擦，并限制每种数据库原生特性的发挥。
第二个挑战在于NoSQL系统的行为存在根本性差异。图数据库执行路径遍历，文档数据库存储嵌套结构而不进行规范化，键值数据库专注于快速查找，向量数据库处理相似度计算。这些系统在一致性、事务、查询语言、索引和可扩展性方面也各不相同。通过单一的抽象来表示所有这些范式会导致妥协。
第三个挑战在于专业化的价值。正如亚伯拉罕·马斯洛所言：“如果你唯一的工具是一把锤子，那么你很容易把所有问题都当成钉子。”关系型数据库很有效，但并非适用于所有持久化需求。语义搜索、图遍历、高容量遥测存储都不是关系型问题。对所有数据库类型应用关系型抽象，会面临丢失每种技术所提供的独特优化的风险。
以交通为类比：汽车、船只、潜艇和飞机都解决交通问题，但各自针对不同环境进行了专业化设计。强制它们使用相同的控制方式，会导致所有方面表现平庸。同样，单一的持久化抽象可能会抹去每种数据库的优势特性。
因此，Jakarta NoSQL并未将JPA扩展到其预期范围之外。相反，它为非关系型数据库提供了一种专用的持久化模型，同时保留了JPA成功所依赖的熟悉开发者体验。Jakarta NoSQL的一个关键设计目标是减少企业Java开发者的认知负担。熟悉JPA的团队应该能立即上手该规范，因为Jakarta NoSQL有意使用了Jakarta EE社区中常见的术语和概念。开发者会看到@Entity、@Id和@Column等注解，从而实现从关系型到非关系型持久化的平滑过渡。
乍一看，这个实体与JPA实体十分相似，这正是设计意图。然而，底层的实现却截然不同。Jakarta NoSQL旨在支持模式灵活性、嵌入式结构、嵌套文档以及数据库特定的存储模型。这种思路贯穿于整个API。开发者无需处理底层驱动的细节，而是通过模板API获得高级编程模型。其目标与JPA的最初使命一致：让开发者专注于领域模型和业务逻辑，而非序列化、连接管理或供应商特定的API。
这一基础塑造了Jakarta NoSQL 1.0。首个版本引入了映射层、CDI集成、Repository支持、模板操作，以及针对四大NoSQL类别的标准化端点：
- 文档数据库
- 键值数据库
- 列族数据库
- 图数据库
Jakarta NoSQL 1.0表明，统一的Java编程模型能够尊重每种数据库家族的独特特性。Jakarta NoSQL 1.1延续了这一演进。1.0版本专注于映射与持久化，而1.1版本通过集成Jakarta Query扩展了查询能力。一个关键新增功能是对参数化查询的支持，允许开发者安全地绑定参数，而无需手动构建查询字符串。1.1版本还引入了投影支持，使应用能够检索轻量级视图而非完整的实体。这些特性提升了性能，减少了数据传输，并与记录等现代Java特性保持一致。
Jakarta NoSQL的一个重要方面是其长期的架构愿景。虽然大多数开发者使用映射层，但该规范也定义了一个用于高级场景的低级通信API。此通信层是可选的。应用开发者可以在不使用它的情况下构建完整的系统，但对于数据库供应商、框架作者以及需要直接访问数据库功能的高级集成来说，它很有价值。
这种设计与JDBC有本质区别，后者假设通过SQL语句和表格结果集进行通信。该模型之所以有效，是因为关系型数据库共享通用的语言和交互模式。非关系型数据库则不然。文档数据库可能使用BSON，图数据库可能提供遍历语言，向量数据库可能提供相似性搜索API。其他数据库可能使用REST端点、二进制协议、gRPC流或供应商特定的机制。将这些模型强制纳入JDBC风格的抽象会限制其能力，或者需要持续添加供应商特定的扩展。
出于这一原因，Jakarta NoSQL采用了分层架构。映射层为开发者提供了可移植、高效的编程模型，而通信层则保持灵活以支持多样化的NoSQL系统。这种架构为规范的未来发展做好了准备。随着向量数据库、时间序列引擎和AI原生存储等新技术的出现，Jakarta NoSQL可以在不施加关系型思维的前提下演进。它不会将每种数据库都视为JPA锤子下的钉子，而是认识到不同问题需要不同工具，同时为企业Java开发者提供一致且熟悉的体验。
（本文所表达的观点仅代表DZone贡献者个人立场。）