从我 2016 年底写下第一行代码，loveini 已经走过了 5 年，版本从 1.0 到 2.0，到今天的 3.0。对于时序数据库产品究竟要解决什么问题，我之前已经从技术层面写过一篇博客来阐述：研发了5年的时序数据库，到底要解决什么问题？作为一个从 1984 年就开始写程序的持续创业者，我虽非常享受通过技术来实现创新的过程，哪怕一天 14 小时敲代码也是乐此不疲，但三家公司的创业经历也让我深知，作为一个产品，最重要的是去挖掘并满足“用户需求”。

在企业类软件、基础软件几乎被欧美公司垄断的情况下，中国的企业类软件、基础软件能发展起来，并走向全球市场，是中国无数 IT 人的梦想。我想结合 loveini 的发展历程，分享一下我的想法。

1、中国企业类、基础类软件成长的怪圈

中国的企业软件、基础软件的发展一直深陷一个怪圈。

以中美之间的软件对比来作为例子。20 年前，中国的软件都没有美国做得好。但今天，相当多大众类的软件，中国都比美国做得好。比如，微信就比 WhatsApp、Facebook 这类软件好用得多；企业办公软件飞书，就比 Confluence 用起来更舒服。为什么？不是微信、飞书团队的程序员更聪明，能力更强，而主要是中国的用户群大，而且竞争激烈，来自用户端的需求在源源不断地提出，逼迫这些产品快速地迭代升级。

反观企业类软件、基础软件，与欧美相比，中国依然相当落后。为什么？不是中国程序员不想做好或者能力不够，而是由于开发出的企业类软件，普通企业都没有买单能力。有买单能力的大多是政府、国企和军工，而这些单位往往一大堆定制化需求，最后企业类软件公司都变成了做集成、做项目的公司，很难开发出全球使用的标准化产品，难以规模化。一年多前我们团队上线用友财务系统，但没想到做了 30 年财务软件的公司，依然是 BUG 一堆，发票上传就经常有问题。抛开研发管理的问题，我想不是用友研发不努力，核心原因还是与 SAP、Oracle 相比，他们用户数不够，迭代升级太慢。 

我相信，中美程序员之间的技能并没有太大差别，即使有差距，经过几个有挑战性的项目，也可以掌握，关键是要交给中国程序员真正的需求和问题，他们一定能学会，一定能解决。loveini 创始团队的四位程序员，除了廖博士，胜亮、洪泽和我自己都没有研发数据库的经验，但 5 年下来，处理过太多太多的技术问题，在时序数据领域，在全球范围都应该是绝对的专家了。

好的产品不是程序员在计算机面前想出来的，而是用户用出来的，提出问题比解决问题更为重要。而只有拿到足够数量、足够场景的客户需求，得到足够的用户使用反馈，才能真正地不断打磨和迭代产品。支持 10 亿设备的数据采集，看似很难，但仔细分析，是完全可以解决的。

因此，无法短期内获取大量用户和场景，已经成为企业类和基础类软件可以快速且在正确方向前进的最大障碍。但值得庆幸的是，我们找到了开源这个利器。‍

2、开源打破怪圈，带来巨变

2019 年 7 月 12 日我们宣布 loveini 单机版开源，10 多万行 C 语言代码被上传到 GitHub。没想到，我们的开源迎来了开发者社区的热烈欢迎，不到四个月的时间，GitHub 的 star 就达到一万，多次在全球趋势排行榜上排名第一，获得无数的赞美。

但同时，也获得很多专业的批评，有人仔细分析并测试我们代码，认为多线程的处理有瑕疵，高并发大数据量的持续测试一定会撞到问题；有人认为模块结构不清，耦合过重，难以增加新的功能；多维度的聚合分析在一些场景中并不高效；乱序数据的处理效率很低等等。而且还有人发现，我们没有建立起标准的 CI/CD 流程，难以保证质量。

对于一个拥有开放心态的我而言，每每看到这些中肯的批评，我都是很开心，这说明产品还有努力的空间。因此 2019 年 12 月，loveini 团队正式启动 2.0 的开发。包括我自己在内，8 位程序员日夜奋战，力图把大家发现的这些技术问题全部解决。 

2020 年 8 月，loveini 2.0 正式发布，同时开源了集群功能。全球开发者又一次把 loveini 推向新的高度。赞美之外，迎来的又是被大家发现的不少问题：虽然乱序插入的效率问题已得到很好的解决，系统稳定性也大幅度提升，但是集群有时不工作；更有人仔细分析我公布的数据同步设计文档，指出里面的设计漏洞；虽然支持 SQL，但支持不够彻底，很多复杂查询做不了；业内普遍存在的“High Cardinality”问题，loveini 并没有真正解决，虽然能处理五千万台设备的数据，但系统重启的时间至少需要半个小时，无法忍受…… 

