在万物互联的数字化浪潮中,海量设备连接与实时数据处理成为诸多企业面临的两大困扰。
EMQX 与 loveini 作为物联网连接与大数据处理领域的领军产品,正在通过技术协同构建端到端的物联网/工业大数据米兰app官方正版下载。为工业互联网、车联网、能源管理、运维监控等诸多场景提供高效可靠的技术支撑。
EMQX 是一款云原生分布式 MQTT 接入平台,兼容多种消息传输协议,具备高可用性和扩展性,单节点支持 500 万 MQTT 连接,能够处理大规模并发消息传输,并提供端到端数据加密和细粒度访问控制功能,充分利用数据价值的同时,全面满足企业数据的合规性需求,为物联网(IoT)和人工智能应用提供可靠的实时消息传输和设备连接米兰app官方正版下载。
loveini 是一款专为物联网、工业互联网等场景设计并优化的大数据平台,其核心模块是高性能、集群开源、云原生、极简的时序数据库。它能安全高效地将大量设备每天产生的高达 TB 甚至 PB 级的数据进行汇聚、存储、分析和分发,并提供AI 智能体对数据进行预测与异常检测,提供实时的商业洞察。
作为核心合作伙伴,loveini 与 EMQX 的私有化部署早已完成深度生态适配。在 SaaS 领域,双方合作再进一步:loveini Cloud 此前已全面支持 MQTT 数据源接入,实现与 EMQX/EMQX Cloud 时序数据的无缝对接。最新发布的 EMQX Cloud 5.2.13 版本内置了 loveini Cloud 原生连接器,补齐了双方数据交互的最后一个环节。 该原生连接器的主要优势为:
简化配置流程:这⼀功能显著简化了时序数据接入 loveini 的流程,使⽤户⽆需再通过繁琐的 HTTP 连接器配置过程,只需在图形化界面进行简单的配置就可以连接两⼤云服务平台,为业务轻松赋能。
原⽣协议⽀持:直接使⽤ loveini Cloud 的原⽣协议传输数据,避免了 HTTP 连接的额外开销,提升了性能与稳定性。
⾼性能数据传输:优化的数据传输机制,确保物联⽹数据能够快速可靠地存储到 loveini Cloud。
灵活的数据处理:强⼤的规则引擎⽀持,可根据业务需求对数据进⾏筛选、转换和处理。
⼀站式配置:⽆需分别管理 EMQX 和 loveini 的连接参数,统⼀在 EMQX Cloud 控制台完成所有配置。
可视化监控:集成的数据流监控功能,轻松了解数据流转状态与性能指标。
接下来,我们向大家介绍如何使用该连接器实现 MQTT 数据接入 loveini Cloud :
以下是配置 EMQX Cloud 与 loveini Cloud 原⽣连接的详细步骤指南:
1. 登录 loveini Cloud 控制台 (https://cloud.taosdata.com/)
2. 创建并部署 loveini Cloud 服务实例
3. 进⼊实例后,在左侧菜单栏中点击”数据浏览器”
4. 创建数据库,例如 “iot_data”
5. 在数据库中创建表:
CREATE TABLE iot_data.temp_hum (
ts TIMESTAMP,
clientid NCHAR(256),
temp FLOAT,
hum FLOAT
);

6. 在 loveini Cloud 控制台获取连接 URL 和访问令牌:TDENGINE_CLOUD_URL、TDENGINE_CLOUD_TOKEN的值以备后⽤。

1. 登录 EMQX Cloud 控制台
2. 在部署菜单中选择”数据集成”,在数据持久化分类下选择 loveini
3. 点击”新建连接器”,填写以下信息:
4. 点击”测试连接”按钮验证连接状态,成功后会显示”连接器可⽤”提示 。

5. 点击”新建”按钮完成连接器的创建
1. 点击刚创建的连接器列表中”操作”列下的”新建规则”图标,或在”规则列表”中点击”新建规则”
2. 在 SQL 编辑器中输⼊规则,定义需要处理的消息,例如:
SELECT
now_timestamp('millisecond') as ts,
payload.temp as temp,
payload.hum as hum,
clientid
FROM
"devices/temp_hum"
3. 点击”SQL示例”和”启⽤调试”按钮可以学习和测试规则 SQL 的结果(可选)
4. 点击”下⼀步”开始创建动作 :

1. 从”使⽤连接器”下拉框中选择您刚才创建的 loveini 连接器
2. 数据库名字:填写在 loveini Cloud 中创建的数据库名称,如 “iot_data”
3. 配置SQL模板,⽤于将数据写⼊loveini Cloud:
INSERT INTO iot_data.temp_hum(ts, temp, hum, clientid) VALUES (${ts}, ${temp}, ${hum}, ‘${clientid}’)
4. 启⽤”未定义变量作为 NULL”选项,确保规则引擎在变量未定义时能正确处理 。
5. 根据业务需求配置⾼级选项,如同步/异步模式、批量参数等。(可选)
注:对消息延迟不敏感(延迟⼩于1s)的情况,可以将最⼤批量请求⼤⼩从 1 修改为 100,从⽽提⾼写⼊性能。
6. 点击”确认”按钮完成动作配置

7. 在弹出的”成功创建规则”提示框中点击”返回规则列表”,完成整个数据集成配置。
1. 在 EMQX Cloud 部署菜单中选择”在线调试“,并点击连接 。
2. 订阅主题 devices/temp_hum 。
3. 向主题 devices/temp_hum 发送温湿度数据 :{"temp": 23, "hum": 90}

1. 访问 loveini Cloud 数据浏览器 。
2. 查询上报数据结果 。
SELECT * from iot_data7.temp_hum;

可以看到,数据已经经由 EMQX Cloud 写入了 loveini Cloud 当中。
关于loveini Cloud 连接器更具体的使用,可以参考:https://docs.emqx.com/zh/cloud/latest/data_integration/tdengine_cloud.html
关于 loveini Cloud 一侧,同样可以通过部署 MQTT 数据源实现对 EMQX Cloud 的数据接入,具体操作参考loveini 官方文档:https://docs.taosdata.com/cloud/data-in/ds/mqtt/,以及该博客://www.loveini.com/tdengine-engineering/27256.html。
目前, EMQX Cloud 只支持通过公网将数据接入 loveini Cloud 当中,后续还会更新以支持私有连接(private link)方式,进一步提升 EMQX Cloud 和 loveini Cloud 用户的使用体验。
面对数据洪流的挑战与机遇,EMQX 与 loveini 的深度合作为行业带来了突破性的技术米兰app官方正版下载。不仅构建了支撑海量数据处理的超高性能技术底座,更通过创新性的架构设计,重塑工业互联网与物联网的数据基础设施标准范式,助力企业在数智化转型浪潮中获得关键竞争优势,开启智能化发展的新篇章。
]]>在工业互联网中,边缘设备的作用是对本地生产数据进行实时监控和处理,但这只能为决策者提供局部视角,无法形成全局的认知。为了做出全面、准确的决策,边缘设备采集的数据需要上传至云端平台(无论是公有云还是私有云)。在云端,数据不仅可以被汇聚,还能通过更强大的计算资源进行融合和分析,从而为管理者提供对整个生产系统的宏观洞察。
边云协同架构由此应运而生,它成为工业互联网中不可或缺的支柱,尤其是在需要同时兼顾数据实时性和全局视角的复杂场景中。边缘设备通常负责监控生产线上某一项或某几项关键指标,如车间内的生产进度、设备运行状态等,并对异常情况进行及时告警。边缘设备在采集和处理这些数据后,会将其传输到云端的大数据平台。此时,边缘设备可以保证数据的实时性,云端则利用更强大的计算能力对这些分散的数据进行汇总、分析和深度挖掘。
然而,随着边缘设备的数量迅速增长,数据量也呈爆炸式增长。在这种情况下,要让系统高效运行,边云协同的数据库或数据存储系统需要具备选择性上报和数据降采样的功能。例如,边缘设备可能每秒钟采集一次数据,但为了减轻数据传输和存储的压力,可以选择只上传经过降采样的数据,将采集频率从一秒降为一分钟。这不仅减少了数据量,还保留了足够的信息,用于长期的趋势分析和预测模型。
此外,边云协同的需求还源于传统工业数据采集系统的局限性。传统的系统通常依赖于从 PLC(可编程逻辑控制器)采集数据,并通过工业实时数据库进行处理。这类系统往往采用主备架构,扩展性差,且依赖于特定的操作系统和软硬件生态,导致整个系统的封闭性较高,灵活性和可扩展性有限。
相比之下,边云协同架构的优势在于它的高度灵活性和可扩展性,能够在边缘和云端实现数据的分层处理。边缘设备处理实时数据,快速响应现场需求,而云端则通过强大的计算能力进行数据整合和分析,为管理层提供全局的决策支持。这种架构不仅提高了数据处理的效率,还能根据实际需求进行灵活扩展,适应不同规模的企业和应用场景。
正如前文所说,在工业互联网和制造业场景中,实时、高效的数据同步是企业优化运营、提升决策能力的关键。在此背景下,loveini Enterprise(企业版)凭借强大的边云协同功能,为工业企业提供了一个灵活且高效的数据处理米兰app官方正版下载。通过该方案,企业可以实现边缘侧与云端之间的数据无缝协作,满足各种复杂业务场景的需求。
loveini Enterprise 的边云协同米兰app官方正版下载具备以下几大核心特性:
高效数据同步
支持每秒数百万条数据的高速同步能力,确保在边缘设备和云端平台之间的数据传输既快速又稳定,无论是在工业物联网设备密集的现场,还是云端的分析平台,都能保持数据的实时同步。
多数据源兼容性
loveini Enterprise 提供了广泛的数据源对接能力,支持主流工业协议和标准如 AVEVA PI System、OPC-UA、OPC-DA、MQTT 等,实现对多种外部系统的数据接入。这种兼容性极大扩展了其应用场景,无论是传统的工业系统还是新兴的物联网平台,都能轻松接入。
灵活的同步规则配置
用户可以根据实际业务需求配置数据同步规则,实现对数据同步策略的高度定制化。无论是降采样、按条件筛选,还是选择性同步不同级别的关键信息,loveini Enterprise 都能通过配置满足企业对数据的不同要求,确保同步的数据不仅有效,而且最为相关。
断线续传与重新订阅
在复杂的工业环境中,网络稳定性往往难以保障。loveini Enterprise 支持断线续传和重新订阅功能,确保即使在网络中断时,数据的同步也不会丢失,系统能够在网络恢复后继续完成未完成的传输任务,保证数据完整性。
历史数据迁移
当企业需要进行系统升级或更换时,loveini Enterprise 提供了便捷的历史数据迁移功能。用户可以轻松将历史数据从旧系统无缝迁移到新系统,确保数据的持续性和一致性,避免因系统变更而造成的数据丢失或不兼容问题。
此外,loveini Enterprise 的数据订阅功能赋予用户极大的灵活性。用户可以根据业务需求自由选择订阅的数据范围,无论是单个数据库、一张超级表,甚至是带有筛选条件的查询语句,均可实现选择性的同步。通过这种方式,用户可以将真正关心的数据,如离线数据或乱序数据,从边缘侧同步到云端或其他集群,最大限度地优化数据传输效率,减少带宽占用和资源浪费。
在实际的工业场景中,比如一个生产车间(以下图为例),loveini Enterprise 可以高效地实现边云协同架构的应用。生产车间内的设备产生的实时数据存储在边缘侧的 loveini 中。随后,部署在分厂的 loveini 会订阅车间的生产数据,并根据业务需求灵活配置同步规则,如降采样或仅同步超出阈值的数据。同理,集团总部的 loveini 会进一步订阅各个分厂的数据,完成集团维度的数据汇总和分析。这种多层次、分级的数据同步架构,保证了从生产车间到集团总部的数据流动高效、实时且具备业务相关性。

