一個用Node.js從頭開始編寫的數據庫

Node 是輕量級和可擴展的，讓咱們能夠快速開發，並且 npm 有使人難以置信的包。

HarperDB的創始團隊創建了第一個也是惟一一個用Node.js編寫的數據庫。幾個月前，咱們的CEO Stephen Goldberg應邀參加了在Women Who Code meetup上發言，分享了這個_(有些人稱之爲瘋狂的)_努力的故事。Stephen討論了數據庫的架構層，演示瞭如何在Node.js中構建一個高度可擴展的分佈式產品，並演示了HarperDB的內部工做原理。你能夠在上面的連接中觀看他的演講，甚至能夠閱讀一篇2017年的文章，但因爲咱們都喜歡Node.js，並且這是一個有趣的話題，我在這裏總結一下。

咱們選擇用Node構建數據庫的主要（也是最簡單的）緣由是咱們對它很是瞭解。咱們由於沒有選擇Go而受到了抨擊，但如今人們已經接受了Go和Node基本上是頭對頭的關係（_在流行度和社區支持度上_）。咱們的聯合創始人之一Zach認識到，若是花時間學習一門新的語言，那是不值得的。

用 Node.js 構建數據庫的優勢

• 咱們已經知道Node.js

*輕量級

• 快速發展
• 高度可擴展性
• npm

HarperDB團隊擁有大型軟件開發的背景。咱們數據庫的最初目標是建立一個工具，使開發人員可以專一於編碼，而沒必要將時間和精力投入到數據庫維護中，同時仍然提供一個強大的解決方案。咱們但願人們對本身使用的產品感到溫馨和自信。咱們的團隊在Node之外的其餘語言方面有着豐富的經驗，但咱們在Node編程方面取得了巨大的成功。雖然來自Java，Stephen一開始認爲Node很可怕，但在大約90天后，他學會了喜歡它）。Node是輕量級的，讓咱們能夠快速開發，並且npm有使人難以置信的包。

在Node.js中構建數據庫的弊端

*當時未被接受爲 "企業級語言"。

• 不直接控制操做系統/文件系統。
• 性能不如C/C++
• 之前沒有本地線程（如今有了）。

咱們確實遇到了一些麻煩......做爲第一個用Node.js編寫的數據庫，咱們沒有選擇跟隨任何人的腳步。咱們多是有史以來第一批用Node構建的企業產品之一，至少是最以數據爲中心的產品。人們對此提出了質疑。有一我的對Stephen說，他寧願用勺子把本身的心挖出來，也不肯意用Node.js來編寫數據庫的程序。如今，人們已經意識到這是一個偉大的想法，由於咱們的產品中有全部這些使人難以置信的功能，咱們沒必要構建，而且是咱們所作的事情的固有功能。咱們確實遇到了挑戰，圍繞着不能直接控制文件系統中的操做系統。此外，C/C++的速度更快，但可能更復雜，並且不必定能橫向擴展。這真的取決於你是在尋找垂直計算仍是水平計算。

---

