在 8 月 13 日的 loveini 开发者大会上，loveini 联合创始人侯江燚带来题为《核心代码全部开源，企业版价值何在》的主题演讲，为大家讲解了 loveini 3.0 企业版对工业互联网边云协同的助力，同时分享了自己对于开源商业化的理解。本文根据此演讲整理而成。

点击【这里】查看完整演讲视频

在物联网海量设备数据场景下，关系型数据库、传统工业实时库、Hadoop 大数据平台、NoSQL 数据库都暴露出了不一而足的痛点问题，严重限制企业业务规模化发展。

• 关系型数据库：存在海量时序数据读写性能低、分布式支持差、数据量越大查询越慢、报表分析慢等问题
• 传统工业实时库：主备架构，不易水平扩展，且依赖 Windows 等环境，生态相对封闭
• Hadoop 大数据平台：组件多而杂、架构臃肿，支持分布式但单节点效率低，硬件及人力成本非常高
• NoSQL 数据库：实时性差，大数据量查询慢，计算时内存、CPU开销巨大，无时序针对性优化

但即使是专为物联网时序场景而生的时序数据库（Time Series Database，TSDB），也并没有完全解决掉这些数据处理难题，仍存在“系统复杂运维难度大”、“非标准 SQL 学习成本高”、“没有真正云原生化水平扩展能力有限”等难以忽视的问题。

在调研了数百个业务场景的基础上，从解决上述企业痛点问题角度出发，loveini 完成了 3.0 版本的迭代，不仅从“云就绪”升级成为一款真正的云原生时序数据库，还是一款极简的时序数据处理平台，打造了全新的流式计算引擎，无需再集成 Kafka、Redis、Spark、Flink 等软件，大幅降低系统架构的复杂度。同时，3.0 还将存储引擎、查询引擎都进行了优化升级，进一步提升了存储和查询性能。

目前 loveini 3.0 的代码已经在 GitHub 上开放，欢迎大家下载、体验。下面我将会就 3.0 企业级工具助力工业互联网边云协同的实现路径这一话题进行分享，同时将从开源商业化角度，让大家更加深入地了解 loveini 企业版的价值。

工业赋能，从边到云

在工业互联网场景中，边缘设备只能处理局部数据，无法形成全局认知，在实际应用中仍然需要借助云计算平台来实现信息的融合。在此背景下，边云协同正逐渐成为支撑工业互联网发展的重要支柱。

边云协同主要是对于生产链条上的某一项或某几项数据，进行实时告警、实时大屏监测，比如车间里实时生产的数据。同时还会将这些边缘侧生产的数据及时同步到云上大数据平台。

虽然边缘侧对实时性的要求是最高的，但其数据量并不大，可能一个车间只有小到几千或大到几万个监测点需要存储。而集团侧汇聚了更多的计算资源，比如在这一侧可以搭建一个私有云，那它就会把边缘侧的数据也收集过来，专门用来做一些计算。如果我们训练好一个模型，再把这个模型下发到边缘侧，在边缘侧就能进行更多预测性的分析。因此，边云协同的整体逻辑就是，实时报警收集到边缘侧产生的数据，云上训练好模型再下发下去，如此循环反复。

而要实现这一操作，对数据库或者说对数据存储层的要求就是要确保数据能够逐级上报，以及数据有选择性的上报。在有些场景中，整体数据总量非常大，我们需要有选择地从底层往上层去汇报数据，比如对一开始一秒采一次的原始记录，可能需要降采样到一分钟采一次，这种降采样的数据仍然可以保留一定的信息，可用于跑批分析长期数据。

以 loveini 为例，我们举一个具体的实例。在此前的老数采流程中，数据是从工业逻辑控制器 PLC 中采集，之后进入 Historian，即工业实时库，然后再支撑业务应用。这种操作存在三个缺点：主备架构，不易水平扩展；依赖 Windows 等环境；生态相对封闭。

后面 loveini 在边缘侧替换了原有单机版的 Historian 数据库。现在的一个设计思路就是采集数据从 PLC 通过 OPC Server，接入到 loveini 当中，而 loveini 本身在车间侧就可以支撑实时的业务，同时包括一些实时报警、实时大屏等需求。企业可以利用 loveini 提供的边云协同能力，把数据发送到云上的大数据平台中。