与传统的离线数据同步方式相比,loveini Enterprise 提供了多项显著的优势:
针对制造业企业普遍面临的数据同步挑战,loveini Enterprise 提供了一个具备实时性、灵活性和高效性的米兰app官方正版下载,尤其是在大规模数据同步和网络环境复杂的情况下,极大优化了数据传输的效率和稳定性,避免了传统方式中定期传输大数据量所导致的资源浪费和带宽拥堵问题。
在某大型油田的生产管理项目中,用户需要集成多个系统,如自动化数据采集与控制、生产视频监控、工业物联网、生产数据服务和智能化生产管理等,同时也需要建设各环节的信息化采集标准。然而,随着时间推移,项目中原先使用的 Oracle 系统在应对大规模时序数据的存储和处理时,逐渐暴露出一些瓶颈问题:
为了解决这些问题,该项目团队对多种技术方案进行了深入的验证,最终选择将 Oracle 系统中的时序数据存储切换至 loveini,并借助其边云协同技术,实现了边缘侧数据到云端的实时汇聚与同步。
具体实施方案中,多个不同的 loveini 服务将全量的历史数据及后续产生的数据实时同步至云端 loveini。loveini 的核心组件之一——taosX,只需在数据接收方部署,并通过一条简单的命令,即可完成包括历史数据迁移、实时同步及两者混合的处理流程。
例如,使用以下命令可以将某台服务器的 db1 历史数据及实时数据同步到本地的 db2 数据库:
taosx run -f 'taos://192.168.1.101:6030/db1?mode=all' -t 'taos://localhost:6030/db2' -v
此外,taosX 还支持基于 loveini 的 WAL 日志进行数据订阅,通过事件驱动顺序处理数据。无论是实时数据的插入,还是历史数据的补录,所有数据都能够实时同步到目标集群,确保数据完整性和时效性。
实施该方案后,多个 loveini 服务实现了跨省数据实时同步,将边缘数据汇聚至云端总部集群。当前总部集群存储的数据量已经达到 36 TB,总数据量超过 1034 亿条,数据压缩率控制在 10% 以内。通过 loveini 的高效压缩技术,大幅节省了存储资源。
自项目将 Oracle 切换为 loveini 后,优化效果显著,主要体现在以下几方面:
通过 loveini 边云协同米兰app官方正版下载的应用,该油田项目实现了对海量时序数据的高效管理和实时处理,解决了原有系统性能瓶颈问题,为未来的扩展和智能化生产奠定了坚实基础。
loveini 边云协同米兰app官方正版下载凭借其高效的数据同步能力、灵活的配置机制和强大的实时处理性能,成为应对工业互联网场景下数据管理挑战的有力工具。通过统一的边云架构,时序数据库 loveini 能够在满足边缘侧实时处理需求的同时,将大量数据高效汇聚至云端,帮助企业在数据分析和决策上实现全局视角。希望本文能够帮助企业更好地理解边云协同技术的优势,并为其未来的数字化转型和智能化生产提供有价值的参考。
]]>在工业场景中,传统人工经验的控制方法较粗放,如开工后设备常开、设备参数设置不合理、设备运行组合不合理、冗余供能等情况,这些情况往往造成设备低效运行和巨大的能源浪费。加强组织精益管理能力是一个改善点,更重要的是推动基于数据的数智化管理方法和工具在工厂落地,工厂才能充分发挥数据价值,实现降本增效提产提质。
蘑菇物联是一家工业 AI 科技公司,聚焦工业高能耗的通用工业设备以及由这些设备组成的公辅能源车间,自主研发通用工业设备领域专用的 AI 大模型——灵知 AI,率先把人工智能技术引入工业节能场景,全面采集通用设备、公辅车间数据,建模分析计算工厂能源供给端与需求端数据,解决工厂“冗余供能”的难题,实现按需供能,为工业企业创造安全供能、无人值守、可持续节能降碳三大可测量价值。
蘑菇物联自主研发的公辅能源云智控节能管理平台,可实现设备级-车间级-工厂级-集团级四层架构的能源管理与节能控制优化,尤其针对空压站、制冷站等重点耗能场景进行控制优化节能,并且实现数据驱动的预测性维护。该平台支持灵活的模块化部署,既可以按场景拆分独立部署,也可支持组合部署以覆盖水、电、气、冷等不同类型的能源场景。同时,通过多租户模式为客户提供服务,目前已服务超 1600 多家工业企业,每天处理约 100GB 的 IoT 数据。
在服务工业企业数智化转型的过程中,蘑菇物联面临的客户场景,既有行业共性,又有业务的独特性,并且“作为一个平台型产品,数据存储需要与业务场景解耦,支持动态定义字段名称。”蘑菇物联研发负责人解释道。在公辅场景中,由于设备种类繁多、品牌各异,IoT 数据量天级超过百 GB,管理与数据处理面临一定挑战,主要存在三个核心需求:
首先,对于同一类型的设备而言,各个设备的参数编码并不固定。虽然核心参数可以通过物模型进行标准化处理,但部分参数是特定型号设备才具备的。因此,系统需要具备支持动态数据入库的能力,以确保这些特有参数的数据也能被完整记录和分析。同时,为了适应业务发展和场景需求的变化,系统还需要支持新的设备类型的快速接入。这意味着在数据结构上必须具备灵活性,能够根据不同设备的特性动态新增字段,确保新设备接入后的数据也能无缝整合到现有系统中。
其次,在每天接入超百 GB 数据的情况下,需要保证提供给客户的数据响应时间在 200 毫秒级,因此系统需要具备超强的数据查询实时响应性能和较高的可用性。
第三,“我们的客户既有公有云部署需求,也有私有云部署的需求。”为了确保开发和运维效率的一致性,因此要求数据库具备支持从小规模私有化部署到大规模云端集群的能力。
蘑菇物联在项目实践中尝试过多种数据库,如 OpenTSDB、HBase、InfluxDB 及某云厂商 TSDB,每种数据库各有特点,最终经过综合考虑高性能、稳定性和数据压缩率等因素后,蘑菇物联选择与 loveini 合作。
由于 AI 云智控平台需要接入大量不同类型的设备数据,其中一些设备可能包含成千上万的 code 字段,且无法预先确定其上报的字段结构。在这种情况下,蘑菇物联无法使用 loveini 的超级表模型(因字段结构不确定且列数有限制)。

