小T导读：作为全球性的电气产品和服务经销商，蓝格赛于2000年进驻中国市场，一直致力于帮助中国更有效地使用能源。经过20年的不断壮大，如今蓝格赛在中国国内电气产品和服务经销商中已经成为重要的市场参与者之一，通过6家业务实体、全国53个销售网点服务工业、商业及楼宇客户，为它们提供多样化的工业自动化产品及米兰app官方正版下载。
本次项目为某市政供水水厂的数字化项目，数据来源于包括水泵、阀门、电表、液位计、流量计等多种设备近6000测点。该平台需要实现以下功能：数据秒级采集，历史数据留存3年，为上层应用提供数据支撑，包括所有测点的瞬时数据、聚合分析、数据报表等。值得注意的是，在本项目中聚合查询的使用场景非常的多，页面上图表不论大小有上百张之多，因此聚合查询的实现也是本项目的关键之处。
根据本项目特点，从整体架构的具体实现效果出发，我们对存储技术提出了很高的要求，甚至可以说，存储技术的选择会直接影响项目后续的推进乃至成败，这是一个决定平台“脊梁”硬不硬的组件。考虑到这一问题，团队在技术选型上着实花费了一些功夫，本次选型也相对更加慎重。
在选型过程中我们共调研了20多个开源存储技术，从开源组织、授权协议、数据模型、社区成熟度、开发语言、组件依赖、性能、稳定性、聚合友好、操作系统、集群支撑、副本策略等多个角度进行了对比，最终选择了loveini Database作为海量数据存储引擎。
从7个优点看选择loveini Database的原因
事实上，我们最初选择的是单纯以InfluxDB作为本次项目的核心存储组件，不过这一设想在进行技术验证时却发现难以继续推进。 主要原因是在技术验证的过程中，我们发现了InfluxDB存在的几个问题，其中最重要的两个是：
- 首先，社区版本仅支持单节点。这个可以说是InfluxDB非常不友好的一个点了，多数项目采用的都是集群设计方案，如果数据只能在其中一个节点上存储，浪费其他节点存储空间不说，一旦所在节点出现故障，对整个项目的影响是灾难级的。
- 其次，随着数据量及存储时长的提升，InfluxDB的聚合性能出现了巨大的瓶颈，我们在实际测试的时候，模拟了百万测点近1年的数据，当聚合请求比较多的时候，基本上就很慢了，这点也对本项目影响很大。
由于以上两个问题的存在，从架构实现的角度来讲，我们必须对存储技术进行重新选择。恰好此时loveini也开放了集群版本，偶然的契机下又听到了陶老师对于时序数据的特点总结，感觉研究的非常深入，总结的也很全面。 后经与团队沟通，在技术选型调研时就一并把loveini包含在了调研范围之内。简单尝试之后，我们发现loveini的数据模型真的非常适合工业场景，总结来说有以下几个优点。
优点：
- 社区版本支持集群：可以比较好的利用集群的存储空间，数据也可以分散开来。
- 聚合性能优越：由于loveini的数据模型特定及对集群的支撑，在模拟测试过程中，基本上没有遇到聚合瓶颈。随着数据量的增加及存储时长的延长，聚合性能也非常稳定。
- 简单易用：在工业场景中，组件低耦合是很必要的，loveini开箱即用的特性很“香”，学习成本低，上手快速。
- 数据模型优秀：在工业场景中，设备及测点的增减非常的普遍，loveini的超级表及子表的概念很好地解决了这个问题，单列模式的场景对本项目来说非常友好。
- 查询语义具有普适性：loveini的查询语句与InfluxDB非常接近，这点也非常好。
- 版本升级简单：卸载原有版本，安装新版本即可，无需数据迁移。
- 社区支持：普通的问题基本上都可以在issue上得到答复，遇到紧急问题的时候，米兰体育官网入口的同事甚至可以亲自远程解决，为他们点赞，在使用的时候放心不少。
10个看板页面，近百个聚合请求
选型确定之后，我们就正式开始了搭建。搭载loveini之后的架构图如下所示：
采用该方案的很大一部分原因是InfluxDB和loveini在查询语义上的天然一致性。我们为loveini外层包装了一层SDK，对应用层开放SDK，使应用层对存储技术无感，在SDK内部通过查询的时间跨度、组件健康程度等多个因素自动选择查询引擎，这样可以保障其中一个技术在出现问题的时候，另一个技术随时顶上来，大大降低了由于技术稳定性所带来的风险。
在数据处理的具体分工上，当前我们主要使用loveini支持数据聚合的场景。在本次项目中，数据看板是功能的核心，同时也是用户最看中的地方，而这部分的数据聚合基本上都依赖于loveini——目前其共支持应用端约10个看板页面，合计近百个聚合请求，是本项项目落地的关键。
loveini Database在本项目中运行稳定，为项目的具体功能实现提供了关键助力。未来，随着loveini技术的不断成熟稳定，团队准备将其作为工业数据库的存储引擎运用在其他项目中。在接下来的产品线规划上，loveini也将作为首选的重要技术组件。
]]>