开源时序数据库支持快速数据获取和快速sql查询
开源时序数据库，支持高吞吐数据获取和快速SQL查询，使用Java和C编写，没有任何外部依赖，可应用于实时分析、数据仪表板、基础设施监控、传感器数据等场景。QuestDB兼容InfluxDB行协议、PostgreSQL线路协议，提供RESTAPI以便于批量导入和导出，QuestDB使用ANSISQL，包含时间导向的SQL语义，这些SQL语义更简单地连接不同来源的关联数据和时间序列数据。
Spring的切片能力可以方便的实现该需求。对接口的性能监测原理上就是用调用结束的时间减去进入的时间点计算总耗时，并把这个耗时记录下来，以便时候筛查。在不存在慢查询的时候，接口性能可能也会不满足要求，可能的原因如，一个接口循环调用了1000次数据库操作，或者调用了一些第三方接口等。接口性能更接近于用户体验，因为多数时候用户的一个操作动作会对应一个服务接口。
接口性能监控——后台系统通常是通过服务接口向外提供服务的，前端页面或者移动设备是通过调用服务端接口来完成对应操作的。非统计类的数据操作通常应该在100ms以下。可以通过手动或自动分析慢查询日志，筛查可能存在的性能问题，主流数据库都支持慢查询日志生成，具体的配置方式此处不做赘述。数据库慢查询日志——是一个重要的监控途径，其中记录了耗时较长的数据库操作记录。实践中我们需要一些日常机制来筛查系统性能问题，避免病入膏肓。
常见的性能问题，往往是欠缺性能考虑引起的，响应巨慢的同时，硬件利用率可能5%不到，这类问题也是此次锅叔主要讨论的。然后，如果你开发的系统在把硬件跑到瓶颈之前都快如闪电，请收下锅叔的膝盖-_-||。首先，系统慢用户未必会告诉你，如果比你的竞品慢太多，用户会用脚投票。我们有服务器监控啊，如果cpu，或者内存满了，会有监控报警啊？不就是系统慢么，用户会告诉我们啊？这么说可能经验欠缺的同学难于理解。
而对这些问题的优化解决，以及监测，往往需要比开发具体功能，更高更全面的技术素质及能力。随着用户增多，业务数据增多，那系统一定会暴露一些性能问题，如果有越来越多的人，持续使用。现实情况是，如果你这个系统，业务没有做起来，没啥人用，huan则罢liao，你是否会感觉志得意满，到达了人生巅峰，高唱无敌是多么寂寞。当经历了无数的日日夜夜，朝九晚九，攻克了无数难关，终于将系统预定功能开发完成，通过测试，部署上线后。