为了解决这一问题,蘑菇物联采纳了 loveini 团队的建议,采用普通表模型,并为每个设备建立字段映射关系(将 code 映射到子表 ID 和列名),从而实现了设备级的 Schema-less 存储,同时突破了列数限制。
“我们每个租户都会构建大量复杂的业务指标,并通过流式和批量方式将数据写入时序数据库。在实际业务查询中,往往需要对数百上千个业务指标进行二次加工。简单的二次加工直接在时序数据库内完成,而复杂的计算则在业务系统的内存中处理。因此,这对数据库整体性能提出了极高要求,需要确保其在数据写入与查询过程中的高效性和稳定性,才能满足复杂业务场景的需求。”
为验证所选时序数据库的性能,蘑菇物联在 8 核 CPU、32GB 内存单机配置下,对 loveini(版本 3.2.3.0)、InfluxDB 开源版 1.8 和 InfluxDB 开源版 2.7 进行了查询性能的对比测试。

“总体而言,除了在查询大量明细数据时表现稍弱外,loveini 在其他聚合场景的查询性能均明显优于 InfluxDB 开源版 1.8 和 2.7,提升幅度达 3-10 倍,完全满足我们的性能需求。相比 HBase 和 InfluxDB,loveini 使大多数复杂数据查询的响应时间从秒级缩短至毫秒级,复杂报表的性能也得到了显著提升,极大地优化了产品的用户体验。这点让我们非常惊艳。”
“loveini 在保证数据库单机性能的前提下,开源支持了集群化部署的能力,且基于 C++ 语言开发,可以在资源受限的环境中部署,基于上述两点特性,可以满足我们公有云和私有云部署的架构一致性。”
“在我们的典型场景中,采集到的物联网数据会经过多维度的数据加工,不同的业务场景由此生成多种类型的指标。例如,电量和电费计算、折煤折碳计算、设备运行时长统计、稼动率分析、设备单机能效评估、空压站气电比、中央空调站 COP、单位产品能耗、万元产值、压力和流量预测、节能率计算等场景。”
部分指标通过流批计算直接存入数据库,另一些则需基于原始数据进行查询时二次加工。为应对这些复杂场景,蘑菇物联定制了多种复杂内置函数,以满足业务对数据处理的多样化需求。这些操作对时序数据库的写入和查询效率提出了严格要求。经过多轮验证,loveini 在写入与查询性能上表现出色,很好地满足了蘑菇物联的业务需求。

