写在前面
本文主要是从学术而非商业数据库实践的角度来介绍分布式DBMS H-Store。H-Store是由Brown，MIT，CMU联合开发并在MIT的实验室成功部署实现的。
H-Store的研究者对外界公布的关于H-Store的论文主要是以下两篇：
The end of an architectural era, VLDB’07
H-Store: A High-Performance, Distributed Main Memory Transaction Processing System, PVLDB’08
其中第一篇是在分析和总结了面向磁盘数据库管理系统的种种弊端，从架构设计这一角度，高屋建瓴地提出了DBMS面临改革的必须，而引出了可能的新型内存数据库系统的设计，也成为了H-Store的原型；在第二篇文章中，研究者在前一个工作的基础上，对H-Store的设计做了更清晰的描述，每一部分的功能也更加具体化了，进而成为广受学术界欢迎和使用的关系数据库管理系统。顺带一提，H-Store有一个商业化的版本，叫做voltDB。
本文是结合第二篇论文来进行讲解的，因此篇幅也会比较短。如果想阅读更多关于H-Store的内容，欢迎阅读官方的介绍和源码：
背景介绍
在H-Store, voltDB, Redis等一系列内存数据库管理系统问世以前，主流的DBMS是基于R系统1的，因此如H-Store研究者所言，因其太过“通用和广泛”，在性能上存在极大地瓶颈。尤其是对于TPC-C2这一类事务具有高度重复性及短寿性的benchmark来说，执行开销眼中，可用组件被多余的组件掣肘，不能发挥全部的功效。研究者认为，必须通过横向扩展系统，分割事务及处理职能给多个无共享架构（shared-nothing architecture）3的主机节点，才能有效提高DBMS的性能。
另外，面向数据库的DBMS存在着严重的IO开销，尤其是对于并发控制来说，锁机制会导致high skew（即事务多次重复访问相同部分的数据）下性能受阻。
因此，H-Store被开发为一个分布式的内存数据库系统。
系统概述
H-Store的系统设计架构如上图所示。
先列出几个H-Store的术语名词：
- H-Store实例(instance): 由同一管理域部署的H-Store节点的集合；
- H-Store节点(node)：一个部署了一个或多个H-Store站点的单机系统；
- H-Store站点(site)：基本的操作实体，在多处理器系统中，通常一个处理器负责一个站点，它是一个单线程的守护进程，连接到外部的应用
每一个站点与其他站点（无论是否在同一主机节点上）都是相互独立的，既不共享数据结构也不共享内存。
数据库中每一个关系（relation）都被划分为一个或多个子集（partition），（由administrator控制管理）分布在多个站点中，形成replica集合。这就是说，一个relation可能分布在好几个不同的站点上（k≤N），这就提高了整个DBMS的可靠性，因为它能容许k次单站点故障。
由图1可以看出，H-Store的整个框架可以分为部署时和运行时两个部分。部署部分是在运行transaction之前就已经执行的。H-Store提供了一个带有cluster部署框架的管理器，它将存储程序、数据库schema、采样负载和cluster中的可靠站点作为输入，输出一系列用来引用运行时程序的独特的调用句柄。
此处值得注意的是，存储程序是H-Store设计者为了更高效执行transaction而采取的特殊手段。简单理解的话，可以把存储程序当做transaction本身。当一个transaction来临时，H-Store不是针对transaction本身去运行，而是执行transaction唤醒的存储程序，从而使得执行效率得到提高。
部署部分使用了两个阶段的query优化，具体细节我没有读，应该在第一篇论文里提及了。
运行时部分相对来讲更容易解释一些，OLTP应用与H-Store实例进行交互，通过API传入transaction。无论transaction所需要的数据是否在交互站点上，该站点都可以执行OLTP应用。比如OLTP应用随机地选择站点1进行交互，要求执行任务，但是transaction请求的数据大部分不在站点1，而是分布在站点2，3及5。这个时候，站点1就会与2、3、5进行通信，传达transaction任务。当transaction执行完毕后，各个站点会回送完成或失败信号给站点1，站点1再与应用交互。
数据库特性
与面向磁盘的数据库相仿，分布式内存数据库的性能也依赖于数据放置策略和物理数据库设计的支撑数据结构。但是由于OLTP的transaction具有高重复性，单任务短暂性的特点，可以对整个设计进行优化。
Transaction分类
- 单站点transaction： 包含的所有的queries可以由H-Store cluster中的一个站点来执行；
- One-shot transaction：所包含的queries不能由一个站点来执行完毕，但其中每个query都可以由一个站点来执行（说明该query所请求的数据全部在同一个站点上）
对于以上两种类型的OLTP Transaction，H-Store选择的优化方案是将transaction或者query交由特定的站点来执行，最小化节点之间的通信，从而提高系统性能。
容错与负载
由于H-Store不在磁盘上存储任何（数据库）数据，它就必须依赖一种数据分布策略来保证可靠性。它采用的是k-安全策略，这一点我们在前述部分已经讲过，即是将相同的partition分布在k个不同的站点上，这样当其中k-1个站点故障时，该partition的数据仍然可以使用。
另一方面，由于某些数据的访问频度较高，也就是存储该数据的站点访问频度也会随之增高。这可能会造成H-Store各节点工作负载不均衡的情况。一旦负载不均衡的情形超出控制器的监视指标，则H-Store的管理器需要对各partition的数据进行调整和分配。
总结与思考
H-Store是一个比较老的内存数据库系统，但是无论在今天还是今后的研究中，它都对我们具有十分重要的价值。无论是它本身分布式设计的理念，内存数据库分割数据，可靠性保证的方法，还是研究者在后来几年基于它所设计的Anti-Caching系统，都非常具有启发性。
我目前想做的是围绕H-Store系统，结合非易失内存NVM，针对数据logging和可靠性保证做出一点新意。结合上次的NVWAL，也许H-Store在修改的地方与SQLite会有较大的不同，这也是我可以插上一手展现自己创新工作的点。