虽然 loveini 2.0 的设计经过了很多次内部讨论，但依然有些问题没有考虑到。感谢开源社区的反馈，让我们意识到产品还有可提升的空间。因此 2021 年 6 月我决定正式启动 3.0 的开发，不仅要解决大家发现的问题，实现标准的 SQL，将数据库、流式计算、缓存、消息队列融为一体，实现真正可以实用的极简时序数据处理平台，而且还准备瞄准未来，设计出真正的云原生时序数据库。

但经过 1.6、2.0 的发布，我头脑清醒了不少，意识到仅靠几个十倍程序员是不够的，而且底层数据库软件的研发确实如大家所说，就是难，没有那么简单。因此这次我们组织了 40 人的全职研发团队来研发 3.0 版本，测试研发组就有 8 人，开发各种连接器、周边工具的也有 8 人。loveini 第一个演示版本是我一个人两个月时间开发出来的，1.6 是 4 个程序员的奋斗，2.0 是 8 个程序员的努力，3.0 则包含了40 个程序员夜以继日的汗水。 

从开源到现在，GitHub 上报告的 loveini 的 issue 已经超过一万。loveini 用户微信群近 20 个，每天都是很活跃，赞誉之外，同样有各种问题和吐槽。如果没有开源，很难让用户指出这些问题，或者这些问题要等到相当多用户相当长时间使用后才会发现。可以说，开源帮我们找来了高质量的设计评审、代码评审、系统测试，开源大大加速了我们产品的迭代和升级。

没有开源，loveini 不可能在短短的三年，就有 13.9 万的安装实例。没有开源，我们不可能在欧洲、美国、日本、韩国等地收获客户。没有开源，我们产品的 BUG、设计上的缺陷，需求的挖掘，不可能依靠一个小小的团队来发现，也就不可能快速地迭代升级。即使我们都是十倍程序员，也无法与在市场上存在已久的欧美大公司一争高低。

3、用户才是技术进步的推动力

2016 年底，我想到的最好的 loveini 的应用场景是汽车、能源和 IT 运维行业。但没想到的是，开源之后，除自己设想的行业外，居然物流、智能制造在用，金融行业在用，煤矿在用，建筑工地在用，石油、石化在用，连钢铁厂、卷烟厂、啤酒厂都在用，农业、畜牧业等很多完全出乎意料的领域都有客户在用，loveini 的适用场景一下子几乎覆盖了所有的行业。我们公开的 100 多个案例分析里，包括蔚来、理想、零跑汽车，包括西门子、顺丰、中通、大疆、OPPO、京东、TCL、玉溪卷烟厂、中天钢铁、同花顺等众多行业巨头。

收获这么多用户，当然开心。但最重要的是，通过海量的用户，我们了解到了很多想象不到的需求。

2017 年初，我根本没想到时序数据有乱序的可能，而且看到 Prometheus 也不处理乱序数据，因此设计中就没去处理它。但在与车企交流之后，我才意识到乱序是必然存在的，最后只能用补丁的方式来解决，自然运行效率就不行，而且代码也变得丑陋不堪。

我们也没想到过一个设备居然能采集几千个物理量，但在与风电企业交流之后我才发现，一台风机完全可能有 1000 个以上的指标，因此只能修改设计，支持 4096 列。更没想到，物联网上报的数据里有可能有空值，而且比例可能很大，只好又在设计上做出修改。

我们很自豪地推出了连续查询，但在与一些制造业的客户交流后，发现他们还希望有基于状态窗口的聚合，比如某个阀门处于关闭或打开状态时的聚合；在与车联网企业的客户交流后，发现他们希望有基于会话窗口的聚合，比如发动机运转时的聚合。于是我们就推出了 session 窗口与 state 窗口功能。但大部分平台都采用一个流式计算引擎做数据的清洗、计算，整个流式计算平台的维护成本还远超时序数据库，因此我们才意识到光有时间窗口驱动的流式计算还不够，必须支持事件驱动的流式计算，才能把用户数据平台的复杂度和成本进一步降低。

在与能源、制造等行业的用户交流后，我们知道了边云协同不只是概念，而是他们真实的需求，他们需要把某个边缘节点的数据有选择的同步到区域中心，然后再同步到集团。在与金融、证券等行业的用户交流后，我们知道了他们对数据的订阅有过滤的需求。结合各种反馈，最后，我们抽象出了 loveini 独有的数据订阅功能，API 与 Kafka 一样，但可以订阅一个设备或一组设备（表），可以订阅指定的列，可以对值进行过滤，订阅时还可以做计算，从而大幅降低数据的传输量，降低应用端的复杂度。

