自90年代末以來，數(shù)據(jù)庫系統(tǒng)激增。盡管當(dāng)時的選擇相對較少，但現(xiàn)在有數(shù)百種數(shù)據(jù)庫系統(tǒng)可供選擇，涵蓋了不同的架構(gòu)、API、模型等。本文將對嵌入式和客戶端/服務(wù)器兩種數(shù)據(jù)庫系統(tǒng)架構(gòu)進行比較和對比。

在這些體系結(jié)構(gòu)中，你可以找到各種類型的數(shù)據(jù)庫系統(tǒng):

關(guān)系型/SQL

分層

網(wǎng)絡(luò)模型（層次結(jié)構(gòu)的超集）

圖形數(shù)據(jù)庫（網(wǎng)絡(luò)模型的超集）

NoSQL

NewSQL

Columnar

內(nèi)存/持久/混合

等等。

即使是NoSQL也包含了一系列的模型、文檔、鍵/值、寬列等。

嵌入式數(shù)據(jù)庫系統(tǒng)的關(guān)鍵區(qū)別在于，它們與應(yīng)用程序緊密集成，提供本地數(shù)據(jù)存儲，而不依賴于單獨的數(shù)據(jù)庫服務(wù)器。換句話說，數(shù)據(jù)庫功能被編譯并與應(yīng)用程序代碼鏈接，這樣應(yīng)用程序就可以直接調(diào)用數(shù)據(jù)庫系統(tǒng)，就像它調(diào)用宿主語言庫的標準函數(shù)（例如標準C庫）一樣。這消除了執(zhí)行路徑中的進程間通信以及由此帶來的所有延遲。

消除客戶端/服務(wù)器負擔(dān)還可以減少數(shù)據(jù)庫系統(tǒng)的代碼大小和資源消耗需求。結(jié)果是一個更小、更快的數(shù)據(jù)庫系統(tǒng)。這使得嵌入式數(shù)據(jù)庫系統(tǒng)更適合資源受限的嵌入式系統(tǒng)。然而，請注意，“嵌入式數(shù)據(jù)庫”一詞與“嵌入式系統(tǒng)”一詞完全無關(guān)。

嵌入式數(shù)據(jù)庫系統(tǒng)至少從80年代早期就已經(jīng)出現(xiàn)了，遠遠早于嵌入式系統(tǒng)擁有足夠的處理能力來利用任何類型的數(shù)據(jù)庫系統(tǒng)。8位和16位嵌入式系統(tǒng)無法尋址足夠的內(nèi)存，所以直到90年代后期基于32位處理器的嵌入式系統(tǒng)變得普遍，嵌入式數(shù)據(jù)庫系統(tǒng)才開始在嵌入式系統(tǒng)中使用。

因此，嵌入式數(shù)據(jù)庫系統(tǒng)產(chǎn)生于在Windows、Unix和類Unix系統(tǒng)上為一系列業(yè)務(wù)應(yīng)用程序提供數(shù)據(jù)庫支持的需求。

嵌入式數(shù)據(jù)庫系統(tǒng)的嵌入式特性限制了它們的可擴展性。但是，考慮到用例，這并不是一個問題。由于沒有進程間通信，共享數(shù)據(jù)庫的所有并發(fā)任務(wù)都存在于一個系統(tǒng)中，并且可以在單個系統(tǒng)上啟動的進程和/或線程的數(shù)量存在固有的限制，即使是具有數(shù)十個內(nèi)核和數(shù)百或數(shù)千GB內(nèi)存的相對較大的Linux系統(tǒng)。

相比之下，在強大的服務(wù)器上托管的客戶機/服務(wù)器數(shù)據(jù)庫系統(tǒng)可以有10個、100個或1000個連接到數(shù)據(jù)庫服務(wù)器并請求數(shù)據(jù)庫系統(tǒng)的CRUD(創(chuàng)建、讀取、更新、刪除)服務(wù)的其他系統(tǒng)。這些系統(tǒng)需要能夠比嵌入式數(shù)據(jù)庫系統(tǒng)更大程度地擴展。

客戶端和服務(wù)器的分離還可以提高整個系統(tǒng)的安全性/可靠性。因為嵌入式數(shù)據(jù)庫與應(yīng)用程序相鏈接，所以它們共享相同的地址空間。這使得錯誤的應(yīng)用程序有可能破壞數(shù)據(jù)庫或嵌入式數(shù)據(jù)庫系統(tǒng)運行時，或者同時破壞兩者。

通過獨立的客戶端和服務(wù)器進程，操作系統(tǒng)可以將數(shù)據(jù)庫服務(wù)器與惡意應(yīng)用程序隔離開來。客戶端進程也可能運行在完全獨立的系統(tǒng)中，進一步將它們與數(shù)據(jù)庫服務(wù)器隔離開來。

嵌入式數(shù)據(jù)庫比客戶機/服務(wù)器數(shù)據(jù)庫更容易部署和維護。嵌入式數(shù)據(jù)庫系統(tǒng)只是應(yīng)用程序安裝過程中的一部分?？蛻魴C/服務(wù)器數(shù)據(jù)庫系統(tǒng)必須單獨安裝，通常安裝在單獨的服務(wù)器上。還必須對其進行配置，以提高可伸縮性。這通常需要數(shù)據(jù)庫管理員(DBA)的參與。

有一種說法認為客戶端/服務(wù)器數(shù)據(jù)庫擅長復(fù)雜的操作/事務(wù)，但嵌入式數(shù)據(jù)庫系統(tǒng)中通常沒有任何固有的東西可以阻止它們執(zhí)行同樣復(fù)雜的操作。當(dāng)然，SQL語言的覆蓋范圍的完整性以及SQL引擎優(yōu)化器的質(zhì)量存在差異，但客戶端/服務(wù)器和嵌入式數(shù)據(jù)庫系統(tǒng)都是如此。嵌入式數(shù)據(jù)庫系統(tǒng)只提供原生的、非SQL的、API，這使得在不同表的列上實現(xiàn)與排序、過濾和聚合等同的多目標聯(lián)接變得困難和/或不切實際。

總之，為了簡單、資源效率和本地數(shù)據(jù)存儲，選擇嵌入式數(shù)據(jù)庫。選擇可擴展性和集中管理至關(guān)重要的客戶端/服務(wù)器系統(tǒng)。