詳解JavaScript中的嵌入式資料庫

導讀	擴充套件這些資料庫，保持資訊的一致性和容錯性本身就是一個挑戰。但是，當我們的資料需求非常小時會發生什麼？

我們習慣於將資料庫視為巨大的儲存平臺，我們可以在其中儲存我們需要的所有資料，然後透過某種形式的查詢語言檢索它。擴充套件這些資料庫，保持資訊的一致性和容錯性本身就是一個挑戰。但是，當我們的資料需求非常小時會發生什麼?
當RedShift、BigQuery、甚至MySQL對我們微小的資料需求來說是一個太大的解決方案時，會發生什麼?好吧，事實證明，有一個應用程式可以解決這個問題。事實上，有很多選擇，所以在這裡，我將介紹5大嵌入式資料庫，以滿足你的微小資料需求。

當我們讀到“嵌入式”這個詞時，90% 的人會得出結論，我說的是物聯網或移動裝置。但這種情況並非如此。

反正不是唯一的情況。誠然，這些系統的資源非常有限，這使得大多數傳統的資料庫系統很難配置和安裝在那裡。

但是對於小型資料庫還有其他的用例，也就是將它們嵌入到軟體產品中。例如，想象一下透過您的IDE在一個大型程式碼儲存庫上進行搜尋。IDE可以嵌入一個反向索引資料庫，允許您搜尋關鍵字並快速獲取相關檔案的參考。或者在您最喜歡的電子郵件桌面客戶端上執行搜尋時，該客戶端很可能也有一個嵌入式資料庫。所有的電子郵件都儲存在那裡並被編入索引，所以你可以快速輕鬆地訪問這些資訊。

到目前為止，您可能已經瞭解了嵌入式資料庫的另一個巨大好處，即它們不需要與網路呼叫進行互動。與標準資料庫相比，這是一個巨大的效能提升。從本質上講，在正常的開發中，你希望把資料庫放在自己的伺服器(或伺服器叢集)上，這樣它的資源消耗就不會影響到你架構中的其他元件，而對於嵌入式資料庫，你希望它們儘可能地靠近客戶端程式碼。這就減少了它們之間的延遲，避免了對通訊渠道(即網路)的依賴。

現在，這個想法可以有多種形式，從使用 JSON 檔案作為主儲存的快速記憶體資料庫，到可以使用類似 SQL 的語言進行查詢的高效微型關聯式資料庫。

讓我們來看看5種選擇。

讓我們從簡單的開始，LowDB 是一個小型的記憶體資料庫。這是一個非常基本的解決方案，但它解決了一個非常簡單的用例：需要從基於 JavaScript 的專案中儲存和訪問類似 JSON 的結構(即文件)。

LowDB的一個主要好處是它可以從JavaScript中使用，也就是說：它可以用於後端、桌面和瀏覽器程式碼。

在後端，你可以將它與 Node.js 一起使用，對於桌面開發，它可以整合到一個 Electron 專案中，最後，它也可以透過其整合的 JS 執行時直接在瀏覽器上執行。

這個資料庫提供的API也相當簡單和簡約，它不提供任何開箱即用的搜尋功能。它只限於將一個JSON檔案的資料載入到一個陣列變數中，讓你(使用者)以你認為合適的方式找到你要找的東西。

例如，看看下面的程式碼：

import { LowSync, JSONFileSync } from 'lowdb' 
 
const title = "This is a test" 
const adapter = new JSONFileSync('file.json') 
const db = new LowSync(adapter) 
 
db.read()  //將檔案內容載入到記憶體中 
db.data ||= { posts: [] } //預設值 
 
db.data.posts.push({ title }) //將資料新增到“集合”中 
 
db.write() //透過將資料儲存到JSON檔案來持久化資料 
 
//任何類似於查詢的操作都由使用者自己來完成 
 
let record = db.data.posts.find( p => p.title == "Hello world") 
 
if(!record) { 
  console.log("No data found!") 
} else { 
  console.log("== Record found ==") 
  console.log(record) 
}

正如你所看到的，這裡有趣的部分不是預設的行為，而是我正在使用一個叫做 JSONFileSync 的介面卡。我可以很容易地使用一個由我建立的自定義的介面卡，這才是這個資料庫的真正強項。

它具有高度的可擴充套件性並與 TypeScript 相容，後者為資料儲存提供了類似於模式的行為(即不允許新增不遵循預設模式的資料)。

如果混合使用這兩種選項，那麼LowDB將成為處理本地類似json的資料的有趣選項。

LevelDB 是由 Google 構建的開源鍵值資料庫。它是一種超快但非常有限的鍵值儲存，其中資料按開箱即用的鍵排序儲存。

它只有三個基本操作：Put、Get 和 Delete，沒有別的——如果你仔細想想，有點像 LowDB。

和LowDB一樣，它沒有一個客戶端-伺服器封裝器，這意味著沒有辦法從任何語言與它通訊，如果你想使用它，你必須使用C/C++庫，如果你想要一個類似伺服器的行為，你必須自己封裝它。