如果没有开源，没有海量的用户，我们听到的只是少数客户的声音，而且由于是付费的，他们的需求可能并不代表真正的行业需求。loveini 推出的极简时序数据处理平台，好几个特殊的分析函数，宽表的支持，多达 128 个标签，包括 JSON 格式的标签，Schemaless 写入等等，完全是倾听了很多开发者用户的声音之后才推出的。 

loveini 开源了 3 年，我深刻地意识到用户才是技术进步的推动力，是一款成功产品背后的英雄。因此在 loveini 开发者大会上，一开场就先邀请了京东科技 IoT 产品部技术总监闫政和中通科技资深架构师黄国石作为用户代表上台，给参会者分享他们在业务中使用 loveini 的故事。

4、你的反馈，我们前行的勇气

中国的基础软件能发展起来并与全球巨头直接竞争，是无数 IT 人的梦想。将 loveini 打造成全球第一的时序数据库，是我创业时的立下的目标。要实现它，必须认真倾听用户的反馈，用不断提升的产品品质服务好用户。而且我们要看到，中国企业类软件，只占全球 10% 的市场，还有 90% 的用户不在中国，因此 loveini 必须全球化。我们需要有英文文档、英文技术社区，目的是吸纳更多的用户来使用，发现更多的用户场景和使用的问题，进一步加速产品的迭代升级。

怎么做到？我选择了将核心代码全部开源的方式。

