數(shù)據(jù)訪問(wèn)層（DAL）技術(shù)已經(jīng)非常成熟，從最早的 JDBC 到 Hibernate、MyBatis，再到 Spring Data JPA。我們習(xí)慣了用這些框架處理數(shù)據(jù)。然而，當(dāng)我們把目光投向“數(shù)據(jù)”本身的變化時(shí)，會(huì)發(fā)現(xiàn)這些經(jīng)典的框架似乎正逐漸變?yōu)椤袄弦淮薄?/p>

新一代的挑戰(zhàn)不再僅僅是如何優(yōu)雅地寫(xiě) SQL，而是如何用統(tǒng)一的方式訪問(wèn)那些不再僅僅存儲(chǔ)在關(guān)系型數(shù)據(jù)庫(kù)中的數(shù)據(jù)。

老舊的一代

談?wù)摗袄弦淮睌?shù)據(jù)訪問(wèn)庫(kù)，并非貶義，而是指它們誕生的時(shí)代背景和核心使命。

在過(guò)去以及現(xiàn)在，MyBatis、Hibernate、JPA (Hibernate)、Spring JDBC Template 以及 Apache Commons DbUtils 統(tǒng)治了 Java 開(kāi)發(fā)者的工具箱。它們的共同特征非常明顯：

關(guān)系型數(shù)據(jù)庫(kù)

它們的設(shè)計(jì)初衷就是為了更好地操作 Oracle, MySQL, PostgreSQL 等數(shù)據(jù)庫(kù)。核心邏輯無(wú)論是 ORM 映射還是 SQL 模板，都緊緊圍繞著 SQL 標(biāo)準(zhǔn)。

專有性

當(dāng) NoSQL 興起后，這些框架顯得力不從心。于是我們看到了 MongoDB Java Driver、Elasticsearch RestHighLevelClient 等專有 SDK。

這種格局導(dǎo)致了一個(gè)現(xiàn)象：要么專有，要么偏向純關(guān)系型數(shù)據(jù)庫(kù)。如果你的應(yīng)用既要查 MySQL 也要查 Elasticsearch，你通常需要引入兩套完全不同的技術(shù)棧，寫(xiě)兩套風(fēng)格迥異的代碼。

破舊嘗試

數(shù)據(jù)庫(kù)技術(shù)一直在不斷的迭代，文檔型數(shù)據(jù)庫(kù)（MongoDB）、搜索引擎（Elasticsearch/OpenSearch）、鍵值存儲(chǔ)（Redis）、時(shí)序數(shù)據(jù)庫(kù)乃至現(xiàn)在的向量數(shù)據(jù)庫(kù)蜂擁而至。

面對(duì)這些 “新東西”，我們熟悉的“老配方”也在嘗試去解決新問(wèn)題。于是我們看到了一系列試圖彌合裂痕的動(dòng)作：

Hibernate OGM

試圖將 JPA 標(biāo)準(zhǔn)延續(xù)到 NoSQL 領(lǐng)域，用注解映射非關(guān)系型數(shù)據(jù)。

Spring Data

通過(guò)統(tǒng)一的 Repository 接口抽象，試圖掩蓋底層實(shí)現(xiàn)的差異（如JpaRepository與MongoRepository）。

Easy-ES

試圖用 MyBatis-Plus 的習(xí)慣去操作 Elasticsearch，讓開(kāi)發(fā)者像操作數(shù)據(jù)庫(kù)表一樣操作索引。

然而，這些努力雖然緩解了問(wèn)題，但依然難以掩蓋核心的困境：

套用 SQL 思維： SQL 是關(guān)系型數(shù)據(jù)庫(kù)的通用語(yǔ)，但對(duì)于具有嵌套結(jié)構(gòu)、倒排索引或圖關(guān)系的數(shù)據(jù)，強(qiáng)行套用 SQL 或表格思維。 像 Easy-ES 這樣的工具雖然方便，但在處理 ES 特有的聚合或復(fù)雜 DSL 時(shí)，往往還是需要回退到原生 QueryDSL。

中間件對(duì) JDBC 的態(tài)度： JDBC 本是 Java 屆最成功的抽象之一，但它被打上了深深的關(guān)系型數(shù)據(jù)庫(kù)烙印。

API 接口層面的持續(xù)割裂： 盡管有 Spring Data 這樣的封裝，但底層的割裂依然存在。

這種割裂不僅增加了學(xué)習(xí)成本，更讓架構(gòu)設(shè)計(jì)變得復(fù)雜。我們看似有了一堆工具，但依然沒(méi)有一個(gè)真正的“One API”來(lái)統(tǒng)一所有數(shù)據(jù)訪問(wèn)。