就像我們在這裡要介紹的大多數案例一樣，功能非常基本，因為它們涵蓋了一個非常簡單但需要的用例：在靠近程式碼的地方儲存資料並快速訪問。

該資料庫的儲存架構是圍繞著日誌結構的合併樹(LSM)，這意味著它被最佳化為大型的連續寫操作，而不是小型的隨機操作。

LevelDB 的一個主要限制是，一旦開啟，它就會在儲存上獲得系統級鎖，這意味著當時只有一個程式可以與資料庫互動。當然，您可以使用多個執行緒來並行化該程式中的某些操作。但這就是它的範圍。

有趣的是，這個資料庫被用作Chrome的IndexedDB的後臺資料庫，顯然Minecraft Bedrock版也使用它來儲存一些分塊和實體資料(儘管從外觀上看，他們使用的是谷歌實現的略微修改的版本)。

我之前提到過物聯網不是嗎? Raima 是速度最快的資料庫管理器之一，專門針對在資源受限的物聯網裝置中執行進行了最佳化。

資源受限的環境是什麼意思? Raima 只需要 350kb 的 RAM 即可執行。這就是我可以極簡的資源利用。

該解決方案的主要特點之一是它完全支援 SQL，這一點在之前的任何解決方案中都沒有出現。它提供了一個關係資料模型，並允許您使用 SQL 語言進行查詢。

與 LevelDB 不同的是，它還允許透過客戶端-伺服器架構對資料庫進行多程式訪問(即這種架構允許您比其他架構更遠離原始碼)。如果您決定採用接近原始碼的嵌入式應用程式，您還可以使用多執行緒來支援對多個資料庫的併發訪問。

Raima的靈活性允許你從傳統的客戶-伺服器方法到最有效的(當然也是有限的)使用案例，即由單個客戶消費的單一記憶體資料庫。但是，嘿，這是一個非常有效的嵌入式資料庫的使用案例。

這種靈活性使它成為一種非常通用的解決方案。當然，每種部署模式都有自己的優點和限制，但是也會針對特定的用例進行最佳化。因此，請確保您選擇了正確的一個，並從這個資料庫中獲得最大的好處。

如果你正在尋找另一個非常小的、類似SQL的資料庫，Apache Derby很可能是你正在尋找的東西。

Derby完全是用JAVA編寫的，當它聲稱只有3.5Mb的記憶體佔用時，也損失了一點信譽。畢竟，如果沒有在主機系統上安裝JVM，您就不能執行或使用它。

也就是說，如果您的用例允許使用JVM，那麼很好，您可以繼續考慮Derby，否則您可能希望使用更本地的解決方案，如LevelDb或Raima。

但正如我所說，如果您已經在從事 JAVA 專案並且需要整合一個小型、可靠、基於 SQL 的資料庫，那麼 Derby 絕對是一個潛在的候選者。

它帶有一個整合的 JDBC 驅動程式，因此不需要額外的依賴項。它既可以在 JAVA 應用程式內的嵌入式模式下工作，也可以作為獨立伺服器執行，允許多個應用程式同時與其互動(類似於 Raima 的工作方式，但沒有許多變體)。

說實話，這個專案最大的缺點是它的文件。它可能是JAVA社群的一個標準，但它對使用者並不友好，大部分的官方連結都把讀者送到一個私人的匯合頁面。這裡的許多其他解決方案在涉及到文件時提供了更順暢的體驗，這也有助於他們產品的採用。

最後，solidDB提供了一個非常有趣的記憶體關聯式資料庫，它同時還可以增強一個永續性模型。聲稱它可以保持兩個資料儲存選項實時同步。這可不是個小要求。

本質上就像這裡列出的其他解決方案一樣，solidDB 可以透過 ODBC 或 JDBC 訪問，這允許 JAVA 和 C 應用程式透過 SQL 與其互動。

也像這裡列出的一些解決方案一樣，它可以以多種模式部署：

高可用性模式。這涉及具有重複資料的多個伺服器。當然，這種模式在我們考慮的用例中並不多。
共享記憶體訪問。這個方案非常有趣，因為它不僅將資料儲存在記憶體中(就像已經列出的其他解決方案一樣)，而且還允許多個應用程式訪問該記憶體(因此有共享記憶體部分)。當然，對共享記憶體的直接訪問需要由同一節點內的應用程式完成，但是，它還允許基於 JDBC/ODBC 從外部節點訪問相同的資料。將共享記憶體轉變為具有外部訪問許可權的記憶體資料庫。
由於訪問資料的速度快如閃電，思科、阿爾卡特、諾基亞和西門子等多家知名企業聲稱將使用該資料庫進行關鍵任務操作。

鑑於其所有的部署模式、廣泛的文件和高需求的客戶名單，我可以看到這是這個名單上最可靠、最穩定、最快速的嵌入式資料庫之一。

嵌入式資料庫是為了處理一個非常具體的用例，或者透過提供快速可靠的資料儲存和最小的延遲，或者透過允許快速安全地訪問資料。這裡列出的解決方案透過不同的手段實現這些目標，這取決於你和你的特定環境，以決定哪一個是適合你的。

原文來自：