（本文由持友网络总裁助理何冠宇在IT168上撰写，由陆敏撰写）。
问题一：现在数据库市场百花齐放，时序数据库其实只是一个比较小的品类，如何定义时序数据库，是不是叫带时间标签的时序数据库？
时间序列数据是随时间推移不断生成的一系列数据，简单来说，就是时间戳数据。 时序数据库是存储和处理时序数据的系统。
通常，生成的时序数据量非常大，例如，只要设备在运行，它就会不断生成数据。 但是，时序数据中的每个数据点都不如关系型数据库丰富，而且大多数情况下数据对时间敏感度很高。 因此，时序数据库需要结合时序数据的特点，支持海量数据的引入、低成本的存储和高效的处理。
问题 2：时间序列数据是如何诞生的？在哪些行业会更有优势？
随着技术的发展，人们对事物的连续观察需求也越来越大，比如服务器的性能监测、锅炉的压力监测、体检时的心电图等，在这种背景下，提出了对时间序列数据进行存储和处理优化的技术，最后产生了时间序列数据库系统。
时序数据库在很多行业都有广泛的应用，时序数据库理论上在各行各业都有应用场景，但我们认为，在制造业、金融业、电力、交通运输等行业，已经形成了丰富的应用场景，具有应用优势。 这些行业已经有很多应用，建立在时序数据库的存储和计算能力之上，在可视化、分析、决策控制等方面为企业提供了丰富的解决方案。
问题3：您如何看待时序数据库的发展趋势，这些趋势的布局是什么？例如，生态、人才、开源。
时序数据库负责处理时序数据的引入、存储、查询、分析和计算功能。 目前，纵观时序数据库，分布式和集群化是企业的主流需求。 分布式时序数据库是一种以分布式方式将数据存储在多个节点上的技术，每个节点都可以独立处理数据查询和写入请求。 集群时序数据库是一种将多个节点组织在一起处理数据请求的技术，这种架构模式可以提供更高的数据吞吐量和更强的数据处理能力。 最近，一些公司提出了模态数据库的概念，它支持在一个数据库系统接口下集成多个数据库引擎，还有一些公司提出了超融合架构，总体上解决了一个类似的问题，即丰富了时序数据库的数据类型，支持更广泛的场景。 随着云原生技术的发展，我们看到时序数据库和容器技术的结合越来越紧密。
对于时序数据库的开发，我们有自己的发展方向，结合自身的业务需求。 边缘方案是我们支持的第一个方案，因此我们重点关注以下技术：
实时+高吞吐：创新的存储引擎支持高吞吐数据引入，同时满足高并发实时数据引入需求，简化数据引入架构
多维度数据计算与分析：类SQL的DSL，结合分布式内存计算技术，支持多业务数据观察，满足可视化分析需求
灵活的数据发布：支持直播数据与磁盘数据相结合的数据发布，以DSL方式描述数据发布规则，支持流式和事件驱动模式的数据发布。
低资源消耗：适合部署在车间、工厂等资源有限的环境中，不断提高数据压缩比，降低存储成本，优化内存布局，降低内存消耗，提高计算效率，降低CPU开销。
多中心架构：支持多中心数据实时同步，满足端、边、云协同的数据协同需求。
问题4：除了技术，在其他方面，比如生态、人才、开源，你对国产时序数据库的发展有什么建议吗？
数据库涉及核心人才在系统开发、存储、查询、分发、计算等方面的需求，企业往往难以具备自己的能力，尤其是与外部合作。 用友与清华大学等高校合作，解决时序数据库关键技术难题。 在开源方面，用友时序数据库的很大一部分也是开源的，同时也为开源做出了贡献，很多工作成果也进入了一些开源产品。 在服务生态方面，我们的技术提供一站式多场景、多范式的计算支撑能力，简化了使用方式，降低了生态产品在使用我们的产品时的技术开销。
国产时序数据库的开发要结合应用场景，不建议把时序数据库的边界拓得太宽，但还是要着力解决时序数据库的关键问题。 时序数据库的标准尚未完全形成行业标准，不同数据库的查询语言和处理能力也不同。
问题5：目前时序数据库市场规模如何？
如今，随着越来越多的设备连接，时序数据库变得越来越重要。 从看到的一些情况来看，包括传感器设备的接入，整个数据的价值正面临着千亿生态的市场，但时序数据库市场非常分散，竞争尤为激烈，而且很多数据库和场景的结合并没有那么紧密，所以培育作为一个独立市场的机会才刚刚开始。
问题6：你认为时序数据库有技术路线吗？例如，如果你是完全自研的，比如说，架构中的技术路线是什么？
自研不是自研，这不是技术路线，而是我们数据库开发选择的模式。 但是，不同的数据库可能具有不同的路径。 如前所述，有超融合数据库、多模态数据库以及一些与流计算相结合的数据库。
用友时序数据库的技术路线选择了多计算范式融合的技术路线，即支持将多种计算范式集成在一个数据库中，如流计算、事件驱动、多维查询分析等。
我们选择的技术路线主要是在时序数据库计算和处理的核心技术上取得突破。 这是由于我们服务的核心市场。 我们服务的北向产品主要包括MES系统、ERP系统、资产管理系统、设备维护系统，我们的应用直接服务于工厂和车间系统，核心需求是端边协同。 应用需要与物理系统连接，面对设备量大、时间数据的时效性要求，这些系统的计算范式都是被动的，而一般报表、仪表盘等系统对于计算范式的功能输出是不同的。
问题7：请简单介绍一下用友时序数据库。
时序数据库是针对时间戳或时序数据进行优化的数据库。 例如，为了管理好工业设备，工业企业需要使用传感器来采集一些带有时间戳的数据，这既需要“瞬时写入超大规模数据”，也需要无序管理。 时序数据库的技术发展与上层应用密切相关，上游应用的需求对现阶段时序数据库的发展具有非常大的牵引作用。 作为领先的企业服务商，为了满足工业企业多场景、高性能、高可用的需求，用友开发了timensiondb时序数据库，具备存储引擎、查询引擎、流式计算引擎、消息引擎四大核心能力，高效释放数据价值。 更懂企业业务的用友TimensionDB时序数据库，得到了众多行业龙头企业的认可。
Q8：用友时序数据库在产品性能方面有哪些优势？
海量数据的采集、存储、查询一直是数据库的难点，用友时序数据库能够实现高性能的数据读写，并能实时分析数据，快速处理海量数据，具有五大核心优势。
1.高写入性能。
基于两阶段LSM合并的TLSM算法，有效保证了单机在任何情况下都能轻松实现每秒1000万个数据点的高速写入能力，实现百万级智能物联网设备的接入和高速写入。
2.硬件成本低。
TSFILE存储格式是专门为时序数据设计和优化的，支持Snappy、LZ4、GZIP、SDT等多种数据类型和相应的压缩算法，可以达到1：150甚至更高的压缩比。 使用高压缩比的硬盘存储，存储 10 亿个数据点的成本将低于 14元，大大降低了硬件成本。
3.查询速度快。
用友时序数据查询引擎采用列式存储、预计算、索引技术，可有效减少数据查询过程中读取的数据量，大幅减少磁盘IO数量，轻松实现对10亿数据量、千万级数据点查询的毫秒级响应。
4、较强的分析能力。
基于用友深厚的行业知识积累，分析引擎自主研发高性能多维度分析引擎和分析DSL，提供便捷的维度管理和分析脚本管理能力简洁的 DSL 语法使零基础人员能够轻松对业务数据进行复杂的多维度分析。
5.扩展性好。
弹性伸缩采用大规模并行处理（MPP）架构和火山模型进行数据处理，可扩展性高，支持秒级添加节点，无需数据迁移，适配不同规模时序数据的存储和分析需求。
问题 9：当您面对客户时，他们在选择时序数据库时关注哪些指标？为什么？
用友所服务的钢铁行业龙头企业也是一家跨国企业，对数据的可靠性和稳定性提出了更高的要求，不能容忍维护中的停机和数据丢失，对产品的可用性要求很高。 也有一些客户的系统与生产执行密切相关，对数据抖动和延迟要求很高，不希望因压力过大而影响数据存储。 此外，客户还会对内存、IO、CPU等提出一些具体要求，以确保在客户的工厂、车间等环境中稳定运行。 为了管理核心制造的高效稳定执行，一些工业企业既需要“瞬时写入超大规模数据”，又需要乱序管理。 为满足工业企业多场景、高性能、高可用的需求，用友时序数据库具备存储引擎、查询引擎、流式计算引擎、消息引擎四大核心能力，以及四大超级引擎，高效释放数据价值。
存储引擎实现高压缩比、低成本存储，支持单机每秒高速写入1000万个数据点，实现1：150的高压缩比，10亿个数据点的硬盘成本不到14元;
查询引擎提供丰富的时序查询语义、时序数据特征的计算、丰富的时间维度聚合函数支持，实现十亿数据量、千万级数据点的查询毫秒级响应同时支持切片计算、四规则操作、周期性桶聚合等操作，基于专用的多线程、多维计算算法，充分利用服务器的硬件资源，提高计算速度。
TimensionDB提供的流式计算引擎，在未来可以很好地兼容流式SQL标准。
消息引擎提供行业标准的消息队列能力，能够根据业务规则快速将时序数据发布到消息队列中，进行消费和处理，满足复杂业务场景的集成需求。
Q10：客户在选择时序数据库时需要做哪些准备？有什么建议吗？
对于时序数据库的选择，主要不是选择时序数据库，而是看上游应用，而时序数据库市场是由上游应用决定的。 由于不同时序数据库的特点和应用场景不同，上层应用的需求和场景也不同，因此时序数据库的选择需要我们结合具体的业务需求，考虑以下因素：数据模型、查询语言、可靠性、性能、生态、技术支持
数据模型一般有两种类型：一种是没有架构和多个标签的模型，另一种是名称、时间戳和值。 前者适用于多值模型，更适合于复杂的商业模式后者更适合一维数据模型，这正是TimensionDB的本质。
大多数查询语言目前都支持基于 SQL 的查询当然，除了类SQL查询外，TimensionDB还具有向量计算能力，可以使用简洁的DSL语法来编写复杂的业务处理逻辑。
可靠性、可靠性主要体现在系统的稳定和高可用，以及数据存储的高可用性。 一个好的系统应该有一个优雅且高度可用的架构设计。 简单而稳定。
当用户开始考虑时序数据库时，一个很大的原因是通用关系型数据库在读写性能方面无法满足业务需求。
生态，一个时间序列数据库产品不能解决所有问题，用友时间序列数据库和用友的人工智能系统、数据中台系统可以很好地融合。 我们需要构建一个多中心架构，可以更好地与其他数据平台集成，让其他数据平台能够协同，发挥更大的能力。
技术支持，一个系统背后的支持公司也更为重要。 背后有一个强大的公司或组织，在项目可用性保证和维护后更新方面将拥有更多的经验。