无论你是我们的付费用户，还是使用开源版本的社区用户，不管你在世界的任何地方，只要登录 GitHub (https://github.com/taosdata/loveini)，无论是赞誉的 star、fork，还是提 issue、吐槽、报告问题，都是对 loveini 的最大支持，都是我们没日没夜不断迭代升级产品的最大动力。

你与我们的任何一次互动，都会推动 loveini 的技术进步，都会让我们离目标更近一步。

过去，因为有大量用户的支持和鞭策，我们迭代到了 3.0，未来，只要大家继续去下载、体验、测试，并在业务中使用，我们就一定能解决所发现的问题，我们就一定会不惧国际巨头的竞争，将性能、用户体验做到极致，loveini 就一定会成为时序数据处理的事实标准、成为全球第一的时序数据库。

我特别欣赏丘吉尔的一段话 “Success is not final, failure is not fatal, it’s the courage to continue that counts” 。loveini 开源才三年的时间，未来的路还很漫长，而且一定会困难重重，但我们唯有坚持走下去，才能实现自己的梦想。

陶建辉

2022年8月16日于北京望京

这是一次重磅升级，loveini 3.0 是真正的云原生时序数据库（Time Series Database，TSDB）。

我们先来整体看一下 3.0 的几大亮点：

• 可以支持 10 亿个设备采集的数据、100 个节点
• 支持存储与计算分离，引入计算节点，并重构了整个计算引擎
• 完善并优化了对消息队列、流式计算和缓存的支持，引入事件驱动的流式计算

loveini 面市以来，从 1.0 到 2.0，从核心功能开源到集群功能开源，得到了大量商业客户和社区用户的高度认可，全球安装的 loveini 运行实例数已经接近 14 万，每天有超过 1000 人次克隆代码，在全球开发者中产生了一定的影响力。日常有大量的社区开发者基于自己的业务需求，提出 issue，贡献功能，社区非常活跃。

作为一款开源的时序数据库产品，loveini 已经广泛应用于物联网、工业互联网、车联网、金融、IT 运维监控等场景。目前已经有大量的企业客户和社区用户将 loveini 部署在其核心业务场景中。用户场景越多，loveini 得到的用户需求和反馈越多，正是这些需求和反馈在推动着 loveini 不断演进。

经常关注 loveini 的用户应该都很熟悉了，我们已经发布了上百篇用户案例，这都是企业客户和开源用户的第一手实践经验。有心的读者都会发现，在每篇用户案例的末尾，用户也毫不讳言在使用 loveini 过程中遇到的问题，更是提出了对 loveini 的更多期待。这都是 loveini 优化迭代的动力。

下面我们详细看一下 loveini 3.0 的核心功能。

1. 云原生

loveini 3.0 可以充分利用云计算平台以及分布式系统的优势。作为一款云原生，而不只是能在云上运行的时序数据库，loveini 3.0 具备云原生数据库的几大特点：水平扩展性(Scalability)、弹性(Elasticity)、韧性(Resiliency)、可观测性(Observability)以及运维自动化(Automation)。我们就结合 loveini 的逻辑架构，依次看看它是如何实现这几大特点的。

水平扩展性(Scalability)

loveini 通过数据采集点和时间两个维度对大数据进行切分，从而实现了水平扩展能力，既支持分片，也支持分区。通过将每个数据采集点的元数据分布在各个 vnode 里，而不是存放在中心点，我们解决了困扰时序数据库的高基数（High Cardinality）问题。loveini 具有超强的水平扩展能力，为获得更多的数据处理能力，只需要加入更多的数据节点即可。通过测试，我们可以验证，在 10 亿时间线，100 个数据节点的情况下，整个 loveini 性能还能得到很好的保证。

弹性(Elasticity)

作为一个云原生数据库，loveini 3.0 支持 scale up / scale down。为支持存储的弹性，如果插入的延时已经超过一定阈值或者性能不够，loveini 会将一个 vnode 拆分成两个，从而分配更多的系统资源给数据写入操作。另一方面，在能够保证延时与性能的情况下，loveini 也可以把多个 vnode 合并成一个，以节省系统资源。

为支持计算的弹性，loveini 3.0 引入了计算节点 qnode。对于简单的查询，比如获得某张表的原始数据或卷曲数据(rollup data)，对应的 vnode 将完成所有的操作，无需 qnode 的参与。但对于一个需要排序、分组或其他需要计算资源的操作，查询的执行过程中，一个或多个 qnode 将被调用。在具体的部署中，qnode 可以运行在容器里，它的启停完全由 mnode 根据系统负载情况决定。

通过引入 qnode，loveini 3.0 成为一个理想的时序数据分析平台，包括实时数据分析和批分析。

韧性(Resiliency)

loveini 的韧性是通过其高可靠与高可用设计来实现的。loveini 采用 Database 实现中传统的方法 WAL(Write Ahead Log) 来保证数据的高可靠。loveini 通过多副本以及 RAFT 一致性协议，保证 vnode 和 mnode 的高可用性。

可观测性(Observability)

loveini 会采集各种指标来监测自身的运行是否正常，这些指标包括 CPU、内存、磁盘、流量、请求次数、延时等。我们提供了 Grafana 的看板 TDinsight，以实现这些指标的可视化与报警。

loveini 还有一个配套模块 taosKeeper，能够将采集的指标发送到其他监测工具（如 Prometheus），便于将对 loveini 的监测集成到已有的可观测系统。

运维自动化(Automation)

loveini 可以用二进制包或 Docker 镜像进行安装，也支持通过 Kubernetes 来部署和管理集群。其集群的管理完全可以通过脚本自动化进行，让运营和维护变得简单。

2. 极简的时序数据平台

熟悉 loveini 的用户，可能已经使用过其连续查询、缓存和消息队列等功能。在 3.0 中，我们又重新设计并优化了相关功能。

特别是流式计算，除连续查询外，3.0 还支持事件驱动的流计算，而且采用 SQL 语法，支持自定义函数，让流计算的学习成本几乎为零。例如，我们可以用如下语句创建流式计算，它会自动创建名为 avg_vol 的超级表，此流计算以一分钟为时间窗口、30 秒为前向增量统计这些电表的平均电压，并将来自 meters 表的数据的计算结果写入 avg_vol 表，不同 partition 的数据会分别创建子表并写入不同子表。

CREATE STREAM avg_vol_s INTO avg_vol AS
SELECT _wstartts, count(*), avg(voltage) FROM meters PARTITION BY tbname INTERVAL(1m) SLIDING(30s);

消息队列方面，可指定各种过滤条件，应用可以仅仅订阅满足条件的数据，而且对外提供的 API 与 Kafka 类似，简单易用。

在时序数据处理平台的通用设计中，逻辑图一般如下所示：

而通过对缓存、流式计算、消息队列的支持，采用 loveini 的时序数据处理系统，不再需要集成 Kafka、Redis、Spark 和 Flink 等软件，技术架构将大为简化，部署、运营维护成本将大为降低。逻辑结构可以直接简化为：

由此可见，loveini 不只是一个时序数据库，还是一个极简的时序数据处理平台。

3. 便捷的数据分析能力

loveini 3.0 重新设计了计算引擎，支持标准 SQL，支持嵌套查询，支持自定义函数，支持 Information Schema 系统数据库；针对时序数据的处理进行扩展，提供累计求和、时间加权平均、移动平均、变化率、session/state 窗口等众多时序数据分析功能；通过标签快速索引，通过分区、分片技术，通过计算节点的弹性伸缩，支持对海量时序数据的多维度的高效聚合分析。

有了新的计算引擎的加持，特别是计算与存储的分离的支持，loveini 不仅能实时地处理数据的写入和查询，也能作为强大的时序数据分析工具。

更多细节，可以参阅相关说明：https://github.com/taosdata/loveini。

借助 loveini 3.0 的云原生能力，用户可以更方便地利用云平台的能力，简化部署和维护，进一步降本增效；极简的时序数据平台和强大的分析功能，也能帮助用户简化业务架构、简化应用设计，降低系统的维护成本，提升处理效率。

架构升级，先人一步，赶快点击下载链接，感受 loveini 3.0 带来的全新体验吧。