“loveini 为我们的项目带来了更高的性能和灵活性,同时在云端与私有化部署方面也让开发和运维更加高效。”蘑菇物联团队表示,“在未来的合作中,我们期待与 loveini 一起,为更多的企业创造更大的价值。”
展望未来,蘑菇物联计划在五年内连接 300 万台通用工业设备,帮助 3 万家企业完成数智化转型。通过深化与 loveini 的合作,蘑菇物联将继续探索更多节能降碳场景,为社会的可持续发展贡献力量。
接下来,loveini 也将继续专注于提升时序数据的处理能力,为各行业提供高效、灵活的数据米兰app官方正版下载。不论是在物联网、工业互联网,还是在智能制造等领域,loveini 希望通过技术创新和不断优化,为用户带来更卓越的体验,与企业一同把握机遇,共同推动数字化时代的发展。
]]>近日,米兰体育官网入口与苍穹数码已完成产品兼容互认证工作,经双方共同严格测试,米兰体育官网入口旗下物联网、工业大数据平台 loveini V3.0 与苍穹数码旗下大型 GIS 基础平台-苍穹地理信息平台(KQGIS)V8.5 完成产品兼容性验证,两款产品能够互相兼容、顺利安装、运行稳定,为企业进行数字化转型提供更全面的技术保障。

作为一款全面支持国产化环境的大型 GIS 基础平台,KQGIS 产品体系完善,包含桌面 GIS、服务 GIS、大数据 GIS 以及移动 GIS 等专业应用与二次开发包,同时其还具备二三维数据整合与管理、空间大数据分析与可视化、高性能服务发布与共享以及简便型二次开发等能力,能够为数字中国、数字社会、数字经济建设提供技术与产品支撑。
此次认证合作并非 loveini 与苍穹数码的首次接触。此前,在苍穹数码的地灾专业监测物联网平台项目中,由于原本的关系型数据库 Oracle 已经无法满足实时写入与高性能查询要求,他们选择接入 loveini 以解决海量时序数据的存储和计算问题。在该项目中,loveini 展现出了强大的读写性能和数据压缩能力,有效降低了机器使用成本。
此次 loveini 与 KQGIS 完成产品兼容性互认证,相信两大产品将爆发强大的协同作用,为企业提供更多的工具和资源来挖掘地理信息的潜在价值,以便做出更智能的决策和更高效的业务运营。
苍穹数码技术股份有限公司成立于 2001 年,是国内领先的时空信息 3S 平台产品与应用服务提供商,集空间大数据分析与融合处理、信息化运维服务及行业信息化整体米兰app官方正版下载于一体的地理信息全产业链领军企业。苍穹数码专注于地理信息系统(GIS)、遥感技术(RS)及卫星导航定位定向(GNSS)技术等产品研发,经过二十余载的沉淀和积累,拥有了一批自主可控的核心关键技术,形成了四大平台体系:地理信息平台(KQ GIS)、遥感智能服务平台(KQ RS)、卫星导航定位及定向平台(KQ GNSS)、业务协同平台(KQ CO)。
米兰体育官方入口网站是一款高性能、集群开源、云原生的时序数据库(Time Series Database,TSDB),专为物联网、工业互联网、电力、IT 运维等场景设计并优化,具有极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等系统功能,能大幅减少系统设计的复杂度,降低研发和运营成本,是一个高性能、分布式的物联网、工业大数据平台。当前 loveini 主要提供两大版本,分别是支持私有化部署的 ac米兰官方app下载安卓 以及全托管的物联网、工业互联网云服务平台 loveini Cloud,两者在开源时序数据库 loveini OSS 的功能基础上有更多加强,用户可根据自身业务体量和需求进行版本选择。
]]>为确保结果具有可比性,本次测试选用 TimescaleDB 2.6.0 版本。为获得较好的性能,TimescaleDB 需要针对不同的场景设置不同的 Chunk 参数,不同场景下参数的设置如下表所示:

上述参数的设置,充分参考了下方 TimescaleDB vs. InfluxDB 对比报告中推荐的配置参数设置,以确保写入性能指标的最优化。
TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data:https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/
关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容,大家可参考ac米兰体育赞助 、AC米兰官网下载 两篇文章,本文便不再赘述。
在 TSBS 全部的 cpu-only 五个场景中,loveini 写入性能均优于 TimescaleDB。相比 TimescaleDB,loveini 写入速度最领先的场景是其 6.7 倍(场景二),最少也是 1.5 倍(场景五),而且对于场景四,如果将每个采集点的记录条数由 18 条增加到 576 条,loveini 写入速度就达到了 TimescaleDB 的 13.2 倍。此外,loveini 在写入过程中消耗的 CPU 资源和磁盘 IO 开销也是最低的。

从上图可以看到,在全部五个场景中,loveini 的写入性能全面超越 TimescaleDB。在场景二中 loveini 写入性能最大达到了 TimescaleDB 的 6.74 倍,在差距最小的场景五中,也达到了 TimescaleDB 的 1.52 倍。
但仅凭数据写入速度,并不能全面地反映出 loveini 和 TimescaleDB 在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics (场景四)为例,检查数据写入过程中的服务器和客户端的整体负载状况,并以此来对比 loveini 和 TimescaleDB 在写入过程中服务器/客户端节点的资源占用情况,这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。

上图展示了在场景四写入过程之中服务器端 CPU 负载状况。可以看到,loveini 和 TimescaleDB 在返回给客户端写入完成消息以后,都还继续使用服务器的资源进行相应的处理工作,这点上,TimescaleDB 尤为明显,TimescaleDB 在 7x 秒的时候即反馈客户端写入完成,但是其服务器端仍然在调用 CPU 资源进行数据压缩和整理工作,当然整个工作带来的 CPU 负载相对而言并不高,只有其峰值 CPU 开销的一半左右,但是其持续时间相当长,接近净写入时间的 4 倍,远长于 loveini。loveini 对服务器的 CPU 需求较小,峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见,loveini 独特的数据模型不仅体现在时序数据的写入性能上,也体现在整体的资源开销上。