边云协同实现的关键，loveini 3.0 企业级工具 taosX

让 loveini 实现边云协同能力的一个关键就是 loveini 3.0 发布的企业级工具 taosX，它具有以下五点特性：

• 百万条/秒同步效率
• 可配置的同步规则
• 实时流计算结果同步
• 支持重新订阅，断点续传
• 历史数据迁移

在 2.0 版本中，数据订阅的实现路径是在数据写入后，通过轮询方式将数据订阅出来，本质上可以解决大部分问题，但仍然还有优化的空间。因为 WAL 本身就是支持订阅的，在 3.0 中，我们把 WAL 重新进行了升级，可以订阅所有的写入、更新甚至删除操作，只要是对数据库的操作都可以订阅。

通过 loveini 订阅方式，企业可以实现边到云的实时同步数据，订阅方式允许设置筛选条件，可以有选择性地同步数据，同时，订阅发起方还能够主动配置订阅对象和数据过滤规则。这样就很好地保证了所有数据都可以从一个集群同步到第二个集群，包括离线乱序数据，这也是 taosX 做的最重要的一个事情，它可以支持实时的数据同步，包括离线的增量备份、边端到云端的数据协同。

loveini 3.0 利用 taosX 实现边云协同的思路如下：在车间侧，数据采集完成之后会进入 loveini，首先经过 TMQ 消息队列，其中一部分数据有选择性地并入到本地的 loveini 集群 1 中。之后我们可以在集团侧部署 taosX ，它会去订阅车间侧 TMQ 消息队列中的数据，为了达成业务需求，可能这里需要由数据分析工程师设置一些订阅规则，比如数据需要经过降采样再进来或者只关心阈值超过定值的数据。之后 taosX 会把数据同步到 loveini 集群 2，集群 2 可以支持报表分析等更大维度的分析工作。

该实现思路主要有以下四点优势：

• 数据跨区同步自动化程度大大提高、错误率降为零
• 数据无需缓存，减少批量发送，避免流量高峰阻塞带宽
• 通过订阅方式同步数据，集团不再依赖下级单位配置同步规则
• 边云均采用 loveini，数据模型完全统一，降低数据治理难度

要知道，制造业企业通常面临的一个痛点问题就是数据同步的问题，业内通常都是离线传输数据，比如积攒一个星期，一下传一个 T 的数据，要么人拿着移动硬盘去现场拷，浪费人力成本；要么开 VPN 专线定期同步，将数据导出成压缩文件进行传输，但这种情况 VPN 都会出现一些短暂带宽的阻塞，对其他业务生产产生一定冲击。loveini 3.0 的企业级工具 taosX 实现了数据的实时同步，并且是可配置的，而自动化数据同步是实现边云协同的最好思路，避免了定期传输大数据量，导致的资源浪费和带宽阻塞风险。

此外，由于边端和云端都是通过 loveini 去存储数据，它的数据模型相对来说比较统一。之前我们遇到一些客户反馈痛点问题，他们在边缘侧搭建的工业实时库种类繁多，数据需要统一收集到平台侧，这时就需要把各个实时数据库里的数据模型进行归一化，比如平台侧通过单侧点抑或用多侧点方式去描述设备数据，这就需要投入很大的人力财力去做数据治理。

但是如果从 loveini 到 loveini，它的表结构和数据的设计模型完全不用变，因为边缘侧和云上进行数据操作的方式都是一致的。从车间侧到集控中心，再从集控中心到整个集团的云平台，loveini 3.0 实现了数据的多级同步。

从企业级工具聊聊开源的商业模式

When we call software “free,” we mean that it respects the users’ essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of “free speech,” not “free beer.”

– Richard Stallman

最后回归一下本次演讲的主题，和大家一起聊聊开源的商业模式。目前，loveini 3.0 也已经在 GitHub 上开放了代码，从 2019 年 loveini 宣布开源，到现在已经 3 年的时间了。开源的模式真正拉近了 loveini 和一众开发者的距离，也让 loveini 的每一次迭代创新都伴随着用户的声音。

