重新设计大量传感器数据的存储

Question

我的任务是实施/重新设计一个解决方案，该解决方案将存储来自传感器阵列的天气数据。该阵列将由大约 40 个塔组成，每个塔有大约 10 个传感器，每个传感器将在不确定的时间（年）内以 10 秒的间隔对大气条件进行采样。此任务的一些应用程序和要求如下：

• 管理和检索塔/传感器配置以了解数据分析。
• 用于气象观测的传感器或时间间隔的数据可视化。
• 为客户提供可靠且持久的数据资源/数据集，以比较模型和传感器的性能（可能需要一些后处理才能以所需的格式交付？）。

注意：当前的解决方案（作为概念验证实施，有 5 个塔）将数据存储为平面文件（每小时一个文件）。

我原本不确定这是否会构成未来的大数据问题，所以我研究了关系数据库和 NoSQL 数据库的几个解决方案，但我觉得我需要更多的指导，因为我不是数据管理专家。

我认为的解决方案之一是将数据存储在由塔、传感器和时间戳索引的关系数据库中，并按日期对表进行分区。

另一种基于未来扩展的方法是将其存储在文档类型的 NoSQL 数据库（如 MongoDB）中，并模仿当前解决方案的结构。

这些有什么好的方法吗？如果没有，什么是更好/推荐的解决方案？另外，是否有必要重新设计当前的解决方案？有人告诉我，使用平面文件的理由是他们认为关系数据库会占用太多开销。如果是这种情况，有没有办法避免这种情况？

Answer 1

由于 (a) 您正在使用的信息本身似乎是一种非常宝贵的组织资源，并且 (b) 数据量将相当可观，因此我决定 (c)在其中一个基础上构建关系数据库主要的 SQL 平台。

当然——从非常普遍的角度来看——需要三个基本因素：

1. 一个明确定义的概念模式，其中一个必须识别和精确标注出来的东西，即原型实体类型（包括它们的属性和相互关系），在您使用（例如，工作业务环境相关的塔和您提到的传感器）。

   如您所知，这一点需要与业务专家建立持续而富有成效的沟通。

2. 甲逻辑反映准确的概念层次，借助于布局表保持阱分隔（即，数学关系）的列与相应的列名和类型（即，关系属性）和所有相应的约束，以确保数据符合上一层确定的所有规则。

   因此，正是在这里，关系模型的巨大力量发挥了作用（尽管它的优势在其他抽象层次上具有积极的影响）。

3. 例如，提高“动态”逻辑数据操作操作的执行速度并保证逻辑约束的物理布置。

   由于关系模型提供物理数据独立性，因此数据库管理系统（简称 DBMS）可以提供该级别的任何类型的结构，而不仅仅是索引，以支持逻辑定义。在领先的 SQL 平台的情况下，是的，这通常意味着，准确地说，根据特定于数据库的查询趋势设置索引策略，并且您对一些可能的配置提出了非常有趣的考虑，但不知道具体的准确的信息需求，在这方面提供具体建议是不合适的。

   其他值得评估的元素是，例如，升级网络基础设施以增加带宽，启用适当的服务器配置（硬件和软件方面）等。而且，如果且仅当从业者足够合格时，他或她甚至可以修改所选 DBMS 的源代码（在开源环境中自然更可行）。

这样，您突出的以下几个方面

• 管理和检索塔/传感器配置以了解数据分析。
• 用于气象观测的传感器或时间间隔的数据可视化。
• 为客户提供可靠且持久的数据资源/数据集，以比较模型和传感器的性能（可能需要一些后处理才能以所需的格式交付？）。

将得到很好的解决，因为您可以很容易地声明查询，例如，以非常有意义的形式获取信息。例如，您可以获得与

• 由 SensorNumber 标识的传感器1750，安装在由 TowerNumber 标识的塔上31，介于 Date1 June 2017和 Date 之间27 June 2017。

此外，由于 (1) 关系数据库中的数据在基于关系代数的操作的帮助下根据集合进行逻辑管理，以及 (2) 不同的 SQL 引擎针对集合进行了物理优化（有些比其他引擎优化）处理，你可以，例如，

