物联网嵌入式数据库的来龙去脉

虽然物联网 （IoT） 的许多方面都已经到位，但用于管理物联网传感器数据的数据库仍然存在一些障碍。在与 hamsterdb 的 Christoph Rupp、ITTIA 的 Sasan Montaseri、McObject 的 Steve Graves 和 ScaleDB 的 Mike Hogan 的圆桌会议中，我们探讨了当前限制嵌入式数据库、扩展和保护 IoT 数据库的因素，以及用于管理和分析传感器输入的可用工具和技术来自连接的嵌入式设备的海洋。

当前嵌入式数据库和数据库管理系统 （DBMS） 的瓶颈在哪里，尤其是与物联网相关的瓶颈？

MONTASERI，ITTIA：嵌入式数据库将根据其所在的系统类型具有不同的数据库。我们将传感器、移动设备、物联网网关设备和嵌入式系统视为物联网系统的重要组成部分，每一个都面临着不同的数据管理挑战。

对于传感器而言，内存和闪存介质等有限资源是最重要的瓶颈，因为它们通常会产生源自单一来源的数据流。对于物联网网关，并发读取访问的写入性能很重要，因为设备将从多个传感器或类似设备收集数据。对于移动设备，主要瓶颈是无连接时数据的可用性。对于嵌入式系统，这些子系统的互操作性和可维护性非常重要。

GRAVES，McOBJECT：设备上嵌入式数据库系统的障碍，在许多情况下，与其说是 DBMS 本身的障碍，不如说是嵌入式系统（设备）的限制。例如，虽然 McObject 的 eXtremeDB DBMS 是在 2000 年明确为嵌入式系统编写的，重点是高效率和“占用空间小”，但它仍然需要至少 24 位内存地址（24 位指针），实际上大约需要 1 MB 内存。eXtremeDB 数据库系统核心的代码大小约为 150 KB，它至少需要 40 KB 的 RAM 用于数据库字典和其他运行时元数据，例如事务缓冲区、连接/事务/对象句柄、等等然后你需要内存来存储数据本身，或者如果它是一个持久性数据库，则需要缓存。

16 位系统根本无法为 DBMS （64 KB） 寻址足够的内存。尽管您可以将 DBMS 挤入该空间，但它不会为元数据、应用程序代码等留出空间。另一方面，一个 24 位指针可以寻址 16 MB——为 DBMS 和应用程序提供了足够的空间。

RUPP、hamsterdb：收集传感器数据或其他数据大多需要存储，但不一定是数据库。特别是处理能力低的设备会将其数据传输到服务器进行后处理和分析。瓶颈通常是用于将数据传输到中央服务器的 I/O 写入性能或网络吞吐量。提高 I/O 性能主要是金钱问题，因为更好的设备成本更高。

但是，通常可以在不牺牲数据质量的情况下应用策略来减少数据量，例如每秒仅存储一个平均值而不是许多离散值。此外，传感器数据通常不会随时间发生太大变化，因此可以很好地压缩（图 1，表 1）。整数压缩不是 CPU 密集型的。即使是低成本的 CPU 也可以每秒压缩数百万个整数，从而大大降低了存储需求。通过一些创造力，通常可以创建针对特定数据模式优化的定制解决方案。

在流行的数据库开发语言中，哪一种最适合物联网中的嵌入式数据库部署，为什么？

GRAVES：对于设备上的数据管理，SQL 可能不适合绝大多数用例。我们认为 C/C++ 和具有快速原生 API 的 DBMS 是最合适的。对于具有足够资源的嵌入式系统，其中一台嵌入式 Java 机器（例如 Aicas 的 JamaicaVM）可能是合适的。SQL 将过于占用资源。任何 SQL 实现的代码大小都将比非 SQL 解决方案大得多——不要与“noSQL”混淆——并且对于任何给定的工作单元会消耗更多的 CPU 周期。