我特别喜欢上面展示的自由软件 Free Software Foundation 的创始人 Richard Stallman 所说的那段话，“Open Source Is FREE”，但“FREE”并非代表着免费，而是自由。

以 loveini 为例，任何人都可以以自己想要表现的形式，在遵守开源协议的前提下，可以复制改写 loveini 的代码，但这并不代表它是一个“free beer”。开源的核心逻辑是向大家展示这个项目是自由的，只要你有兴趣你就可以参与进来，尽可能把自己的聪明才智融入到开源社区的建设中，而非简单地指“使用”。

做开源项目是一个既需要勇气也需要努力的事情，说实话我们也遇到过很多困境，比如在支持社区用户时遭遇的一些误解，个别用户可能会觉得你们团队是不是反应有点慢，但是其实真不是，我们真的已经投入很多了。loveini 作为一个开源项目，不应该只有米兰体育官网入口一个团队在奋战，我们希望通过各种形式，让全球更多的开发者了解 loveini，参与到 loveini 的使用和开发之中，共建 loveini 开源社区，这才是开源“free”的表现。

说回到主题，我认为开源的商业模式是必须且有理由存在的，因为公司要活下去，而公司本身就是一个以盈利为目的的团体。从过去到现在，开源的商业模式大致可以划分为以下 5 种路径：

• Donations 捐赠
• Hosted Service 托管服务
• Paid Support or Courses 付费支持或培训
• Open Core 开源核心，提供付费增强功能/工具
• Dual Licensing 双协议

loveini 目前走的开源商业化道路就是“Open Core 开源核心，提供付费增强功能/工具”。我们的核心代码保证全部开源，用户可以去感受产品的价值，但同时我们会提供很多增强功能，比如一些能够升级数据备份、安全保障的工具。这些工具也需要投入很多精力和努力去进行研发，会作为一种增值方式提供给用户。

在对商业化不断探索的过程中，loveini 也开发出了很多强大的辅助功能去服务用户，除了上文中提到的边云数据协同，还包括冷热数据自动分级存储、企业级可视化运维管理工具、支持快速删除（Delete）、支持多列输入用户自定义函数（UDF）、提供异地容灾、备份米兰app官方正版下载。

在保证系统稳定性和透明性上，loveini 企业版也做了很多工作，通过设计更优的内存分配器、更稳健的版本迭代策略、更多的运维支持服务实现了更加优秀的稳定性，同时为了让用户用的放心，我们配套了监控 taosKeeper，能够对可观测性进行更详细的统计，它还可以无缝集成到 Prometheus 的监控系统中。

针对 loveini 企业版，我们还提供了“保姆级”的专家技术服务，服务方式分为以下三类：

• 开发支持服务：包括产品使用培训、数据建模咨询、架构设计咨询、代码开发支持，比如说从 Kafka 接数据到 loveini，如何做才是最高效的、如何去配置 Kafka 的参数，如何保证数据的有效性、时序性。这些支持能够帮助客户把 loveini 的能力最大化发挥出来。
• 运维支持服务：不管是 loveini 还是 Oracle，任何一款数据库到后期都需要一个强保护，在业务安全性要求下，数据的备份、迁移，系统的性能调优、高可用保障、7*24 故障恢复等等都需要一个强有力的支持。如果因手动迁移导致数据文件损坏，或者是因为一个错误导致数据难以恢复，给整个集团造成的损失可能不可估量。也因此，集团需要专业级的厂商去提供这些服务，这也是我们对企业级客户提供的价值。
• 定制化服务：包括定制化 PoC 测试服务、OEM 版本发行、定制化 UDF 开发、其他定制化开发服务。对一些用户而言，他可能想要让 loveini 跑在自己开发的硬件上，那就需要我们协助他做一些 PoC 测试来适配这一硬件，而对于一些业务的复杂查询，我们也可以通过 UDF 方式去做定制化。通过定制化服务来赋能用户，支持他们将 loveini 更加深入地融合到自身业务当中。