• 将集合a与集合b进行比较；
• 将集合c与集合d 连接起来；
• 通过对集合e的限制得到子集f；
• 从n 个交集产生n个子集；
• 项目f 中的n 个属性
• 从集合z中检索信息，该信息是集合x与集合y并集的结果；
• 等等。

数据操作的可能性实际上是巨大的——展示了关系范式无与伦比的多功能性——因为您不仅可以处理基表（用CREATE TABLE … ( … );语句声明的表），还可以处理派生表（通过SELECT …;操作表达的表，有时固定为VIEWs） . 换句话说，您可以 (i)基于 (ii) 对 (iii) 单个底层关系构造（即数学关系）进行操作的先前数据结构来表达新数据结构。

显然，关系数据库的基表和列的排列可以发展，并且 (a) 新的基表或列可以合并到其中时 (b) 跟踪新的实体类型或实体类型属性被认为是值得的相关的业务背景。换言之，无论初始结构也不关系数据库的开口约束预计是静态的或不可变的。此外，当新的信息需求出现时，从一开始就适当组织的数据库往往更容易修改。

与上述考虑一致，适用集合的逻辑格式必须在数据库逻辑级别以声明方式生成。这些集合的图形或表示格式（例如，所使用的颜色或字体）必须依次通过一个或多个应用程序的代码进行处理（是的，主要以程序方式，也许在对象的帮助下）面向的框架、HTML 等），以便用户友好地访问和展示此类集合。当然，您也可以使用与数据库连接的报告软件。

相关性数据库的建模

鉴于您将使用传感器数据（其中，除其他功能外，通常涉及时间序列形式的信息），您可能会在@PerformanceDBA的两个特殊答案中找到多数据库设计和整体管理原则的帮助，题为：

• “关于传感器/读取/警报数据库设计的意见”，以及
• “历史/可审计数据库”。

关系、平面文件和 NoSQL 方法

在关系模型由埃德加·弗兰克·科德博士，虽然出版于1970年，真正的仍然是最现代和优雅的方法（基于逻辑和集合论），以应对数据管理的问题。反过来，不同的 SQL DBMS 是关系理论中提出的系统最流行的近似值（虽然不完全兼容，但确实很强大），其中一些已经过大量优化（例如，关于它们的物理-级别机制）甚至几十年。此外，主要的 SQL 平台当然可以（并且将能够）非常有效地使用最新的存储（例如，硬盘驱动器）和处理（例如，CPU）技术。

当建立在强大的 DBMS 上时，在概念、逻辑和物理层面上适当设计的关系数据库将绝对成为一种自包含、自我描述和自我保护的资产，它 (1) 值得信赖，(2) 提供快速响应，如您所知，这两个方面非常重要。

平面文件

因此，接下来的主张

有人告诉我，使用平面文件的理由是他们认为关系数据库会占用太多开销。

很容易被丢弃，因为平面文件方法是：

• 前科学;
• 远非大量数据的最佳选择；
• 太麻烦；
• 依赖于应用程序（并且您必须手动实现适当的 DBMS 原生提供的大部分功能）；
• 它的性能很容易受到破坏；
• 等等。

而 - 更方便 - 关系时尚，至少可以说：

• 将提供很大的可扩展性（它与物理级别无关，因此您可以根据需要增强底层物理机制）；
• 将带来一种简单的风格来操作数据（通过抽象操作）和
• 可以同时使用多个应用程序（例如，一个或多个移动应用程序，和/或一个或多个网络应用程序，和/或一个或多个桌面应用程序等）。

但是，如果您选择使用平面文件，您应该评估使用像Awk这样强大的实用程序，虽然它不是 DBMS（并且不是这样设计的），但提供了方便的资源来处理文件、记录、字段等. 有关此主题的更多信息，请参阅GNU Awk 用户指南。

无SQL

“非结构化数据”和相关术语

根据他们的宣传，使用 NoSQL DBMS 的最初理由是它们旨在用于涉及处理“非结构化数据”的业务领域，因此需要提出以下问题：

• “非结构化数据”的表达应该是什么意思？