One API Access Any DataBase

既然已經(jīng)走向多元化，數(shù)據(jù)訪問(wèn)層（DAL）也必須進(jìn)化。新一代數(shù)據(jù)訪問(wèn)庫(kù)的使命，應(yīng)當(dāng)是讓數(shù)據(jù)訪問(wèn)重新實(shí)現(xiàn)標(biāo)準(zhǔn)化和統(tǒng)一化。

我們不再應(yīng)該問(wèn)“這是什么數(shù)據(jù)庫(kù)？”，而應(yīng)該問(wèn)“我想在這個(gè)數(shù)據(jù)源上做什么操作？”。

繼承 JDBC 和 SQL 的普世精神，但打破其對(duì)關(guān)系型數(shù)據(jù)庫(kù)的枷鎖，這就是新一代數(shù)據(jù)訪問(wèn)庫(kù)的目標(biāo)。將其概括為一句就是："One API Access Any DataBase"。

技術(shù)選擇與可行路徑

要實(shí)現(xiàn)這個(gè)宏大的愿景，技術(shù)上有兩條主要路徑可供選擇：

路徑 1：統(tǒng)一 DSL

這條路試圖定義一種“萬(wàn)能語(yǔ)言”，能同時(shí)表達(dá)關(guān)系查詢、文檔檢索、圖遍歷等邏輯。

類(lèi)似 SQL 的統(tǒng)一 DSL： 本質(zhì)的難點(diǎn)在于應(yīng)用場(chǎng)景的不同，導(dǎo)致很難有一個(gè)統(tǒng)一的 DSL 能在所有場(chǎng)景下適用。比如 Oracle、MongoDB、Elasticsearch 甚至是 Redis 在語(yǔ)法層面達(dá)成共識(shí)。

自然語(yǔ)言： 一種更大膽的假設(shè)，基于 LLM 大語(yǔ)言模型直接將自然語(yǔ)言解釋為數(shù)據(jù)庫(kù)引擎可執(zhí)行的物理執(zhí)行計(jì)劃，也就是：自然語(yǔ)言 -> AI -> 算子樹(shù) -> 存儲(chǔ)引擎， AI 在這一過(guò)程中充當(dāng)了 Parser 和 Optimizer 的角色，直接驅(qū)動(dòng)數(shù)據(jù)庫(kù)內(nèi)核運(yùn)行具體的物理任務(wù)。但在當(dāng)下，AI 在處理語(yǔ)義精確性、數(shù)據(jù)訪問(wèn)安全性以及復(fù)雜邏輯推理時(shí)仍存在“幻覺(jué)”風(fēng)險(xiǎn)。 將不確定的 AI 推理直接作用于確定性的數(shù)據(jù)存儲(chǔ)內(nèi)核，這將會(huì)是一場(chǎng)極具冒險(xiǎn)的行為。因此，它更多被視為輔助工具（Copilot），而非底層的、確定性的數(shù)據(jù)訪問(wèn)標(biāo)準(zhǔn)。

路徑 2：基本范式的抽象

操作（Operation）是數(shù)據(jù)訪問(wèn)的本質(zhì)。相比發(fā)明新語(yǔ)言或依賴 AI，顯得更加務(wù)實(shí)且可控。無(wú)論數(shù)據(jù)存在 MySQL 的行、Redis 的 Key、Elasticsearch 的 Document、還是 Neo4j 的節(jié)點(diǎn)。

應(yīng)用程序?qū)?shù)據(jù)的使用場(chǎng)景絕大多數(shù)時(shí)候都逃不出增（Create）、刪（Delete）、改（Update）、查（Read）這四個(gè)基本范式。

行為為中心： 不同于 SQL 關(guān)注“如何描述數(shù)據(jù)”，統(tǒng)一 API 關(guān)注“應(yīng)用想對(duì)數(shù)據(jù)做什么”?！案鶕?jù) ID 獲取對(duì)象”是一個(gè)通用的意圖，無(wú)論底層是SELECT * FROM table WHERE id=?還是GET /index/_doc/id，其業(yè)務(wù)語(yǔ)義是完全一致的。

逃生艙（Escape Hatch）： 當(dāng)然，如果僅有簡(jiǎn)單的 CRUD 是無(wú)法覆蓋真實(shí)業(yè)務(wù)中 20% 的復(fù)雜場(chǎng)景（如深度聚合、圖算法分析）。因此，統(tǒng)一 API 方案必須包含一個(gè)逃生艙機(jī)制。 當(dāng)標(biāo)準(zhǔn) CRUD 無(wú)法滿足需求時(shí)，開(kāi)發(fā)者可以借助 JDBC 的Statement接口，直接下發(fā)專有 DSL（如 Elasticsearch JSON Query）或標(biāo)準(zhǔn)化 SQL。 底層的適配器不僅負(fù)責(zé)翻譯標(biāo)準(zhǔn) CRUD，也允許透?jìng)髟?API 或 SDK 調(diào)用，確保簡(jiǎn)單場(chǎng)景統(tǒng)一化，復(fù)雜場(chǎng)景如初般強(qiáng)大。