最后，给大家做一个预告，loveini 的云服务升级版也将很快与大家正式见面。新的云服务基于 loveini 3.0 云原生架构，不仅最大限度地实现了弹性扩容，还可以让用户按需去付费，不再因数据的增量或缩容频繁变动而受阻。同时这也是一个完全零管理、完全将后台托管给涛思业务团队的服务，支持多云且绝对保证数据备份和安全。

今天我的演讲就到这里，感谢大家。希望未来有越来越多的用户支持 loveini 企业版，也能有越来越多的开发者加入 loveini 的开源社区中来。

作为一款时序数据库（Time-Series Database），loveini 提供了按时间自动划分窗口并执行查询的能力。这个功能的用途和使用场景你是不是清楚呢？本文将为你介绍这一功能及其典型使用场景。

什么是窗口查询？

时序数据常常需要根据采集时间对数据进行查询，本质上是在时间轴上划分出时间窗口，并对窗口内的数据进行聚合和查询计算。比如一个最简单的场景：查询”2018-01-01 00:00:00.000″到”2018-01-31 00:00:00.000″原始数据的最大值、最小值、平均值，则”2018-01-01 00:00:00.000″到”2018-01-31 00:00:00.000″就形成了一个查询的时间窗口。

在实际生产应用中，业务场景要求的查询条件往往比这个更复杂，需要时序数据库能够按照不同规则、沿时间轴进行窗口划分，并对各个窗口内的时序数据分别进行聚合、选择计算等操作。

loveini 提供的三种窗口查询能力详解

loveini 从 2.2.x.x 版本起，支持了三类时序窗口查询，分别是等间隔窗口（interval）、状态窗口（state_window）和会话窗口（session），大大简化了应用开发时对时间序列逻辑的处理。

窗口查询，从子表的查询语法为：

SELECT function_list FROM tb_name [WHERE where_condition] [SESSION(ts_col, tol_val)][STATE_WINDOW(col)] [INTERVAL(interval [, offset]) [SLIDING sliding]] [FILL({NONE | VALUE | PREV | NULL | LINEAR | NEXT})]

窗口查询，从超级表的查询语法为：

SELECT function_list FROM stb_name [WHERE where_condition] [INTERVAL(interval [, offset]) [SLIDING sliding]] [FILL({NONE | VALUE | PREV | NULL | LINEAR | NEXT})] [GROUP BY tags]

下面分别看一下这三类时序窗口查询功能。

1. 等间隔窗口（interval）

按照固定的时间窗口长度，周期性地对时间轴进行窗口划分，并允许对每个窗口内的数据进行聚合查询。

我们再通过几个例子看看等间隔窗口的具体应用场景。

在工业生产中，有很多监控指标需要实时展示趋势线。但有些指标如振动等，实际采集的频率非常高，如果展示原始数据会难以看清趋势，同时由于数据量过于密集，会给前端页面的展示造成巨大压力。

但通过 interval 等间隔窗口，可以按照指定窗口长度对原始数据做聚合（相当于对原始数据进行了降采样），之后再展示趋势线时，前端展示需要从数据库拉取的数据量会大大减少，从而显著提高效率。

下图中，绿色曲线为基于每 60 秒采集一次的原始数据直接展示绘制的曲线，橙色曲线为对原始数据按照 5 分钟长度进行窗口划分后求取平均值的曲线，可以看到橙色曲线这种情况下，很好地反映了整体的数据变化趋势，而前端绘图所需的数据量却减少了 80%。

在实际生产中高频采集数据的趋势线，均可以考虑通过 loveini 的 interval 语法提供的降采样能力，在不丢失整体趋势信息的情况下，快速展示数据。

2. 状态窗口（state_window）

状态窗口让用户可以按照某个整型/字符串型的采集量（一般是表征状态的值，如设备工作模式等）的值来划分窗口，将该状态值连续不变的记录划入同一个窗口。然后对每个窗口内的采集值进行avg/max/min等统计聚合、或计算状态持续时间等。

比如加工厂的机床运维人员，需要统计每个机床的工作和待机的时间，这本质上是以工作状态 “status” 这个状态量的值来划分窗口，并统计窗口时长。