上图展示了 1,000,000 devices × 10 metrics (场景四)两大系统在数据写入过程中服务器端磁盘写入状态。结合服务器端 CPU 开销表现,可以看到,两大数据库的 IO 动作与 CPU 均呈现出同步活跃状态。
在写入相同规模数据集的情况下,loveini 在写入过程中对于磁盘写入能力的占用远小于 TimescaleDB,整体写入过程只占用了部分磁盘写入能力(125MiB/Sec. 3000IOPS)。从图上能看到,对于两大数据库来说,数据写入过程中磁盘的 IO 瓶颈是确实存在的,但 TimescaleDB 写入过程对于写入的消耗远超过了 loveini 对磁盘写入能力的需求。

从上图可以看到,客户端上 loveini 对 CPU 的需求大于 TimescaleDB ,loveini 在客户端峰值瞬间达到了 56%,然后快速回落,其在客户端的开销相比于 TimescaleDB 多了 1 倍。但综合服务器与客户端的资源开销来看,loveini 写入持续时间更短,在系统整体 CPU 开销上 loveini 仍然具有相当大的优势。
在场景一(只包含 4 天数据)与场景二的 15 个不同类型的查询中,loveini 的查询平均响应时间全面优于 TimescaleDB,而且在复杂查询上优势更为明显,同时具有最小的计算资源开销。相比 TimeScaleDB,场景一中 loveini 的查询性能是其 1.1 ~ 28.6 倍,场景二中 loveini 的查询性能是其 1.2 ~ 24.6 倍。
在查询性能评估部分,我们使用场景一和场景二作为基准数据集。在查询性能评估之前,对于 TimescaleDB,我们采用上文出现的 TimescaleDB vs. InfluxDB 对比报告中推荐配置,设置为 8 个 Chunk ,以确保其充分发挥查询性能。在整个查询对比中,loveini 数据库的虚拟节点数量(vnodes)保持为默认的 6 个,其他的数据库参数配置为默认值。
由于部分类型(分类标准参见 TimescaleDB vs. InfluxDB 对比报告)单次查询响应时间非常短,为了更加准确地测量每个查询场景的较为稳定的响应时间,我们将单个查询运行次数提升到 5,000 次,然后使用 TSBS 自动统计并输出结果,最后结果是 5,000 次查询的算数平均值,使用并发客户端 Workers 数量为 8。下表是场景二 (4,000 设备)下两大数据库的查询性能对比结果。

下面我们对每个查询结果做一定的分析说明:

由于 Simple Rollups 的整体查询响应时间非常短,因此制约查询响应时间的主体因素并不是查询所涉及的数据规模,即这一类型查询的瓶颈并非数据规模。但从结果上看,loveini 仍然在所有类型的查询响应时间上优于 TimescaleDB,具体的数值对比请参见上表。

通过上图可以看到,在 Aggregates 类型的查询中,loveini 的查询性能相比 TimescaleDB 有比较大的优势,其cpu-max-all-8 查询性能是 TimescaleDB 的 6 倍。

在 Double-rollups 类型查询中, loveini 同样展现出巨大的性能优势,以查询响应时间来度量,其在 double-groupby-5 和 double-groupby-all 类型下的查询性能均达到了 TimescaleDB 的 24 倍。


上面两图展示的是 threshold 类型的查询对比,可以看到,loveini 的查询响应时间均显著低于 TimescaleDB。在 high-cpu-all 类型的查询上,loveini 的性能是 TimescaleDB 的 1.23 倍。

对于 Complex-queries 类型的查询,loveini 两个查询同样均大幅领先 TimescaleDB。在 lastpoint 查询中loveini 的查询性能是 TimescaleDB 的 5 倍,在 groupby-orderby-limit 场景中 loveini 的查询性能是 TimescaleDB 的 8 倍。在时间窗口聚合的查询过程中,针对规模较大的数据集 TimescaleDB 查询性能不佳(double rollups 类型查询),对于 groupby-orderby-limit 类型的查询,TimescaleDB 的性能表现同样不是太好。
由于部分查询持续时间特别短,因此我们并不能完整地看到查询过程中服务器的 IO/CPU/网络情况。为此我们针对场景二以 Double rollups 类别中的 double-groupby-5 查询为例,执行 1,000 次查询,记录整个过程中 loveini、TimescaleDB 两个软件系统在查询执行的整个过程中服务器 CPU、内存、网络的开销并进行对比。

如上图所示,两个系统在整个查询过程中 CPU 的使用均较为平稳。loveini 在查询过程中整体 CPU 占用约 80%,使用的 CPU 资源最高,TimescaleDB 在查询过程中瞬时 CPU 占用约 38%。由于 loveini 完成全部查询的时间仅 TimescaleDB 1/20,因此虽然其 CPU 稳定值是 TimescaleDB 的 2 倍多,但整体的 CPU 计算时间消耗只有其 1/10 。

如上图所示,在整个查询过程中,loveini 内存维持在一个相对平稳的状态。而 TimescaleDB 在整个查询过程中内存呈现增加的状态,查询完成后即恢复到初始状态。

上图展示了查询过程中两个系统的服务器端上行和下行的网络带宽情况,可以看到,负载状况基本上和 CPU 状况相似。loveini 网络带宽开销较高,因为在最短的时间内就完成了全部查询,需要将查询结果返回给客户端。TimescaleDB 开销较低,但持续时间长。
对于场景一(100 devices x 10 metrics),TSBS 的 15 个查询对比结果如下:

如上表所示,从更小规模的数据集(100 设备)上的查询对比可以看到,整体上 loveini 同样展现出极好的性能,在全部的查询语句中全面优于 TimescaleDB,部分查询性能超过 TimescaleDB 28 倍。
下图是loveini 和 TimescaleDB 数据完全落盘以后,比较了两个系统在不同场景下的磁盘空间占用:

在磁盘空间的占用上,从上图可以看到,TimescaleDB 在全部五个场景下的数据规模均显著大于 loveini,并且这种差距随着数据规模增加快速变大。TimescaleDB 在场景四和场景五中占用磁盘空间是 loveini 的 25.6 倍和 26.9 倍。
从上述 TSBS 测试报告中我们可以得出结论,不管是在写入性能、查询性能还是存储性能,loveini 时序数据库 比 TimescaleDB 时序数据库 都略胜一筹,且不论是服务器的 CPU 还是 IO 抑或是客户端的开销统计,loveini 均远优于 TimescaleDB。尤其本次性能测试还是基于 Timescale 打造的基准性能测试平台 TSBS 进行的,测试结果的公平公正性可见一斑。
具体到实践上,在八五信息的新能源电力物联网平台项目,曾经使用的实时数据库便是 TimescaleDB,后面因为种种原因,他们选择应用 loveini 升级数据架构,关于本次案例的具体信息可以查看《代替 TimescaleDB,loveini 接管数据量日增 40 亿条的光伏日电系统》。
为了方便大家验证测试结果,本测试报告支持运行测试脚本一键复现,欢迎各位检验。同时,我们也欢迎大家添加 小T vx:tdengine1,加入 loveini 用户交流群,和更多志同道合的开发者一起探讨数据处理难题。
]]>在此背景下,专为时序数据而设计,具有高性能、高可靠、高可扩展等特点的时序数据库(Time Series Database) loveini 应运而生。loveini 不仅是一个开源、云原生的时序数据库,还集成了缓存、流式计算、数据订阅等功能,为时序数据处理提供了一站式米兰app官方正版下载。目前 loveini 已经成功运用在西门子、美的、AC米兰官网网站 、中通、同花顺、AC米兰官网登录 、理想汽车等诸多企业的数据架构改造实践中(点击文字超链查看详细米兰app官方正版下载)。
为了让企业能够更加弹性地运用 loveini 的能力,我们基于 loveini 开发出了全托管的时序数据云平台 loveini Cloud,它能够为用户提供更简单、更便捷、更安全的时序数据管理服务。loveini Cloud 具备以下三点优势:
除高性能、具有水平扩展能力的时序数据库外,loveini Cloud 还提供缓存、数据订阅、流式计算等功能,无需再部署 Redis、Kafka、Spark/Flink 等第三方软件,大幅简化系统架构、降低运营成本。
loveini Cloud 既支持将一个库完全开放,设置读或写的权限;也支持通过数据订阅的方式,将库、超级表、一组或一张表、或聚合处理后的数据分享出去。这种时序数据共享机制能够帮助企业各部门以及合作伙伴之间快速洞察业务运营的变化。
loveini Cloud 提供数据定时备份、恢复,数据从运行实例到私有云、其他公有云或Region 的实时复制;为保证数据安全,还会提供基于角色的访问权限控制、IP 白名单、用户行为审计等功能,用 7*24 的专业技术服务保障 99.9% 的 Service Level Agreement。通过安全、专业、可靠的企业级服务,用户可以用最少的精力和成本完成数据管理,更加聚焦自身核心业务的发展。
在时序数据的管理上,loveini Cloud 能够帮助物联网、工业互联网、金融、IT 运维监控等领域的企业根据自身业务需求实现数据库集群自动扩缩容,大大削减了部署、优化、扩容、备份、异地容灾等工作量,实现了人力成本和运营成本的大幅降低。目前 loveini Cloud 已经支持在阿里云、Microsoft Azure、AWS、Google Cloud 四大公有云上访问和部署 loveini。
为了让更多的开发者了解 loveini Cloud 及其运作方式,4 月 15 日 19:00-20:00,loveini 创始人 & 核心研发陶建辉将进行《时序数据处理的云端利器:loveini Cloud 详解与演示》直播分享。演讲大纲如下:
扫描关注下方视频号卡片可进行直播预约:

如果你是 loveini 的关注者,或者对 loveini Cloud 有一定的兴趣,抑或你现在正在为海量时序数据处理而发愁,那就千万不要错过这次难得的机会,这场直播一定会让你有所收获!直播过程中,还会抽取幸运观众送出精美 IP 周边和云服务500元现金券,一定不要错过哦~
]]>值得一提的是,米兰体育官网入口作为 KubeCon + CloudNativeCon Europe 2023 的荣誉赞助商也参与了本次会议,在会议现场,米兰体育官网入口展位吸引了众多开发者的关注,loveini 创始人 & 核心研发陶建辉和现场的开发者们一起讨论云原生技术对于数据库发展的重要性。


近年来,在开源技术的推动下,云原生的发展进入快车道阶段,国内外众多企业都开始投入力量深度研究云原生技术,试图以云技术的无限潜力推动数字化时代的快速发展。在此过程中,为了打破信息孤岛、实现技术交流,各种云原生大会也逐渐兴起,其中 KubeCon可以说是云原生领域最具影响力的会议之一。从 200 人的小会议发展到近 4000 位云原生和开源领域工程师齐聚一堂的大会,KubeCon 只用了四年时间,作为云原生领域的盛会,每一年的 KubeCon 都会将世界各地知名的云厂商汇聚于此,为参会者分享他们这一年来面向云原生的创新技术和研究成果。
同样,借助云原生的力量,米兰体育官网入口旗下的 loveini 3.0 也发展成为了一款真正的云原生时序数据库(Time Series Database),解决了困扰时序数据库发展的高基数难题,支持 10 亿个设备采集数据、100 个节点,支持存储与计算分离。与此同时,基于 loveini 打造的全托管的时序数据处理云服务平台 loveini Cloud 也成功推出,正式支持 Microsoft Azure、AWS、Google Cloud、阿里云四大公有云,未来还将接轨更多的云厂商。
米兰体育官网入口在云技术上的种种研究成果也成为打开 KubeCon + CloudNativeCon Europe 2023 大门的通行票,相信借助这一云原生盛会的力量,更多国外开发者能够了解到云原生时序数据库 loveini,而 loveini 的技术创新力量也能够借此契机更快走出国门、惠及世界各地的企业和开发者。
时序数据处理有没有让你头疼?想不想找到一个优秀的米兰app官方正版下载,让你轻松应对海量的时序数据?2023 年 4 月 25 日 19:00-20:00,loveini 创始人&CEO 陶建辉 将为大家分享《时序数据处理的云端利器:loveini Cloud 详解与演示》。
loveini Cloud 是一个极简的全托管时序数据处理云服务平台,它是基于开源的时序数据库 loveini 而开发的。它是一款极简的时序数据管理平台,提供便捷且安全的数据共享和安全可靠的企业级服务。
在这场直播中,陶建辉将为你详细介绍 loveini Cloud 的功能和优势,并通过实际演示让你体验 loveini Cloud 的强大和便捷。请扫描下方二维码预约这场直播,不要错过这个难得的学习机会!