適配器模式： 通過(guò)定義一套標(biāo)準(zhǔn)的 API（如insert,update,query），我們可以在底層通過(guò)適配器模式，將這些標(biāo)準(zhǔn)請(qǐng)求動(dòng)態(tài) “翻譯” 為不同數(shù)據(jù)源的方言（Dialect）。

新一代數(shù)據(jù)訪問(wèn)庫(kù)

我認(rèn)為“新一代 Java 數(shù)據(jù)訪問(wèn)庫(kù)”應(yīng)該具是以 One API Access Any DataBase 為核心愿景，通過(guò)標(biāo)準(zhǔn)化的 API 屏蔽底層數(shù)據(jù)源的差異，為開(kāi)發(fā)者提供統(tǒng)一、簡(jiǎn)單、高效的數(shù)據(jù)操作體驗(yàn)為目標(biāo)。

它不應(yīng)再區(qū)分“這是 ORM”還是“這是 Client”，它就是應(yīng)用通往數(shù)據(jù)的統(tǒng)一大門(mén)。

dbVisitor 的技術(shù)嘗試

dbVisitor正是基于這一理念誕生的技術(shù)嘗試。它的架構(gòu)設(shè)計(jì)非常獨(dú)特，可以概括為：API訪問(wèn)庫(kù) + JDBC Driver的雙層適配架構(gòu)。

API訪問(wèn)庫(kù)：提供統(tǒng)一 API

dbVisitor 的數(shù)據(jù)訪問(wèn)層不依賴于具體的 SQL 語(yǔ)法，而是提供高度抽象的 API。例如：查詢構(gòu)造器

這一層負(fù)責(zé)屏蔽 Java 對(duì)象與數(shù)據(jù)模型之間的映射差異。

在此過(guò)程中，方言（Dialect）扮演了關(guān)鍵的翻譯官角色。它負(fù)責(zé)根據(jù)上層統(tǒng)一 API 的調(diào)用行為（如.list(),.eq()），生成目標(biāo)數(shù)據(jù)源能夠理解的專有 DSL（如 MySQL 的 SQL、MongoDB 的 BSON Command、Elasticsearch 的 JSON DSL）。

這些生成的 DSL 隨后會(huì)被下發(fā)到JDBC Driver 適配層，由對(duì)應(yīng)的驅(qū)動(dòng)執(zhí)行器完成最終的數(shù)據(jù)交互。這種機(jī)制確保了業(yè)務(wù)代碼的純凈性，同時(shí)保留了對(duì)底層特性的精確控制。

JDBC Driver 適配器

標(biāo)準(zhǔn)下的選擇性實(shí)現(xiàn)，這是 dbVisitor 最具創(chuàng)新性的地方。它沒(méi)有重新發(fā)明輪子去寫(xiě)一套私有協(xié)議的 Driver，而是選擇復(fù)用 JDBC 標(biāo)準(zhǔn)接口，但對(duì)其內(nèi)涵進(jìn)行了擴(kuò)展和適配。

dbVisitor 的解法是引入一個(gè)輕量級(jí)的驅(qū)動(dòng)適配器框架。它將 JDBC 繁瑣的狀態(tài)管理和復(fù)雜的接口規(guī)范，封裝為簡(jiǎn)單的Request/Response 模型。

開(kāi)發(fā)者不需要去實(shí)現(xiàn)一個(gè)完整的 JDBC 規(guī)范，只需要關(guān)注核心的數(shù)據(jù)交互邏輯，并實(shí)現(xiàn)Request/Response 模型即可。

這種簡(jiǎn)化極大降低了適配新數(shù)據(jù)源的成本，從而能夠快速適配絕大多數(shù)的數(shù)據(jù)訪問(wèn)需求。

通過(guò)這種“舊瓶裝新酒”的方式，dbVisitor 既保留了 JDBC 生態(tài)的兼容性（你可以直接用 Druid 連接池管理 ES 連接），又實(shí)現(xiàn)了對(duì) NoSQL 的原生級(jí)支持。

目前的挑戰(zhàn)

盡管 dbVisitor 的雙層適配架構(gòu)解決了大部分通用問(wèn)題，但在實(shí)現(xiàn) "One API" 的征途中，我們依然面臨著一些客觀存在的挑戰(zhàn)：