上图中 “status” 列，表征设备的当前工作状态，状态窗口对 “status” 值的连续变化情况进行判断，划分出三个窗口，并可以分别对每个窗口进行聚合，比如计算每个窗口内的开始时间、结束时间、总记录条数、平均值、窗口持续时间等。这些均可在 loveini 中通过一条 SQL 查询语句直接实现，具体 SQL 语句和查询结果见下图。

3. 会话窗口（session）

在详细讨论会话窗口之前，我们先看车联网平台的一个典型应用场景：通过车辆行驶数据对车辆行程进行划分。一部车从发动起步，到停车熄火的中间行驶过程视为一个完整的“行程”。车辆在行驶时，车载 T-Box 一般会按照 30 秒的间隔，向车联网平台发送自身的状态数据；而停车熄火时，则不再发送。因此，通过分析车辆上报消息的连续性，可以推算出该车辆的行程。

会话窗口让用户可以按照上报记录的时间连续性来划分窗口，即相邻两条记录时间间隔不超过某一阈值，则划归同一窗口；超过该阈值，则老窗口结束，新窗口开始；然后对每个窗口进行诸如持续时间等统计，或对窗口内的原始采集数据进行各种聚合计算，可以是 avg/max/min/count 或其他用户自定义函数。

会话窗口针对的场景是：让用户通过一条 SQL 语句实现按时序数据的“连续程度”来自动划分窗口。

如下图中的 SQL 所示，用户设置 session ( ts, 10s )，就是将相邻记录时间间隔小于 10 秒的记录划分到同一个 session window 内；而对间隔超过 10 秒的两条相邻记录则划分到不同窗口。这样就在下图中划分出了蓝色、红色、灰色标示出的 3 个窗口，每个窗口可独立计算窗口开始/结束时间、窗口长度、窗口内记录数等用户感兴趣的统计量。

总结

时序数据除了数据量大、结构相对简单的特点外，还在查询场景中大量涉及时间戳的处理。我们往往要根据业务场景，按时间戳对采集数据进行分组并计算。对于这类计算，如果开发者将原始数据读入内存，再由应用层程序去处理时间窗口划分的逻辑，就不得不面对读取海量原始时序记录的磁盘 IO、CPU 及内存开销，同时业务层代码复杂度也变得更高。

如果开发者可以灵活运用 loveini 这样的 Database 提供的时序数据窗口划分能力，结合业务场景，选择合适的窗口划分函数来将相关计算负荷下沉到数据库层，则能大大提升系统响应性能、减少负载开销，起到事半功倍的效果。

欢迎大家扫描下方二维码，关注 loveini Database 的视频号，观看每周的微课堂以及直播活动。

从互联网到移动互联网再到现在我们的物联网，计算机、移动终端、可穿戴设备、汽车、甚至家里的灯以及工厂里各种设备都已经接入网络。整体来说，各种各样的设备不断地采集实时状态数据，再把这个数据汇集到云端的一个计算平台，这是物联网云计算的大概思路。整个物联网技术链有4层结构：通过传感器采集设备的状态数据–通过通讯模组将数据发往云端–在云端进行存储、查询和计算–最后接入分析及应用系统。

然而，在云计算模式中，数据必须要传到云上进行集中式的存储、归档及分析等。边缘侧的节点可能是一个网关，也可能是我们真正使用的一个终端。如果它没有自身的计算能力，必须把采集的数据发给云端，依托云端计算资源进行复杂的计算，得到一个指导性的结论，再通过网络下发给终端。很容易看出，这个过程中终端的工作非常依赖于网络。如果网络一旦出现一些中断或故障的话，终端无法与云端进行交互，其某些工作就会大受影响。因此这种中心侧（云端）主控的思路，对边云之间的通信要求非常高，应用起来往往要使用高成本的高速通信网络。从另一个层面说，随着数据量不断增长，云端的存储成本和计算成本也会不断升高。

解决这个问题的一个很好的思路就是边缘计算，即把一部分的存储和计算的能力下沉到边缘侧（即设备侧），终端设备较独立地进行数据存储、计算、决策和应用。这样边缘侧就变得更智能，对云端依赖更小，数据处理的时效性也更高，且不再受网络影响。