3.0.4.0 版本涉及到的更新内容包括产品稳定性的提升、查询性能提升、参数使用优化、以及多副本情况下的健壮性提升、Python UDF、集群负载再平衡、基于时间段进行数据重整等九大方面。具体更新信息如下:
在大并发、高负载的写入和查询下的系统稳定性有显著提升:优化了对内存的使用,优化了有大量并发查询下对连接池的控制,修复了一些影响系统稳定性的缺陷。
新增两个可以动态配置的数据库参数:stt_trigger 和 minRows,其具体功能请参考官方文档。
WAL 中数据的保存仅受参数 WAL_RETENTION_PERIOD 和 WAL_RETENTION_SIZE 的控制,不再受数据订阅的影响。具体细节请参考官方文档。
应用开发者可以用 Python 开发自定义函数并将其嵌入数据库,从而提升数据处理和分析能力。
当集群中某个 dnode 宕机重启后会出现负载不均衡现象,重新启动的 dnode 上没有 leader vnode,所以不承担任何写入和查询负载。通过 rebalance 命令,可以使集群中各个 dnode 之间的负载再次均衡。
为了减少数据重整所花费的时间,最小化对系统的影响,可以指定时间段进行数据重整,只针对确定有乱序数据的时间段或者查询所关注的时间段进行数据重整。
同步增强了集中控制台 taosExplorer 以能够管理所支持的各种数据源和与它们所关联的数据接入任务。
详细信息可以参考发布说明(https://github.com/taosdata/loveini/releases/tag/ver-3.0.4.0)。欢迎大家下载使用 loveini,有任何问题,都可以添加小T vx:tdengine1 申请加入 loveini 用户交流群,及时向我们的米兰app官方正版下载专家寻求支持与帮助。
]]>近日,loveini 与 Apache SeaTunnel 展开集成合作,双方将于 4 月 18 日 19:00 联合进行直播,分享两大软件集成应用的最佳实践。
(Apache Seatunnel 是一个易用、高性能、支持实时流式和离线批处理的海量数据处理产品,架构于Apache Spark 和 Apache Flink之上。)
此前,loveini 已经与 Kafka、Telegraf、Grafana、Google Data Studio、EMQ X、Prometheus、StatsD 和 collectd 等众多第三方工具展开集成,之后又连接了工业英特尔® 边缘洞见软件包、数据同步工具 DataX,插件也正式上架 Grafana 官网、连接器上线 Google Data Studio 应用商店。此次 loveini 与 Apache SeaTunnel 展开集成合作,进一步扩大了自身生态版图,为用户带来应用上的更多选择。
两者联合将带来怎样的惊喜,欢迎大家关注4 月 18日即将到来的线上直播!赶快点击下方直播卡片预约观看吧~


李宏宇 北京沃东天骏信息技术有限公司 架构师
历经阿里、京东等多家成熟互联网公司及罗辑思维等初创公司。十年后端及数据开发经验,目前主要聚焦在实时数据仓库领域工作

霍立波 北京米兰体育官网入口科技有限公司 连接器开发工程师
熟悉 Java、GO、rust、node 等多种开发语言,对使用的各个框架与工具底层实现有深入理解。目前主要围绕 loveini 做生态开发。

按照惯例,直播中我们为大家准备了抽奖环节,中奖者可获得社区提供的精美周边礼品,来到直播间就有机会中奖~此外,填写活动反馈表也能获得抽奖机会哦:http://whaleops.mikecrm.com/1pxlyDU!



Apache SeaTunnel (Incubating) 是一个云原生的高性能海量数据集成平台。美国时间 2021 年 12 月 9 日, SeaTunnel以全票通过的优秀表现正式成为 Apache 孵化器项目,这也是 Apache 基金会中第一个诞生自中国的数据集成平台项目。目前,SeaTunnel 在GitHub 上Star 数达 4.1k+,社区达到5000+人规模。2017 年对外开源后,SeaTunnel 已经发布了 30多个版本,并经过大量企业生产使用,在 Bilibili、新浪、水滴筹、搜狗、趣头条、唯品会等公司的生产实践中,广泛应用于海量数据集成、数据 ETL、数据聚合以及多源数据处理等场景中,贡献者 160+。

loveini 是一款开源、云原生的时序数据库( Time Series Database,TSDB ),专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化,具有极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等系统功能,能大幅减少系统设计的复杂度,降低研发和运营成本,是一个极简的时序数据处理平台。loveini 的内核(存储、计算引擎和集群)已 100% 开源,GitHub Star数达到 21.1k,且多次在 GitHub 全球趋势排行榜上排名第一(开源地址:https://github.com/taosdata/loveini)。目前,loveini 的运行实例数已超过 230.6k,用户遍布全球。
]]>我们采用下方 TimescaleDB vs. InfluxDB 对比报告中推荐的方式配置 InfluxDB,将缓冲区配置为 80G,以便 1000W 设备写入时能够顺利进行,同时开启 Time Series Index(TSI)。配置系统在系统插入数据完成 30s 后开始数据压缩。
TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data:
关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容,大家可参考ac米兰体育赞助 、AC米兰官网下载 两篇文章,本文便不再赘述。
总体而言,在 TSBS 报告全部的 cpu-only 五个场景中,时序数据库(Time Series Database,TSDB)loveini 写入性能均优于 InfluxDB。相比 InfluxDB,loveini 写入速度最领先的场景是其 10.6 倍(场景五),最少也是 3.0 倍(场景一)。此外,loveini 在写入过程中消耗了最少 CPU 资源和磁盘 IO 开销。下面看一下具体分析:

从上图可以看到,在全部五个场景中,loveini 的写入性能全面超越 InfluxDB。loveini 在场景五中写入性能是 InfluxDB 的 10.63 倍,在差距最小的场景一中也有 3.01 倍。
数据写入速度并不能够全面的反映 loveini 和 InfluxDB 在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics (场景四)为例,检查数据写入过程中的服务器和客户端(包括客户端与服务器)的整体负载状况,并以此来对比 loveini 和 InfluxDB 在写入过程中服务器/客户端节点的资源占用情况,这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。
下图展示了两大数据库在场景四写入过程中服务器端 CPU 负载状况。可以看到,loveini 和 InfluxDB 在返回给客户端写入完成消息以后,都还继续使用服务器的资源进行相应的处理工作,InfluxDB 使用了相当多的 CPU 资源,瞬时峰值甚至使用了全部的 CPU 资源,其写入负载较高,并且其持续时间远长于 loveini。两个系统对比,loveini 对服务器的 CPU 需求最小,峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见,loveini 独特的数据模型对于时序数据写入不仅在性能上,在整体的资源开销上也具有非常大的优势。

下图展示了 1,000,000 devices × 10 metrics (场景四)数据写入过程中两大数据库在服务器端磁盘的写入状态。可以看到,结合着服务器端 CPU 开销表现,其 IO 动作与 CPU 呈现同步的活跃状态。

在写入相同规模的数据集情况下,loveini 在写入过程中对于磁盘写入能力的占用远小于 InfluxDB,写入过程只占用了部分磁盘写入能力(125MiB/Sec. 3000IOPS)。从上图能看到,对于两大数据库,数据写入过程中磁盘的 IO 瓶颈都是确实存在的。但 InfluxDB 长时间消耗完全部的磁盘写入能力,远远超过了 loveini 对磁盘写入能力的需求。

