阅读笔记：How ShiftLeft Uses PostgreSQL Extension TimescaleDB - High Scalability

https://blog.shiftleft.io/time-series-at-shiftleft-e1f98196909b

ShiftLeft是一个安全公司，公司会涉及到大量的关于时间序列数据。所以对时间序列的数据库做了一个选型，选型策略如下：

最好使用go语言写的，因为ShiftLeft公司的大部分产品的开发语言都是GO
需要很好的能够适合Docker这个生态链，因为当前的大部分产品都使用到了Docker的方案。
需要能够很好的支持迭代开发，不能过于依赖一种数据模型，因为经常会有需求更改。（感觉这个跟自己开发有关系啊，跟系统选型没关系，放在这里有些奇怪呢）
一个创业公司能够维护的了的系统，特别复杂的就算了，公司没有几个人。
不同类的粒度的序列支持。Retention management（没翻译出来啥意思，但是感觉还挺关键的）

最后选择了基于PostgreSQL的TimescaleDB，这款数据库是作为PostgreSQL的一个扩展，提供了一个叫Hypertables的超级表，估计是增强了一下PostgreSQL强大的分区表的功能，让分区根据时间段进行划分，查询的时候根据时间来筛选chunk，会省掉大部分无用的磁盘IO。我猜测选型的过程还是为了最大限度的保持技术栈一致，因为公司的其他业务也都大量的使用了PostgreSQL。不过对于TimescaleDB来说，在时间序列业内也算是首屈一指了，就算是没有技术栈的考虑，选择它也是没有问题的。

整个数据采集系统的架构非常典型，前端API接口接受应用上报数据，然后发送给Kafka（订阅模式），在Kafka的后端进行数据聚合，分批次写入数据库，间隔有2秒的，有1分钟的，还有5分钟，还有更长的1个小时和1天的。1个小时以上的都认为是大粒度的任务，做了特殊的设计，即大粒度分解成小粒度，然后汇总成大粒度的数据。

ShiftLeft定义了两种类型的采集事件，一种是应用上报的指标类数据，另一种实际上也是应用上报的数据，但是跟安全相关的信息，对这类信息进行了特殊的处理。

上报消息中的关键字段：时间戳，消息计数，对于安全类消息的话，包含一些请求消息的一些细节数据，这些数据都是以JSONB的格式存放，这里非常赞一下PostgreSQL对JSONB的支持，一个私有key（叫SP ID），用来标识版本。

在系统运行的过程中，曾经发生过一次性能问题，查询过程中Plan的节点竟然花掉了17秒，但执行阶段只用了250毫秒，这个有点吓人，不过还好的是，这个问题已经被数据库方面修复了。文章中给了一个链接关于这次问题的分析，很有兴趣找机会再翻译一下。

接下来就是任何完整系统都逃不过的系统监控了，我们最近也在选型这个部分。

ShiftLeft其他业务用的数据库也是PostgreSQL，所以用的PGHero来做的数据库请求的监控（https://pghero.dokkuapp.com/datakick，他们一开始想用pg自己的pg_stat_statements这个表的功能来做监控数据，但是发现不合适，人家这个表是看某一个消息处理延迟的，而ShiftLeft的延迟大多是因为大量的消息导致的，单纯每一个消息看的话，都很快。这部分上报数据实际上也都是时间序列的数据，那么最合适的监控和分析工具就是Prometheus（今天看到这个工具好几次了，有缘分啊），我们可以观察他的数据库写入和延迟情况（美图就不贴了）。除了上面的时间序列的监控，还用到了一个PostgreSQL的关于Grafana（哇塞，又看见了一次他）的扩展http://docs.grafana.org/features/datasources/postgres/

接下来要做的事情：
1. 优化一下Timescale那个Hypertables的chunk size
2. 希望加入一个流复制的备节点，这样对于查询可以有一些性能的扩容
3. ShiftLeft现在还处在PostgreSQL9.6版本，计划升级到11版本，因为11版本使用了JIT，性能会有很大的提升。
4. ShiftLeft之前只是对PostgreSQL内部的事务处理做了很多的关注，接下来对于一个消息在API层的处理延迟要进行分析。

希望：
希望未来TimescaleDB能够支持RDS版本，因为ShiftLeft其他业务用的PostgreSQL都已经上云了。

总结：
TimescaleDB是我今年去美国参加新泽西的Postgresql用户大会的时候第一次听见的，也看见了公司的一些开发者，感觉还蛮有朝气的。虽然公司规模不大，但是推广的粒度还挺猛的，后来的一些会议都有这个公司的参与和赞助。
也就是在这次用户大会才了解到了时间序列数据库，想象了一下应用场景，确实还挺多的，特别适合IOT场景，我以前还在想，以后这个世界未来那么多的智能设备，如果每时每刻都要上报数据，那得需要啥样的数据库才能处理的来。

现在好像好多的公司的新的系统开发语言都是选择了GO，这个趋势好明显，我的大Python虽然红红火火，但是命运也是尴尬的，只能集中在运维和大数据分析领域了。GO的2.0出来，解决了错误处理的诟病之后，说不定会火的不得了了。