Free NodeJS Tutorial for Beginners:

](https://leanpub.com/tutorial-...

Download: Tutorial for node js

---

Tech Stack

這是咱們的技術棧的樣子。咱們認爲咱們的管理工做室是HarperDB堆棧的一部分，那是用React與Node後端構建的。綠框表示任何創建在HarperDB之上的應用，好比咱們的【Node-RED節點】(https://harperdb.io/blog/were...。HarperDB技術徹底用Node.js構建，它包含了咱們的接口和HarperDB核心。

咱們的產品以REST API的形式呈現，而在本質上，它只是一個Express應用，那是你如何與HarperDB交互的主要接口。咱們的NoSQL解析器是咱們內部構建的定製解決方案。咱們使用AlaSQL來實現咱們的SQL解析功能，你能夠在這裏閱讀更多信息，咱們在此基礎上用自定義代碼來擴展他們的功能，這是一個了不得的解析SQL的npm包。咱們提供驅動，好比ODBC和JDBC，由咱們的一個合做夥伴構建。最後，咱們使用SocketCluster進行分佈式計算和集羣，咱們的CTO將在幾周內介紹。

HarperDB的核心技術包含了 "祕籍"。這就是讓咱們可以在沒有數據重複的狀況下進行徹底的索引，併爲單一數據模型提供各類接口選項的緣由。在覈心內部，實現了許多npm包來擴展咱們的功能。

最後咱們有各類存儲介質的選擇。咱們默認捆綁LMDB，由於它比其餘選項提供了顯著的性能提高。HarperDB核心包含可擴展的代碼，容許咱們在將來添加更多的存儲介質選項。

REST API

• HarperDB是一套微服務。
• 一個單一的端點
• 全部業務均爲員額。
• 無狀態/休息型

(代碼樣本見https://docs.harperdb.io/__)_。

在之前的一家公司，咱們的團隊要處理上百個不一樣端點的API，這簡直是瘋了。你們可能會以爲HarperDB只有一個端點很奇怪，但若是你看一下代碼的主體，你作的每個操做--你所要改變的只是主體，也就是前面那幾行。這是超級簡單的，當你編寫一個基於REST的應用程序時，你能夠把它變得很是直接。這是你能夠從咱們這裏學到的東西，而且能夠在任何應用程序中使用。基本上，你向API發佈一條消息，咱們就會看到你在執行什麼操做，而後用一套標準的方法來處理它。在過去的幾年裏，咱們重寫了不少應用，但這部分基本保持不變。

管理工做室

• 以HarperDB REST API爲基礎。
• 用React Native編寫
• 容許經過GUI控制HarperDB實例。

HarperDB管理工做室是創建在咱們微服務之上的React前端（因此咱們吃本身的狗糧）。JavaScript有一個很讚的地方就是它的輕量級，無論你用的是什麼框架（Node、React等），你均可以很容易地把這些不一樣的層耦合在一塊兒。React很神奇，它改變了前端開發的質量，讓咱們的應用更容易上手。經過在此基礎上進行構建，咱們也在同時測試咱們本身的API--這讓它變得很是強大。Jaxon，咱們的產品副總裁選擇了React做爲Studio，而Stephen則用Express編寫咱們的後端報告。

---

AlaSQL

• SQL搜索是創建在AlaSQL基礎上的。
• https://github.com/agershun/alasql
• 容許加強的SQL
• 咱們的開發人員爲項目作出了貢獻

咱們選擇了AlaSQL來實現HarperDB的後端功能](https://dev.to/harperdb/alasq...，它裏面有一些咱們沒有的好東西，而且容許咱們把Math.js和GeoJSON這樣的東西接入進來，因此它是一個難以想象的包。使用Node作這樣的語言有一個驚人的好處，那就是隨着技術的進步，你想要和須要的大部分酷炫的東西都在npm上。若是咱們必須創建本身的SQL解析器，咱們可能還在創建HarperDB。咱們的競爭對手之一FaunaDB花了大約4年時間才進入市場，但咱們在6個月內推出了咱們產品的測試版，12個月內推出了原始版本，幾個月前咱們剛剛發佈了咱們的雲產品（大約3年後）。**咱們並非說咱們是天才，可是經過在Node中開發，咱們獲得了站在像AlaSQL開發者這樣的人的肩膀上，這也是咱們以爲npm社區的神奇之處。

Maths.js

• HarperDB在咱們的SQL中使用了math.js函數。
• 容許加強數學能力，同時利用npm社區的能力。

Maths.js是另外一個使人難以置信的包，用於平均數、數據科學等方面，咱們把它接入了咱們的SQL功能。它並不難用，與AlaSQL結合起來很是強大。

集羣/複製

• 基於SocketCluster.io創建的。
• 容錯
• 點對點
• 表層複製
• 全球共享模式
• 分佈式計算

在Node.js中構建一些東西的另外一個很是酷的特性是，它的本質是無狀態的，這意味着它不須要在內存中持有對跨會話服務客戶相當重要的數據，這很是節省資源。大多數企業級應用都有後臺進程和有狀態的變量，會變得很是不穩定。Node是無狀態的，專爲網絡設計，設計成水平擴展，而且是點對點的。使用Node框架的一個驚人的好處是，咱們可以鏈接SocketCluster來支持咱們的集羣和複製。HarperDB使用簡單的pub-sub模型，因此咱們經過將數據發佈到不一樣的聊天室來複制數據，不一樣的節點訂閱這些數據，而且可以水平分佈。Node能夠進行水平擴展，比其餘語言的資源密集度更低，並且它的無狀態特性使它的穩定性很是高。經過將Node放在不少電腦上（水平擴展），你可使框架的功能大大加強，同時下降成本，擁有更容易的開發，併成爲一個很棒的社區的一部分。

LMDB和文件系統

*最初在文件系統上創建了咱們的爆炸數據模型。

• 因爲產生許多文件佔用節點和過多的磁盤空間以及其餘問題，存在問題。
• 在LMDB上重建數據模型
• 大幅提升性能

原本咱們是直接用文件系統與上面的HarperDB數據模型，這就是產品的獨特之處。當數據進來的時候，咱們把它映射到咱們的數據模型上，它不是一個SQL引擎或者NoSQL引擎。咱們把這些數據分解成各個屬性，而後存儲在文件系統的文件夾結構中。咱們把每一個東西都原子化地存儲，你能夠經過SQL和NoSQL來查詢。咱們確實在規模上遇到了一些挑戰，因此最近咱們在一個叫LMDB的包裏接入了一個鍵值存儲，咱們在上面操做。咱們可以在上面實現咱們精確的數據模型，它提供了使人難以置信的性能提高。在最近的一次基準測試中，咱們比MongoDB](https://harperdb.io/harperdb-...，這主要得益於LMDB。