你是否也遇到过这样的问题？
在设计和实现监控系统时，因为在数据存储上过于依赖 Kafka、Spark 和 HBase 等大数据组件，导致大数据处理链路越来越长，不仅运维和使用成本越来越高，系统的可靠性保障也出现了更多的挑战。一旦监控系统本身出现漏洞，业务系统存在的问题便将难以定位，进而就可能会造成巨大的实际业务损失。
此前顺丰科技便被以上问题所困扰，他们使用 OpenTSDB 作为全量监控数据存储方案，不仅运维和使用成本很高，性能上也越来越难以满足需求——日常大跨度和高频次查询方面已经无法满足当前业务发展的需求，查询返回结果甚至需要十几秒。此外，随着用户量的增加，支持较低 QPS 的 OpenTSDB 非常容易崩溃，一旦崩溃将导致整个服务都变为不可用状态。
顺丰科技并不是独一例，睿信物联网平台同样遭遇了此类问题。为了解决这个问题，两家企业都开始重新进行数据库选型，但为什么最终它们都选择了 TDengine Database？TDengine 又带给了它们哪些改变？
以顺丰科技为例，他们分别调研了 IoTDB、Druid、ClickHouse、TDengine 等几大市面流行的支持时序数据处理的产品。
在调研时发现，单机性能不错的 IoTDB 尚不支持集群模式，单机模式在容灾和扩展方面无法满足需求；性能强大的 Druid 却过于依赖 ZooKeeper 和 Hadoop 作为深度存储，整体复杂度较高；性能算是最好的 ClickHouse 却由于运维成本太高扩展特别复杂。最终，性能、成本、运维难度都满足且支持横向扩展的 TDengine 脱颖而出，成为了顺丰科技的最佳选项。
改造成功后，顺丰科技智慧物流服务系统发生了四个显著变化：
- 在稳定性方面，大数据监控平台摆脱了对大数据组件的依赖，有效缩短了数据处理链路
- 在写入方面，理想情况下集群写入速度最高能达到 90w 条/s
- 在查询方面，在使用预计算函数情况下，查询 p99 都在 0.7 秒以内
- 在成本方面，服务端物理机由 21 台降至 3 台
无独有偶，睿信物联网平台也收获了这些惊喜效果，但是他们还遇到了一个问题，就是如何将历史数据顺利迁移，为此他们还自发做了一个迁移工具。
为了更加方便企业从 OpenTSDB等产品顺利迁移至 TDengine，TDengine 研发团队专门开发了解决方案。
今天的公开课分成了：
如上这三部分来多角度、全方位解读TDengine Database的核心功能与最佳迁移路径。