在这方面，必须指出，就其本质而言，数据是结构化的；如果它没有结构，那么它就毫无意义，因此这样的东西 (i)不能被视为数据，并且 (ii)不值得管理。因此，“非结构化数据”是一个矛盾且令人遗憾的表达方式。

这些上下文的其他短语是“半结构化数据”。该短语表明存在“部分”或“一半”结构化的数据，因此，根据上一段，只有结构化的“部分”或“一半”可以是实际数据，其余的“部分”或者“一半”只是一个无形的东西，因为它缺乏结构，不能称为数据。

可惜，NoSQL 营销中的另一个典型术语是“多态数据”。如果说这个词的意思是“具有多种不同形式的数据”，那么它实际上是普通数据，它一如既往地以多种不同的形式出现。而且由于它有很多不同的形式，那么它就呈现出很多不同的结构，所以这种“种类”的数据并没有什么特别之处。

不用说，数据和数据结构一直很容易受到变化的影响，那么这方面也没有什么不寻常的。

数据量增长

显然，通过计算机化系统管理的信息量多年来肯定在增长——并且会随着时间的推移呈指数增长，因为每天都在构建新系统——但这是一个事实，与信息本身的结构。

缺乏全面的理论基础

NoSQL 系统的一个关键限制（有不同的类别，例如基于文档和基于图的）是当前的产品都没有——尽管大量销售并标记为“现代”——拥有可靠的理论基础（如果有的话）它支持适当 DBMS 的三个最重要元素中的每一个，即用于数据 (a) 定义、(b) 操作和 (c) 收缩的工具。因此，NoSQL 方法实际上暗示着回归到一个古老的时代，在那个时代，数据的处理是在一个临时的、不健全的行动过程中进行的，它带来了所有不必要的复杂性。

如今，图形系统包含在“NoSQL”范围内。这些软件产品通过对两种不同结构的操作来管理数据：节点和关系——这再次与术语“非结构化数据”相冲突——并且它们在“NoSQL”组中脱颖而出，因为它们确实如此有数学基础。然而，图产品与网络平台相当相似，网络平台在几十年前就被认为已经过时了（一个明显的缺点是，如上所述，它们需要两种结构来表示数据，而关系型 DBMS——根据信息原则——只需要一个）。

即使与大多数 SQL DBMS 的起源相比，不同 NoSQL 系统的创建按时间顺序更新，但 NoSQL 产品所基于的大多数概念实际上是原始的。

NoSQL 程序应该主要在以下情况下使用，例如，

• IT 人员缺乏确定（或适时确定）感兴趣数据结构所需的技术技能——例如，由于其复杂性——；和/或
• 该组织无法为现有员工提供适当的教育和培训，或无法雇用具有所需教育和培训的新员工；和/或
• 当数据的完整性和一致性不是特别重要时；和/或
• 当将相关数据与需要高精度的任务关键系统的数据混合时，是不期望的。

但是，即使相关数据的结构在相关系统创建之前没有定义，一个或多个人也必须

• 发现上述结构，
• 丢弃所有周围的“干扰”和
• 收集并链接正确的数据

在数据库和应用程序进入生产阶段之后，为了能够充分利用投入到项目中的所有资源，数据结构描绘是一项无法绕过的任务，必须尽快完成或以后。

因此，虽然采用 NoSQL 方式是可能的，但前面提到的所有因素都必须考虑在内。

最稳健的方法

In contrast, approaching the informational requirements of a business environment in a relational manner —i.e., with a general paradigm behind— offers the possibilities of (1) managing the data in its natural structure from the beginning —which eases integration with other data sources— and also of (2) producing new trustworthy structures by dint of the manipulation of a single instrument —as explained in previous sections— that has a robust scientific basis.

According to your description of the scenario in question, you have already identified a particular structure in terms of the relevant organizational needs, so I suggest requesting that the business domain experts validate it. Successively, I recommend taking advantage of (i) the constructs —the relation, the constraints and the operations— provided by the relational model to handle said structure and the respective data, and of (ii) your SQL DBMS of choice which will very likely offer very efficient physical tools that can hold up the present demands and will supply future scalability.