我們傾向於將資料庫視為巨大的儲存平台，我們可以在其中加載所需的所有數據，然後使用某種形式的查詢語言來檢索它。擴展這些資料庫並保持資訊的一致性和容錯性本身就是一個挑戰。但是，當我們的數據需求非常小時會發生什麼？
當 RedShift、BigQuery 甚至 MySQL 太大而無法處理我們的微小資料需求時，會發生什麼事？事實證明，有一些應用程式可以做到這一點。實際上有很多選擇，但在這裡我將介紹 5 個最好的嵌入式資料庫，以滿足您的微小資料需求。
但什麼是嵌入式資料庫？
當我們讀到「嵌入式」這個詞時，90% 的人得出的結論是我正在談論物聯網或行動裝置。但事實並非如此。
至少不完全是這樣。當然，這些系統的資源非常有限，因此很難配置和安裝大多數傳統資料庫系統。
但是使用小型資料庫還有其他選擇，即將它們嵌入軟體產品中。例如，假設您的 IDE 正在搜尋大型程式碼儲存庫。 IDE 可以有一個內建資料庫，讓您可以搜尋關鍵字並快速引用對應的檔案。或者，當您在最喜歡的桌面電子郵件用戶端中進行搜尋時，它很可能也有一個內建資料庫。所有電子郵件都儲存在那裡並建立索引，因此您可以快速輕鬆地存取這些資訊。
您可能已經注意到，嵌入式資料庫的另一個優點是無需網路呼叫即可與它們互動。與標準資料庫相比，這是一個巨大的效能提升。本質上，在正常開發中，您希望將資料庫放在單獨的伺服器（或伺服器叢集）上，以便資源消耗不會影響架構的其餘部分，對於嵌入式資料庫，您希望它們盡可能靠近客戶端程式碼。這減少了它們之間的延遲並避免了對通訊通道（即網路）的依賴。
現在，這個想法可以採取多種不同的形式，從使用 JSON 檔案作為主儲存的快速記憶體資料庫，到可以使用 SQL 等語言存取的高效小型關聯式資料庫。讓我們來看看 5 個替代方案。
低資料庫
讓我們從簡單的開始，LowDB 是一個小型記憶體資料庫。這是一個基本的解決方案，但它提供了一個非常簡單的用例：需要從基於 JavaScript 的專案儲存和存取類似 JSON 的結構（即文件）。
LowDB 的主要優點之一是它被設計為透過 JavaScript 使用，這意味著它可以用於伺服器端、工作站和瀏覽器程式碼。
在後端，您可以將它與 Node.js 一起使用，對於桌面，它可以整合到 Electron 專案中，最後它還可以透過整合的 JS 運行時直接在瀏覽器中運行。
這個資料庫提供的API也非常簡單且最小，它不提供任何內建的搜尋功能。它僅限於將 JSON 檔案資料載入到陣列變數中，並允許您（使用者）以您認為合適的方式找到您要查找的內容。例如，看一下下面的程式碼：
正如您所看到的，這裡有趣的不是預設行為，而是我正在使用名為 JSONFileSync 的適配器這一事實。我可以輕鬆地使用我創建的自訂適配器，這是該資料庫的真正優勢。
它具有高度可擴展性並與 TypeScript 相容，TypeScript 為資料儲存提供了示意行為（即不允許添加不遵循預定義架構的資料）。
水平資料庫
LevelDB 是 Google 建立的開源鍵值資料庫。這應該是一個超快但非常有限的鍵值存儲，它存儲按開箱即用的鍵排序的數據。
它只有三個主要操作：Put、Get 和Delete，僅此而已，如果您仔細想想，與 LowDB 類似。
與 LowDB 一樣，該資料庫沒有客戶端-伺服器 shell，這意味著無法使用任何語言與其進行通訊。您必須使用 C/C++ 庫，如果您想要類似伺服器的行為，則必須自行包裝它。
與我們將在這裡介紹的大多數情況一樣，該功能非常簡單，因為它涵蓋了一個非常簡單但必要的用例：將資料儲存在程式碼附近並快速存取它。
資料庫儲存架構基於日誌結構合併（LSM）樹，這意味著它針對大型順序寫入而不是小型隨機寫入進行了最佳化。
LevelDB 的主要限制之一是它在開啟時會取得儲存上的系統級鎖，這意味著一次只有一個 bc 數據巴西 程序可以與資料庫互動。當然，您可以使用多個執行緒來並行化該進程內的某些操作。但僅此而已。
有趣的是，這個資料庫被用作 Chrome 的 IndexedDB 的後端資料庫，顯然 Minecraft 的基岩版使用它來儲存一些片段和實體（儘管它們似乎使用了 Google 實現的稍微修改的版本）。
賴瑪資料庫管理器
我已經提過物聯網，不是嗎？Raima是最快的資料庫管理器之一，專門針對在資源受限的裝置上運作進行了最佳化。
資源受限環境是什麼意思？ Raima 僅需 350 KB RAM 即可運作。這就是它的意義——資源的最小化利用。
該解決方案的主要 布拉格市中心辦事處的網站 例如，我們為 特徵之一是該解決方案完全支援 SQL，這是之前任何解決方案中所沒有的。它提供了一個關聯式資料模型，並允許您使用 SQL 語言執行查詢。
此外，與 LevelDB 不同，Raima 允許透過客戶端-伺服器架構進行多處理器存取資料庫（即，它允許您比其他架構更遠離原始程式碼）。而且，如果您決定使用接近來源的本機應用程序，您還可以使用多執行緒來支援同時存取多個資料庫。
Raima 的靈活性可讓您從傳統的用戶端伺服器方法轉變為使用由單一用戶端使用的單一記憶體資料庫的最有效（當然也是有限）的選項。這是嵌入式資料庫的合適用例。
這種靈活性使 Raima 成為非常通用的解決方案。當然，每種部署模式都有其自身的優點和局限性，但也會針對特定用例進行最佳化。因此，請確保選擇適合您的資料庫並充分利用該資料庫。
阿帕契德比
如果您正在尋找另一個 資料庫數據 非常小的類似 SQL 的資料庫，Apache Derby很可能就是您一直在尋找的。
Derby 完全用 JAVA 編寫，聲稱只佔 3.5 MB。但歸根結底，如果不在主機系統上安裝 JVM，則無法以任何方式運行或使用它。
話雖這麼說，如果您的用例允許 JVM 那麼好，您可以繼續考慮 Derby，否則您可以選擇其他解決方案，例如 LevelDb 或 Raima。
但就像我說的，如果您已經在從事 JAVA 專案並且需要整合一個小型、健全的基於 SQL 的資料個內建資料庫庫，那麼 Derby 絕對是一個潛在的候選人。
它帶有內建的 JDBC 驅動程序，因此不需要額外的依賴項。它可以在 JAVA 應用程式中以嵌入模式工作，也可以作為獨立伺服器工作，允許多個應用程式同時與其互動（類似於 Raima 的做法，但沒有太多選項）。
老實說，這個專案最大的缺點是它的文件。這可能是JAVA社群的標準，但對使用者來說並不友善。這裡的許多其他解決方案提供了更好的文件體驗，這也有助於其產品的採用。
實體資料庫
最後但並非最不重要個內建資料庫的一點是，solidDB 提供了一個非常有趣的案例，它提供了一個記憶體中關係資料庫，同時可以支援模型持久性。聲稱它可以即時同步兩個資料儲存選項。
本質上，與此處列出的其他解決方案一樣，solidDB 可以透過 ODBC 或 JDBC 進行訪問，從而允許 JAVA 和 C 應用程式透過 SQL 與其進行互動。此外，與此處列出的一些解決方案一樣，solidDB 可以以多種模式部署：
- 高可用模式。假設存在多個具有重複資料的伺服器。當然，這種模式不太適合我們正在考慮的用例。
- 存取共享記憶體。這是一種非常有趣的模式，因為solidDB不僅將資料儲存在記憶體中（就像已經列出的其他解決方案一樣），而且還允許多個應用程式存取記憶體（因此是記憶體的共享部分）。當然，對該共享記憶體的直接存取必須由同一節點上的應用程式完成，但它也提供了從外部節點對相同資料的基於 JDBC/ODBC 的存取。將共享記憶體轉變為可外部存取的記憶體資料庫。
由於資料存取速度快個內建資料庫如閃電，許多知名公司（例如思科、阿爾卡特、諾基亞和西門子）都聲稱使用該資料庫來執行其關鍵任務操作。
考慮到所有部署模式、廣泛的文檔和支援的客戶端列表，我可以說這是此列表中最可靠、穩定和快速的嵌入式資料庫之一。
您過去嘗試過這些解決方案嗎？您的專案是否曾經需要一個嵌入式資料庫？你選擇了什麼。