EventStore的选型

在enode中，因为针对事件幂等操作做了实现，导致要依赖存储特定的能力（数据库唯一索引约束）

针对这个限制，EventStore的选型会有比较多的限制，目前仅仅支持一些关系型数据库（MySQL，Postgresql），MongoDB可以支持主要原因也是因为高版本支持了事务能力。

这个能力其实也是enode提供的核心能力，为了保证命令消费的幂等性，这点必不可少。同时为了写入性能的考量，通过uk的方式远比写入前查询下是否存在高效的多

我常常想把HBase应用在EventStore中，主要得益于HBase海量存储的能力，但仔细思考了一番，HBase其实不太适合做为enode中的EventStore，主要原因有以下几点：

• EventStore中存储的是业务数据，可以认为是很关键的数据，主流观点认为业务数据放在HBase不如放在MySQL中可靠（待求证）
• HBase写入数据的思想是一直append，所以并不会关心append的前一个位置是什么数据，如果要做唯一性校验，只能通过先查再插，或者直接插入（upsert多版本）
• enode中会有写入后立马读的场景，HBase是写入一条数据时，为了写入的性能，其实不是立马刷盘的，这样的话在读己之写这种场景就会出现实际已经写入，但没有读到的问题