给我的感觉Db2 Event Store是一个私有的InfluxDB IOX，只不过没有InfluxDB IOX功能那么强大而已，其在写入流程，COS的利用，存储格式，以及架构上给我的感觉是后者好像也可以这么实现，只不过后者计算节点可以不挂盘，且控制面更为强大而已

线上负载要求写入和实时查询高性能，时序数据库+缓存（内存时序数据库）可行。

通用的时序数据库BenchMark是一个看似简单，实则极具挑战的问题。

云原生时序数据库目前来看还是一个没有行业标准架构特殊数据库分支，各大云厂商都有自己的集群化实现，从谷歌的Monarch，阿里的Lindorm，腾讯的CTSDB，到垂直领域的InfluxDB IOX，TDengine，IotDB，都是各有的特点和适合的领域。终究不存在银弹，强如各大头部厂商也只是在做Trade off...

Monarch这篇文章的重点不在于In-Memory的存储引擎，而在于其新颖的数据模型，路由方式，查询下推和FHI，其中提出的不少点值得学习。

最近正在研究InfluxDB1.8的series file实现，竟发现其中大量使用mmap，这和我的固有认知有非常大的差异。

边缘设备（时序数据的产生点）边缘服务器中需要一个用于写入，存储和查询的数据库云端的计算集群，用于OLAP分析不断变化的模式，即对于SchemaLess的支持（传感器经常被替换，移除，新增）周期性的数据采集强相关的series（利用2，3可以增加压缩的可能性）多样化延迟数据的写入高并发的数据写入一天之内10万数据点的selection在100ms三年之内1000万数据点的aggregation在100ms。

在另外一个系统之上建立一层多租户层，尤其是当底层系统是偏向于分析型场景时，因为此时一个RPC请求的资源消耗基本无法准确预测，此时请求本身无法作为隔离指标，遂需要在其他维度解决这个问题。

不同介质导致的瓶颈使得数据存储格式的决策有很大的优化空间，主内存列存储和磁盘列存储之间存在根本差异。

所以核心要解决的问题是：在云环境Serverless的环境中，运营商如何在保证成本效益的情况下向用户提供一系列有意义的保障。