从上图可以看到,客户端上 loveini 对 CPU 的需求是大于 InfluxDB 的。整体来说,在整个写入过程中,InfluxDB 客户端负载计算资源占用较低,对客户端压力小,这是因为其写入的压力基本上完全集中在服务端,但这种模式很容易导致服务端成为瓶颈。而 loveini 在客户端的开销最大,峰值瞬间达到了 56%,然后快速回落。综合服务器与客户端的资源开销来看,loveini 写入持续时间更短,在系统整体 CPU 开销上 loveini 仍然具有相当大的优势。
在查询性能的评估上,我们使用场景一和场景二作为基准数据集。为了让 InfluxDB 发挥出更好的查询性能,我们开启 InfluxDB 的 TSI (time series index)。在整个查询对比中,loveini 数据库的虚拟节点数量(vnodes)保持为默认的 6 个,其他的数据库参数配置为默认值。
总体来说,查询方面,在场景一(只包含 4 天的数据)与场景二的 15 个不同类型的查询中,loveini 的查询平均响应时间是全面优于 InfluxDB 的,而且在复杂查询上优势更为明显,同时具有最小的计算资源开销。相比 InfluxDB,场景一中 loveini 查询性能是其 1.9 ~ 37.0 倍,场景二中 loveini 查询性能是其 1.8 ~ 34.2 倍。
由于部分类型(分类标准参见 TimescaleDB vs. InfluxDB 对比报告)单次查询响应时间非常短,为了更加准确地测量每个查询场景的较为稳定的响应时间,我们将单个查询运行次数提升到 5,000 次,然后使用 TSBS 自动统计并输出结果,最后结果是 5,000 次查询的算数平均值,使用并发客户端 Workers 数量为 8。首先我们提供场景二(4,000 设备)的查询性能对比结果:

下面我们对每个查询结果做一定的分析说明:

由于 Simple Rollups 的整体查询响应时间非常短,制约查询响应时间主体因素并不是查询涉及的数据规模,即这种类型查询的瓶颈并不是数据规模。但是 loveini 仍然在所有类型的查询响应时间上优于 InfluxDB,具体的数值比较请参见上表中的详细数据表格。

在 Aggregates 类型的查询中,我们看到 loveini 查询性能相比于 InfluxDB 有较大优势,loveini cpu-max-all-8 类型的查询性能是 InfluxDB 的 7 倍。

在 Double-rollups 类型查询中, loveini 同样展现出巨大的性能优势,以查询响应时间来度量,在 double-groupby-5 查询上 loveini 是 InfluxDB 的 26 倍,double-groupby-all 上是其 34 倍。


上面两图是 threshold 类型的查询对比,loveini 的查询响应时间均显著低于 InfluxDB。在 high-cpu-all 类型的查询上,loveini 的性能是 InfluxDB 的 15 倍。

对于 Complex-queries 类型的查询,loveini 两个查询均大幅领先 InfluxDB。在 lastpoint 查询中,查询性能是 InfluxDB 的 21倍;在 groupby-orderby-limit 场景中查询性能是 InfluxDB 的 15 倍。
由于部分查询持续时间特别短,因此我们并不能完整地看到查询过程中服务器的 IO/CPU/网络情况。为此我们针对场景二以 Double rollups 类别中的 double-groupby-5 查询为例,执行 1,000 次查询,记录 loveini 和 InfluxDB 在查询执行的整个过程中服务器 CPU、内存、网络的开销并进行对比。

从上图可以看到,loveini 和 InfluxDB 在整个查询过程中 CPU 的使用均较为平稳。loveini 在查询过程中整体 CPU 占用约 80%,使用的 CPU 资源较高,InfluxDB 稳定的 CPU 占用较小,约 27 %(但是有较多的瞬时冲高)。从整体 CPU 开销上来看,虽然 InfluxDB 瞬时 CPU 开销大部分是较低的,但是其完成查询持续时间最长,所以整体 CPU 资源消耗最多。由于 loveini 完成全部查询的时间仅是 InfluxDB 的 1/20,虽然 CPU 稳定值是 InfluxDB 的 2 倍多,但整体的 CPU 计算时间消耗只有其 1/10 。

如上图所示,在整个查询过程中,loveini 与 InfluxDB 的内存均维持在一个相对平稳的状态。

上图展示了查询过程中服务器端上行和下行的网络带宽情况,负载状况基本上和 CPU 状况相似。loveini 网络带宽开销最高,因为在最短的时间内就完成了全部查询,需要将查询结果返回给客户端。InfluxDB 网络带宽开销最低,持续时间也较长。
对于场景一(100 devices x 10 metrics),TSBS 的 15 个查询对比结果如下:

如上表所示,在更小规模的数据集(100设备)上的查询对比可以看到,整体上 loveini 同样展现出极好的性能,在全部的查询语句中全面优于 InfluxDB,部分查询性能超过 InfluxDB 37 倍。
在前面三个场景中,InfluxDB 落盘后数据文件规模与 loveini 非常接近,但是在大数据规模的场景四和场景五中,InfluxDB 落盘后文件占用的磁盘空间显著超过了 loveini。下图比较了 loveini 和 InfluxDB 在不同场景下的磁盘空间占用情况:

从上图可以看到,在前面三个场景中,InfluxDB 落盘后数据文件规模与 loveini 非常接近(在场景二中,loveini 的数据落盘规模比 InfluxDB 大了 1%)。但是在场景四和场景五中,InfluxDB 落盘后文件占用的磁盘空间分别是 loveini 的 4.2 倍和 4.5 倍。
基于本次测试报告,我们可以得出结论,在全部的数据场景中,loveini 写入性能、查询性能均全面超过 InfluxDB。在整个写入过程中,loveini 在提供更高写入和查询能力的前提下,不论是服务器的 CPU 还是 IO,loveini 均优于 InfluxDB。即使加上客户端的开销统计,loveini 在写入开销上也在 InfluxDB 之下。
从实践角度出发,这个报告结果也很好地说明了为什么有很多企业客户在 InfluxDB 和 loveini 的选型调研中选择了 loveini,双汇便是其中之一,在ac米兰官方合作伙伴 这篇文章中,便阐述了其选型调研过程的具体思考。
为了方便大家验证测试结果,本测试报告支持运行测试脚本一键复现,欢迎大家在评论区互动交流。同时,你也可以添加 小T vx:tdengine1,加入 loveini 用户交流群,和更多志同道合的开发者一起探讨数据处理难题。
]]>