数据历史记录器与时间序列数据库

作者：Jason Myers / 开发者
2024年3月13日

很容易将技术购买决策描绘成非黑即白，一方是乐土，另一方则是公司死亡和利润消亡的乌托邦荒漠。但这并不符合现实。

相反，组织需要权衡技术权衡与他们的需求。因此，虽然站在“撕毁并更换”的山顶上高喊新技术的优点很容易，但这并不是大多数组织愿意做的事情。

在工业和制造业领域，数据历史记录器是第三产业的关键元素，其中计算机扮演了中心角色。事实是，从第三产业到第四产业的进步是渐进的。一些公司可能从第三产业发展到3.5到3.7，然后最终进入第四产业。随着技术的发展和组织接受第四产业，它们应该如何适应？这些渐进式变化对每个组织而言都不同。

在做出任何重大决策之前，了解游戏中的参与者至关重要。本文中，我们谈论的是InfluxDB，一个专为时间序列数据库设计的数据库，以及传统数据历史记录器。

数据历史记录器：优点

数据历史记录器并非一无是处。如果一项技术——如数据历史记录器——在特定行业——无法很好地工作，那么它就不会成为该行业的普遍技术。

• 特定领域：供应商为工业和工业应用构建数据历史记录系统。这些系统专注于工业环境的独特特性和需求，并提供与PLC、SCADA、单个机器等协同工作的工具。
• OT集成：数据历史记录系统与运营技术（OT）控制系统和标准紧密结合。
• 端到端：数据历史记录系统几乎具备工业操作员所需的所有功能。更新的数据历史记录系统甚至提供丰富的用户界面来可视化数据。数据历史记录系统更像是一个“一站式”解决方案，在单一解决方案中提供广泛的特性和能力。它们可能不是现成的，但它们比DIY更接近这一目标。

数据历史记录系统：缺点

虽然这些优点听起来都很不错（这就是为什么它们是优点），但我们必须记住，考虑的背景是向工业4.0的转变。数据历史记录系统是很好的自包含解决方案，但当你想要对你的数据做更多的事情时会发生什么？

• 遗留技术：封闭的软件系统创造了“围栏花园”，限制了组织的适应、创新和增长能力。数据历史记录系统是为一项工作设计的工具。但如果多人需要使用相同的数据来完成不同的目的？这导致了下一个观点...
• 供应商锁定：“围栏花园”使得与现代数据生态系统集成变得几乎不可能。封闭的、专有的软件使得与供应商愿意支持的工具之外的工具集成变得困难，甚至不可能。随着其他系统的进步，新的协议和标准出现，供应商优先考虑互操作性，封闭的系统限制了你可以用你的数据做什么。
• 数据孤岛：这些系统通常在本地运行，所以当你的数据历史记录系统无法连接到其他系统时，历史记录中的数据就会变成孤岛。一些组织甚至可能在一个地点运行多个数据历史记录系统。这些系统的封闭性质阻止了用户跨系统汇总数据并得出见解——这是限制你从数据中创造价值的能力的另一个因素。如果其他系统无法访问你的数据，那么它们也无法从中受益。
• 成本：由于它们是如此专业的系统，数据历史记录系统往往很昂贵。如果可用，定制更改既昂贵又耗时，因为供应商致力于他们的专有标准，并且开发资源有限。

InfluxDB：优点

