微软、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的公司（来源：lullabot.com）

因为Node.js依赖于谷歌的V8 Javascript引擎，所以这次在温哥华谷歌能成为白金会员，对于整个Node.js社区都是个积极的消息。（参考：Node.js Foundation welcomes Google as Platinum Member）

有趣的是，在会议上设立展台的除了几大白金会员公司和利用Node.js搞托管、包裹管理、安全、云计算的相关公司以外，还有一条狗，这是为什么呢？

丹佛初创公司HarperDB的图标（来源：HarperDB.io）

这条狗是丹佛初创公司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库房机器人，完全打乱固定货架，每一个方形立柱货架作为一个独立的存货单元，然后全面索引，需要哪个单元就由举重机器人把那个单元抬过来。

亚马逊库房机器人系统把货架剁碎成单个方形立柱货架。来源：NPR

在HarperDB自己的网站上是这样展示的:

最右侧的数据单元就是剁碎了的数据库。来源：harperdb.io

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创始人Stephen Goldberg的爱犬Harper本尊。Stephen Goldberg授权使用。

本文试图从一个外行的视角来了解HarperDB和他们自己选用Node.js的理由，得到了CEO Stephen Goldberg和CTO Kyle Bernhardy的帮助。这是跟他们团队的合影，右二是Stephen，左一是Kyle。韩裔为Fred Yoon，COO。女生为Kaylan Stock，战略总监。

2017年11月10日跟HarperDB「狗仔队」在丹佛共享办公楼SPACES

本文基于跟他们哥儿俩的聊天及查阅相关网站，尚未找到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 doesn&＃8217;t 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所以没法直接在边缘上运行」。

更多回答，请看：张戎的回答

更多文章，请看：数据冰山