设备上的嵌入式数据库系统将主要用于收集数据、基于该数据采取一些行动，并对数据进行一些处理/操作。这些操作不需要也不会受益于 SQL 语言的健壮性和复杂性。设备不会执行复杂的（当然也不是临时的）查询，这些查询涉及具有复杂过滤和排序的多个表。

另一方面，在设备的上游，用于收集、聚合和以其他方式处理物联网生成的大量数据的 DBMS 肯定会受益于 SQL。

HOGAN，SCALEDB：对于后端系统，即那些聚合和处理数据（分析、执行触发器等）的系统，大部分挑战是处理海量数据，这与来自间歇性推文或发布的人类数据不同。

MySQL 使用 SQL。它适用于在线事务处理 （OLTP） 用例，主要用于 IoT 的后端——不是设备端，而是网关和后端。大多数公司最终都采用了多种技术组合，例如用于客户/交易信息的 MySQL、用于快速提取设备数据的 NoSQL 以及用于分析设备数据的 Hadoop。我们的技术通过快速数据扩展您的 MySQL 基础架构，使您能够消除 NoSQL 和 Hadoop 部分并专门使用 MySQL 来最大限度地减少您使用的专业知识、招聘和不同工具，并显着降低成本。

RUPP：对于那些不需要支持 SQL 的数据库的应用程序，像 hamsterdb 这样的键/值存储的好处将很有吸引力：高性能、低资源要求。对于嵌入式 SQL 数据库，SQLite 是最明显的选择。

当前的嵌入式数据库技术如何促进传感器输入的存储和分析，这些输入可以从数百或数千扩展到可能的数百万？

GRAVES：管理物联网中传感器网络产生的海量数据集有很多维度。如果 DBMS 要支持应用程序的不同数据访问模式，则必须支持多个数据库索引。至少它应该提供：

哈希索引，用于通过键（简单或复合）快速查找特定对象

用于模式匹配、范围检索和排序结果的B-tree 索引（B-tree 可以针对内存数据存储进行优化）

地理空间数据的 R 树索引

PATRICIA Trie用于网络通信/电信系统的 IP 地址和电话号码索引

“模糊搜索”用例的Trigram 索引

可能导致它们在大数据规模上陷入困境的 DBMS 的一个特征是索引树的深度。这可以通过使用哈希索引来缓解。在 eXtremeDB 中，我们还修改了 B 树算法，以使树比传统的 B 树更浅。

一些嵌入式数据库系统（如 SQLite）是单任务的，因此无法利用多核，这在嵌入式系统中变得越来越普遍。理想情况下，DBMS 将是具有乐观并发模型的多任务处理，允许嵌入式系统开发人员充分利用目标系统的资源。

在某些情况下，从事传感器数据融合的嵌入式系统必须优先处理指示某些数据到达的中断。在 DBMS 中，在运行时确定事务优先级的能力可以满足这一要求。缺少这样的功能可能意味着丢失数据，例如当一个传感器数据单元在另一个传感器数据到达之前没有被抓取时。

RUPP：可能必须将昂贵的操作（如分析查询）卸载到服务器上。对于收集数据和简单查询，开发人员可以求助于键/值存储，这是一种精简的、类似 NoSQL 的数据库方法。一些键/值存储可作为嵌入式库使用，这避免了客户端/服务器架构的通信开销。这些通常还提供各种配置选项以针对特定用例进行优化。

我通常建议在服务器上执行后处理。后处理通常会根据产品演变或业务需求频繁更改，因此需要定期更新软件。在现场将更新部署到 IoT 设备比部署到由 ISV 直接控制的单个服务器要脆弱得多。如果传感器数据太大而无法传输到服务器，那么设备通常可以在不牺牲数据质量的情况下执行非常简单的合并策略，例如每秒只发送一个值而不是多个值。此外，通常可以有效地压缩数据。

审核编辑：郭婷