• 开放技术：InfluxDB建立在开放技术之上，为应用程序开发提供了很大的灵活性。利用现代技术和开放标准，用户可以访问一流的服务和工具。这些功能使团队能够更快地适应、增长、开发和迭代应用程序。访问更大的生态系统、API、连接器、广泛采用的工业协议和第三方工具，让开发者可以选择他们喜欢的工具，并将它们与InfluxDB集成。可访问性和互操作性是工业4.0的关键组成部分，这就是TSDB如InfluxDB发光的地方。
• 查询语言：InfluxDB支持SQL和类似SQL的InfluxQL查询语言。SQL基本上是数字时代的通用语言，大大缩短了许多用户的启动时间。有多个方式查询数据为用户提供了额外的灵活性。InfluxDB还支持多种语言的客户端库，使写入数据变得更容易。
• 可扩展性：有几个关于可扩展性的方面值得提及。首先，是数据库资源和基础设施。作为一个云原生数据库，InfluxDB 提供了全托管服务。位于主要云环境中，使得 InfluxDB 能够根据用户需求进行扩展和缩减。另一个方面是它能够扩展以满足不断增长的数据摄入需求。《InfluxDB 被设计用来处理大量时间序列数据集而不会影响性能》。
• 降低存储成本：这对于希望利用预测分析和其它高级分析以及人工智能工具的工业组织尤为重要。这些组织需要高度细粒度的历史数据来不断喂养和训练人工智能和机器学习算法。存储这些数据可能很昂贵，这就是为什么 InfluxDB 将计算和存储分离，并利用多个存储层。对于不常访问的数据，《冷存储》可以存储在低成本的对象存储中，并且可以《将存储成本降低90%以上》。
• 多种部署选项：InfluxDB 是云原生数据库，但也为希望或需要控制其基础设施的用户提供了本地部署选项。边缘部署的单节点实例也允许组织将数据收集和处理更靠近数据源，如果需要的话，还可以将这些数据《复制`回集中实例。

InfluxDB：缺点

没有一种解决方案能够始终如一地满足所有人的需求，数据库也不例外。这正是为什么存在专业数据库的原因。

• 非领域特定：InfluxDB 并非专门为工业或制造应用构建。它不具备数据历史记录器从一开始就内置并准备就绪的特性。添加这些特性需要额外的时间和精力。
• 构建与购买：当您选择像 InfluxDB 这样的时间序列数据库时，您从一开始就知道您需要构建一些东西。这需要领域知识（或者至少学习和投入时间的意愿）以及开发者资源。
• 堆栈需求：与构建/购买理念相关，因为 InfluxDB 并非领域特定，构建端到端解决方案需要使用更广泛的生态系统来获得与数据历史记录器相当的功能。一些组织可能不想——或者没有——学习或管理整个生态系统的资源。

部署：爬行、行走、跑步选项

回到我们最初的构想，在选择数据历史记录器和/或时间序列数据库时，您应该考虑您组织的需要和最适合它们的解决方案。

以下示例仅仅是示例。每个组织都会有不同的需求，需要不同的权衡，但希望这些示例能为您提供思考数据历史记录器、您的需求和时间序列数据库在画面中位置之间的关系的起点。

爬行

假设您的数据历史记录器对您的组织运行良好，但您对数字化转型很感兴趣。毫无疑问，您已经为您的 OT 堆栈投入了多年和大量资金，因此您不会因为实验而到处拔掉插头。

你可能采取的一种方法是使用Telegraf进行数据收集测试。本质上，你可以配置Telegraf从与你的数据历史记录器相同的数据源收集数据。你可能会想要从一个小数据集开始，以降低存储成本，因为你将相同的写入两个不同的地方。

但这样做可以让你知道在OT堆栈中定位InfluxDB的位置。它还提供了合法的生产数据供你实验，以了解你可以获得哪些见解。

步行

让我们将这个例子提升到下一个层次。记得我们提到过，一个工厂可能在同一地点运行多个孤立的记录器吗？那么，为每个记录器复制上述实验（但将每个Telegraf实例的数据输出到单个InfluxDB实例），可以使你结合这些数据流并打破这些孤岛。

使用像Grafana这样的可视化工具，你可以创建一个单视图来跟踪每个系统的个别性能以及它们的整体性能。

运行

一旦你了解了InfluxDB如何在较小的层面上与你的数据历史记录器一起工作，你就可以构建出这种集成。将更多系统和工具连接到InfluxDB。调查你可以使用的其他生态系统工具来替代数据历史记录器功能。开放技术的优点之一是你可以自定义这些替代方案以满足你的特定需求。

如果你正在扩展运营并且你的TSDB实验进行得很好，可能该是采用TSDB而不是昂贵的传统数据历史记录器的时候了。但重点是，你可以逐步采用开放标准和时间序列数据库。不需要彻底替换。你想要确保你使用的科技满足你的需求，因此你需要确保从数据历史记录器到TSDB的权衡是有意义的。

话虽如此，那些对数字化转型认真的组织可能会很快——而不是更晚——处于需要开放标准的连接性、互操作性和可访问性以保持竞争力的位置。传统技术之所以成为传统，是有原因的。但幸运的是，确保你的系统具有未来性不必一蹴而就。在从3.0到4.0的产业过渡光谱上处于3.6是完全可以接受的。选择是存在的。你只需要确定对你组织来说可接受的权衡，例如成本、功能、能力等，并据此计划。

要开始尝试这些想法和InfluxDB，今天注册免费账户。

其他资源

• 替换数据历史记录器的战略方法
• 升级你的物联网/运营技术堆栈：用InfluxDB替换传统数据历史记录器