复杂系统的质量并非一蹴而就，而是遵循客观事实逐步演进的，稳定产品的测试最佳实践唯有Early、Continuous。

一个稳定的binlog可以带来无限的可能性，异地复制，PITR，流计算，构建稳定副本，存算分离等等

在希望提供更强工程能力的计算引擎这点来看，项目开发之初接入Velox是正确的，此时最大的风险在于接入Velox最大的问题在于将自己的身家性命与快速迭代的可能交给了Velox和它的扩展API，当Velox无法支持时必要特性时就麻烦了。 如果项目开发已经有段时间，此时愿意放弃自己团队已经投入很久的实现，而完全去使用Velox的c++实现作为单机runtime需要团队有一定的魄力，其次需要技术视野清晰，明确替换后的优势，一定需要ROI确定后再动手。

使用开源的执行引擎，所有玩家都将具备同 Snowflake 十年前独有的相同向量化执行能力，当存储层对每个人来说都是相同时（云盘/对象存储），区分 DBMS 产品的关键因素将会是那些难以量化的事物，比如稳定性，UI/UX 设计，查询优化等。好在并不是所有人存储层都一致，这意味着我们可以基于不同的场景设计不同的存储引擎，针对不同场景的存储引擎插件化以及智能化引擎参数调优，并佐以智能索引构建，cache等外部能力建设有竞争力的产品。

所以事实上show series返回的真正顺序遵循以下规则： 1. 以measurement name排序 2. 每个measuremnet基于serieskey内部的tag本身做排序

现有的时序数据库只是实现了窗口仅为时间，无状态的，且非DAG的简化批处理系统，想以此替代流系统的全部份额基本不太现实，但是确实可以拿下其中部分收益，领域垂直公司需要故事去活下去，但是公有云需要关注业务上真正需要解决的问题，可见的未来我们的精力不会投入到完善时序的流计算系统中去。

结论1：基于统一kv/宽表底座的多模型数据库是错误的方向，只有不同模型拥有不同的存储引擎才可以带来最大的综合性能优势 结论2：哪怕是最优秀的存储引擎也只是在Trade-off，没有一种设计可以保证所有情况下的最优，所以需要智能化调优，并在项目选型之初选择最适合业务场景的引擎。 结论3：完全独立的多个不同模型数据库对于联合分析的场景性能较差

工程不是学术，对于一个新结构我们最关心的是这个特性的普适程度以及各种负载下的稳定性

1. 读写差异巨大，读写的SLI设定应该分离，而且写入偶尔的失败是可预料的，频繁的告警没有意义 2. 数据库内的写可能只是链路的一部分，我们希望跟踪全链路的写入指标 3. 时间范围不同的查询告警指标的设定应该不是一致的 4. 我们希望通过session做服务降级，也希望更好的理解业务层面的SLI，单独的查询分析不能cover这一场景

好好工作，好好吃饭，好好睡觉，好好处对象