微軟、IBM、英特爾、三星、紅帽歡迎谷歌入群，怎麼來了一條狗？

（題圖照片：2017年10月攝于丹佛共享辦公樓SPACES。）

2017年10月4日到6日，Node.js北美互動會在溫哥華勝利召開。在這次團結的大會上，谷歌正式成為Node.js基金會的白金會員。此前的白金會員包括微軟、IBM、英特爾、紅帽和三星旗下的Joyent。

這個Node.js是一位華羅庚式的茶館兒店小二，它是一種開源的、伺服器端的、非阻斷I/O、事件驅動的JavaScript運行環境。它能提高網路伺服器的用戶容量和響應速度。具體細節請參考：張戎：Node.js是用來做什麼的？和該問題下的其它答案。

總而言之，Node.js這個店小二現在是越來越招人待見了。你熟悉的很多公司都在用它，包括谷歌、蘋果、寶馬、airbnb等等。

因為Node.js依賴於谷歌的V8 JavaScript引擎，所以這次在溫哥華谷歌能成為白金會員，對於整個Node.js社區都是個積極的消息。（參考：Node.js Foundation welcomes Google as Platinum Member）

有趣的是，在會議上設立展台的除了幾大白金會員公司和利用Node.js搞託管、包裹管理、安全、雲計算的相關公司以外，還有一條狗，這是為什麼呢？

這條狗是丹佛初創公司HarperDB的圖標。HarperDB從事的不是寵物行業，而是資料庫。

用大白話說吧，HarperDB自認為給資料庫的幾大頭疼病找到了止疼片兒，而Node.js是這種止疼片兒最合適的糖衣。

先舉個例子說說資料庫幾大頭疼病吧。2016年據騰訊網報道，京東當時已有6萬快遞小哥。

劉強東爆料：京東配送條線員工總數已達6萬人_科技_騰訊網

我們知道小哥們的手持POS機（「把槍」）有客戶和訂單信息，可以實時處理收貨等交易操作，這是目前就有的。但是，假如京東想同時對幾萬小哥的實時數據進行匯總，同時結合線上用戶反饋，隨時進行分析出報表以供實時決策，比如重新規劃路線、臨時處理客戶投訴、動態改變送貨任務，這個頭疼的要求可能會把數據工程師逼瘋。

頭疼有幾點。

首先，邊收錢還要邊算賬很頭疼。傳統的資料庫，要不擅長交易操作，要不擅長分析操作。如果要求同時進行交易和分析（HTAP：Hybrid Transaction and Analytical Processing），需要資料庫同時支持在線交易處理（OLTP）和在線分析處理（OLAP），這就涉及到完全不同的資料庫架構和解決方案，兩者的整合不僅涉及姿態各異的軟硬體，工程浩大，而且造成不可避免的分析延遲，很難實現真正的混合式交易分析處理。

其次，要長得快還要長得齊很頭疼。結構嚴謹的關係型資料庫SQL保障交易強於分析，但需要事先實現定義好數據架構，靈活性差。典型場景是電商和網上銀行。結構靈活的NoSQL支持數據的快速增長，縮放自如，但交易和分析嚴謹性差。典型場景是社交網路和客戶管理。在用戶、產品、訂單、業務模式迅速靈活增長時又要求結構嚴謹，使資料庫選擇常常在SQL和NoSQL之間陷入兩難。

還有，要花錢少還要算得快很頭疼。隨著業務量的增長，企業如果有全局實時分析能力的需求，通常只能投資建造更強大的計算中心，購買更快的網路帶寬。

那麼，HarperDB這家剛剛成立8個月的初創公司拿來了什麼止疼片呢？

這個止疼片點就是一個新型的資料庫。啰嗦點說，是一個輕體、SQL／NoSQL兼容、無架構、跨平台、全索引的新型資料庫。它主要有仨絕活兒：

1. 「剁碎了」：

關係型資料庫依賴於事先定義好的表及表之間的關係；非關係型資料庫依賴於文檔或列數據。而HarperDB的基本結構既不是表，也不是列，而是剁碎成單個的數據單元，然後再通過索引保持這些單個數據之間的行、列、表間關係。

這就好像圖書館裡的書，既不按類別也不按作者首字母，而是按照入庫順序混亂地擺放在一起，然後依賴RFID索引到每一本書的具體位置。

或者說像亞馬遜收購的Kiva Systems庫房機器人，完全打亂固定貨架，每一個方形立柱貨架作為一個獨立的存貨單元，然後全面索引，需要哪個單元就由舉重機器人把那個單元抬過來。

在HarperDB自己的網站上是這樣展示的:

2. 「靠邊站」：

對比把數據集中到雲端用中央伺服器來運算的傳統方案，HarperDB致力於支持邊緣計算，這在物聯網的場景下既可能又必要。

依賴於中央伺服器來計算，就好像老師在黑板上演算100道題，20個小朋友坐在課堂里看著。邊緣計算能夠把計算負擔推到移動設備上，就好像老師把100道題分了一人5道大家一起算。