封裝與穿透： Request/Response 模型可以極大地簡(jiǎn)化了適配器開(kāi)發(fā)，但沒(méi)有任何一種抽象能完美覆蓋所有底層特性。當(dāng)開(kāi)發(fā)者需要使用某個(gè)數(shù)據(jù)源極其特殊的特性時(shí)， 目前的解法是允許使用 JDBC 的unwrap方法直達(dá)底層 SDK。雖然這在一定程度上破壞了封裝性，不作為推薦用法，通過(guò)這種“開(kāi)后門(mén)”的方式，保證了在極端場(chǎng)景下問(wèn)題依然可解。

DSL 困境： 并非所有 NoSQL 都有完善的查詢語(yǔ)言，對(duì)于那些沒(méi)有標(biāo)準(zhǔn) DSL 的數(shù)據(jù)庫(kù)，dbVisitor 不得不采用一種折中方案：用 DSL 語(yǔ)法來(lái)模仿 SDK 的 API 調(diào)用結(jié)構(gòu)。 這樣做的好處是保留了近似官方的習(xí)慣用法，降低了認(rèn)知門(mén)檻。但壞處也很明顯：不同版本的 SDK API 差異甚至是不兼容的 API 結(jié)構(gòu)。 這會(huì)削弱了 DSL 本身的標(biāo)準(zhǔn)化程度和穩(wěn)定性，加重認(rèn)知負(fù)擔(dān)。這個(gè)問(wèn)題只能寄希望于數(shù)據(jù)庫(kù)廠商可以有一個(gè)屬于它自己的標(biāo)準(zhǔn)的查詢語(yǔ)法出現(xiàn)，例如 Elasticsearch 的 QueryDSL。

最佳實(shí)踐總結(jié)：

經(jīng)過(guò)大量的適配實(shí)踐，我發(fā)現(xiàn)實(shí)現(xiàn)"One API"的最佳路徑，是依賴于數(shù)據(jù)庫(kù)廠商提供的標(biāo)準(zhǔn) DSL 或 Shell Commands。

如果數(shù)據(jù)庫(kù)本身提供了一套穩(wěn)定的文本協(xié)議（如 SQL, MongoDB Shell Command, Elasticsearch DSL），那么基于這些標(biāo)準(zhǔn)協(xié)議構(gòu)建適配器，對(duì)接底層 API，是最穩(wěn)健、兼容性最好的方式。

對(duì)于沒(méi)有 DSL 的 數(shù)據(jù)庫(kù)，只需要模仿它 API 的調(diào)用方式，提供一個(gè) Shell Command，這一點(diǎn)可以借鑒 MongoDB 的思路。

dbVisitor 實(shí)戰(zhàn)演示

為了讓大家更直觀地感受"One API"的魅力，以最常見(jiàn)的 CRUD 操作為例，展示 dbVisitor 如何在不同數(shù)據(jù)源間保持統(tǒng)一的編碼體驗(yàn)。

1. 統(tǒng)一的 CRUD 體驗(yàn)

無(wú)論底層是MySQL、MongoDB還是Elasticsearch，開(kāi)發(fā)者都可以使用完全一致的 API 進(jìn)行數(shù)據(jù)操作。

2. 底層 API 可達(dá) (Escape Hatch)

當(dāng)統(tǒng)一 API 無(wú)法滿足特殊需求時(shí)（例如 Redis 的特定原子操作，或 ES 的特殊聚合），dbVisitor 允許通過(guò)unwrap機(jī)制“穿透”到底層驅(qū)動(dòng)，直接使用原生 SDK。

dbVisitor 的生態(tài)現(xiàn)狀

目前，dbVisitor 已經(jīng)實(shí)現(xiàn)了對(duì)多類(lèi)數(shù)據(jù)源的統(tǒng)一訪問(wèn)支持，正在一步步踐行新一代數(shù)據(jù)訪問(wèn)庫(kù)的承諾：

關(guān)系型數(shù)據(jù)庫(kù)：MySQL, PostgreSQL, Oracle, SQLServer, H2, SQLite 等。

NoSQL 支持：Elasticsearch、MongoDB、Redis

在 dbVisitor 的世界里，開(kāi)發(fā)者不再需要為了引入一個(gè)新的中間件而重構(gòu)整個(gè)數(shù)據(jù)訪問(wèn)層代碼。One API, Access Any DataBase，這不僅僅是一句口號(hào)。

如果你對(duì)這個(gè)項(xiàng)目非常感興趣不妨“加個(gè)關(guān)注”及對(duì)我支持一下。