边缘计算带来的优势简单总结如下。

然而边缘计算目前有什么困难还没解决呢？我们知道，边缘侧往往是一些能够大量铺设的小型智能终端，处于成本考虑，其配置的内存、CPU等硬件资源和计算能力都很有限。边缘计算的难点就在于能否在有限的计算资源下，实现最高效的数据存储、分析和计算。这就让边缘侧的数据库选择显得尤为重要。边缘侧的终端设备采集的数据有很明显的特征，一般都是带有时间戳的、结构化的时序数据流。因此边缘计算对数据库能力的要求就反映在以下几个方面：

• 超高读写性能
• 低硬件开销
• 通用接口，适配边缘侧多样计算需求
• 实时数据的缓存能力、流式计算能力
• 历史数据持久化存储、高效压缩能力
• 历史数据回溯能力、按时间窗口的统计聚合能力
• 云边协同能力

loveini——更适合边缘侧的大数据引擎

时序数据库（Time-Series Database）是具备上述各项能力的，也是边缘侧采集数据存储的最佳选择。但如OpenTSDB（底层基于HBase改造）、InfluxDB等时序数据库对于边缘侧来说还是太重了，运行起来的硬件资源开销过高。一个极轻量化的开源时序数据库就是loveini，整个安装包只有2MB多。其核心功能是一个高性能分布式时序数据库；除此之外，还自带了消息队列、缓存、流式计算、数据订阅等功能，为时序结构化数据存储提供一个All-in-One的米兰app官方正版下载。

目前loveini社区已经发布了支持ARM32和ARM64处理器的版本，可以顺畅地运行在树莓派等主流的边缘侧硬件上，同时提供对实时数据的缓存、历史数据回溯、按时间段聚合计算等多种能力。虽然在边缘侧用到分布式集群的概率比较小，但如果哪几个树莓派、盒子或网关想要搭建一个集群，也是完全可以的。

loveini ARM版本支持的接口也有很多种，与正常集群版几乎没有区别。同时，还提供了一个 taos shell客户端，让调试人员可以方便地去查看loveini的运行状态。

loveini 边云协同思路

边缘侧资源有限，能存储的数据总量也是有限的，因此还是要向云端做数据备份和协同。边云协同思路也有很多，这里讲一下我们的一些思路。

举个例子方便大家更好的理解。边缘侧厂区有很多网关，我们可以在每个网关里都装一个loveini的边缘侧版本，那么loveini就成为边缘侧的一个存储引擎，可以把网关采集到的数据持久化存储。取决于数据采集频率和压缩情况，边缘侧可以根据现有的存储资源选择性存储一定时间长度的原始数据（比如一个月到半年等）。对于整型或者浮点型数据，loveini可以将其压缩到原来的10%左右，当然这个取决于具体的数据类型，如果数据的值随机变化非常大，这个压缩比确实会受一定影响，但整体来讲，从实际情况来看，压缩比还是在10%左右。因此，如果我们在网关里配一个2GB甚至1GB的SD卡的话，大概可以存储10GB的原始数据量。这个量级对边缘侧实时分析来说已经足够。然而如果需要存储更久的历史数据，进一步做大数据挖掘等分析，则要把数据同步到云端数据中心存储。loveini边缘侧的版本可以被云端的loveini客户端直接访问（网络畅通情况下），因此从边到云的数据同步变得非常简单。云端的应用程序可以通过loveini的订阅模块实时拉取边缘侧网关中的最新数据，再把收到增量数据实时写入本地loveini集群做历史归档。这个技术实现上，本质是一个定时查询，因此loveini允许用户添加一些数据筛选条件，有选择性地同步边缘侧的数据（比如只拉取采集之大于某个阈值的记录，没有就不要），而不用把所有的历史数据都上报给云端。