HarperDB的設計思路面向邊緣計算。設計意圖是讓企業不必動輒投資在計算中心，而是充分利用已經擁有的移動設備包括手機、筆記本、和嵌入式計算設備。

3. 「講普通話」：

分散式邊緣計算的一大挑戰是各地方言不通。特別是在OLTP／OLAP並重，SQL／NoSQL並存，各種緩存、插件紛繁複雜的情況下，這個矛盾尤其突出。好在從2000年Roy Fielding的博士論文開始，我們有了一種連接網路上不同平台的「普通話」，即REST或RESTful標準。為了保證HarperDB不為方言所困，HarperDB提供原生的REST API介面。

那好吧，這個有著三大藥效的止疼片聽著不錯。怎麼把這個止疼片包裝起來呢？

Node.js。

大家從HarperDB邊緣計算和面向物聯網的路子聽出來了，不管這個資料庫用什麼語言寫，對這個語言的要求和對女裝模特的要求是一樣的：輕體、混搭、流行。

而Node.js這個店小二就有這三個特點。

• 首先，輕體：Node.js在不工作的情況下幾乎不佔用資源；其次用Node.js寫的程序可以很小。HarperDB目前的發布整個軟體才65MB，甚至能夠部署到像Raspberry Pi這樣的單板機上。
• 其次，混搭：Node.js是跨平台的。HarperDB在第一版發布時就可以同步上映在各大影院上，包括Linux, Mac, ARM6, ARM7, 和ARM8上。
• 另外，流行：Node.js近年的盛行使得代碼包豐富，新人濟濟，幫HarperDB這樣的初創企業提高開發速度，降低招聘門檻。Node.js的程序包管理系統npm現在就有35萬個包，號稱「當前世界上最大的軟體包管理解決方案」。比如，HarperDB公司的CTO找到的async庫手到擒來地解決了HarperDB本來需要自己開發編程的問題。所以流行也是優點，只要不是感冒。當然，開源系統的風險在於，有些包的開發維護會因為開發者的個人原因而突然中斷，因此得優先選擇有大公司大組織站台的。

綜上三點，HarperDB選擇了Node.js作為糖衣包裝自己的止疼片兒。而Node.js也歡迎自己在新型資料庫上的應用，而且是目前在資料庫上的唯一應用。這就是為什麼微軟、IBM、英特爾、三星、紅帽在溫哥華歡迎谷歌入Node.js群，來了一條狗。

不開玩笑，Harper真的是一隻狗。它是創始人Stephen的愛犬。好了，發福利了：本文得到Stephen的許可，讓知乎成為Harper靚照的全球互聯網首發平台。

本文試圖從一個外行的視角來了解HarperDB和他們自己選用Node.js的理由，得到了CEO Stephen Goldberg和CTO Kyle Bernhardy的幫助。這是跟他們團隊的合影，右二是Stephen，左一是Kyle。韓裔為Fred Yoon，COO。女生為Kaylan Stock，戰略總監。

本文基於跟他們哥兒倆的聊天及查閱相關網站，尚未找到HarperDB應用實例的資料，也沒有來得及將其產品及技術和其它競品進行對比。

• 滿足物聯網邊緣計算、交易分析同步、縮放自如的資料庫還有哪些選擇？
• 有什麼需要轉告狗主人的表揚和批評？

懇請懂行知友在評論區留言以助學習冰山水下那一大坨。

參考資料：

Why Choose Node.js?

NoSQL and SQL Application Database

Hybrid transactional/analytical processing (HTAP)

Node.js Interactive North America 2017: Key Takeaways

(以上2017年11月14日原帖）

2017年11月15日更新：

收到HarperDB的創始人Stephen Goldberg對本文評論區 @王文武 同學批語的回復。懶得看英文的跳過引用塊中文見。

Rong,

Thanks again for posting the article! We had two downloads, and one contact last night as a result! I have used google translate to read several of the comments and they seem to be positive for the most part.

I noticed one person suggested Mongodb instead of HarperDB. MongoDB utilizes multimodel which means that resources must be duplicated in order to search. MongoDB also doesnt support full ANSI SQL, and it is much larger then 65mb so it cannot run directly on the edge.

SG

他昨晚收到（來自中國的）兩次下載和一次（電郵）聯繫。同時他藉助Google翻譯看了幾條評論大體是積極的。（按咱知乎磚頭墊拍兩用的風格，他應該過兩天再回來看看。）

他特別注意到一名讀者（是不是拿不準讀「王文武」還是「王斌」？）建議用MongoDB而不是HarperDB。他解釋說「MongoDB用的是多模型方法，需要重複佔用資源才能支持搜索。另外MongoDB不支持全套ANSI SQL，而且遠遠大於65MB所以沒法直接在邊緣上運行」。

更多回答，請看：張戎的回答

更多文章，請看：數據冰山