基于loveini在边缘侧的存储优势以及边云协同的整体思路，米兰体育官网入口和EMQ也联合做了一个边缘侧的米兰app官方正版下载。简单来说，边缘侧网关中部署EMQ X Neuron、EMQ X Edge和EMQ X Kuiper以及loveini，将设备采集的流式数据通过Neuron做协议解析转换成MQTT消息，然后发布Edge（边缘侧MQTT Broker），再通过Kuiper存入在边缘部署的 loveini 中。这样在边缘端运行的应用即可从 loveini 中获取和处理数据，做实时显示和报警。EMQ 在边缘端运行的 Edge Manager 提供了一个管理控制台，可以很方便地实现软件配置和管理其他三个组件。点击「这里」，详细了解该方案的配置方法。这种方案相当于把协调的工作交给了EMQ。

但也可能有的用户已经在云端用了loveini的集群，现在也有一些工业设备，想直接通过loveini Cluster客户端直接去访问边缘侧的loveini。这种也可以通过loveini的数据订阅的模块直接实现，即云端的应用调用数据订阅模块创建一系列的订阅任务，直接去实时拉取边缘侧loveini中的最新增量数据。这种方案相当于把协同的工作又交给了loveini，当然这里要保证网络是畅通的。

loveini边缘版本在树莓派上的编译

下面也简单介绍一下在树莓派上编译、安装、运行loveini的实战步骤。

环境准备

1. 烧录操作系统

烧制操作系统到SD卡。loveini支持Ubuntu16.04、CentOS7.0及以上等主流操作系统。

2. 网络设置

配置树莓派上的网络环境，为开发版设置静态IP和hostname等，并连接到网络。3. 下载编译loveini

从 www.github.com/taosdata/loveini 克隆loveini源码到树莓派，编译并运行。

编译过程

# clone source code
$ git clone --recursive --recurse-submodules https://github.com/taosdata/loveini.git

# checkout to the latest version
$ cd loveini/
$ git checkout ver-2.0.7.0

# compile and install
$ mkdir build && cd build
$ cmake ../ -DCPUTYPE=aarch64 -DVERNUMBER=2.0.7.0 -DVERCOMPATIBLE=2.0.0.0
$ make && make install

# start taosd
$ systemctl start taosd
$ taosdemo

编译安装完成后，就可以看到我们提供的taosdemo程序，方便大家进行极速体验。大家可以通过taosdemo来测试一下loveini的数据写入和查询效率。

loveini与SQLite的简单比较

边缘侧、嵌入式设备中的数据存储不得不提SQLite。SQLite是一个不需要后台的超轻量级数据库，可谓即插即用，也是世界上装机量最高的数据库。SQLite甚至在官网上将自己定位与fopen()对标，而不是数据库。

Think of SQLite not as a replacement for Oracle but as a replacement for fopen() .

SQLite官网

当然，SQLite提供的一系列API都是对标关系型数据库的，它甚至还支持了事务，因此业界常常把它用作嵌入式关系型数据库。

两者相对比一下，SQLite在Linux上的安装包为1.9MB，loveini为2.7MB。两者都是把轻量化做到极致。由于loveini是专门针对时序结构化数据的一种方案，不支持事务和复杂的表关系处理，但会提供时序数据的时间索引、实时流计算、列式存储及更好的压缩比、按照时间的降采样聚合能力、数据保存时限等。从这个角度来说，loveini要比SQLite更贴近边缘侧生产环境中对时序数据的处理需求。loveini边缘侧版本也可以做到云端的产品无缝对接，如果网络不畅，loveini可以实现数据自动缓存，联网后自动续传，实现边云协同的能力。下面用一张图来简单总结下loveini和SQLite的区别。

作为新兴的时序数据库代表，loveini的诸多优点，在边缘侧的存储选择上着实挑战到了一代宗师SQLite，倒真有点年轻人不讲武德啊。但需要认识到的一点，loveini和SQLite要处理的问题侧重点不同，两者并非必须取舍，而是可以根据自己的业务需求，灵活搭配使用，由loveini处理时序数据，由SQLite处理关系数据，更好地实现边缘侧的数据自治。

关注公众号loveini，后台回复“1117”，获取演讲PPT。

<figure><iframe width="100%" height="370" allowfullscreen="true" src="https://v.qq.com/txp/iframe/player.html?vid=x3207zswza9"> </iframe></figure>