嵌入式数据库为什么不使用关系数据模型

以传统方式处理数据管理并不总是能很好地应用于嵌入式系统。关系数据库模型的流行是无可争辩的，但这并不意味着它是处理宝贵的 CPU、内存和存储资源时的正确选择。关系模型的一种替代方法可以帮助降低硬件要求并为复杂的数据关系建模，从而允许供应商为手头的应用程序释放资源。

在竞争日益激烈的市场中，嵌入式应用程序供应商不断寻找新方法来降低应用程序成本和上市时间，并增加应用程序功能以最终获得市场份额并促进产品销售。虽然收入利润率受到挤压，但消费者期望新产品发布具有更高的质量和功能。供应商越来越愿意将第三方组件添加到新产品和现有产品中，以实现这些目标。

任何嵌入式应用程序中的一个重要组成部分是高效的数据管理。商业嵌入式数据管理引擎正在获得认可，并且在许多情况下成为应用程序的硬性要求。在过去的 25 年中，随着数百万美元的投入用于研发，关系模型已成为数据管理的首选方法。

建立关系

关系数据模型的首要好处不是模型本身，而是它与 SQL 语言的密切关系。SQL 有两个主要好处：

即席查询：使用预定义的关系数据模型，任何有效的 SQL 都将保证结果而不保证其性能。在数据挖掘应用程序中，这是一个非常强大的功能，但在大多数嵌入式应用程序中，用例和查询在设计时是已知的。想想 MP3 播放器：所有用例，例如音乐文件同步和用户导航，都是预定义的，在设备或固件的下一个版本发布之前不会改变。这不像经理会来要求开发人员根据现有数据模型创建新报告。

供应商独立性： SQL 是许多嵌入式数据库供应商支持的通用语言。据推测，用另一个替换一个应该像打开电灯开关一样容易。尽管它并不那么简单，但进行这种转换绝对比从一个专有 API 迁移到另一个更容易。

关系模型通过值匹配以及在大多数情况下通过键来建立记录之间的关系。这些键称为主键/外键关系。图 1 说明了 MP3 播放器中艺术家和专辑的关系模型，它将作为本文进一步讨论的基础。

图1

仔细观察，关系是通过将 fname 的值复制到专辑表中并在两者之间添加索引结构来实现的。复制 fname 字段本身会增加数据库映像的开销。图 1 中的另一个含义与外键有关。如果没有添加外键数据结构，开发人员每次处理关系时都必须访问专辑表中的每一行。原因是表格数据没有任何顺序，因此无法判断匹配值是在表格的开头、中间和/或结尾。添加外键索引解决了这个表扫描问题。图 2 分解了外键索引和专辑表来说明索引开销。

图 2

有了 B 树，开发人员可以进行二分搜索来建立关系，从表扫描到索引扫描。这将线性搜索转换为二分搜索，通过指数差异提高了运行关系的成本。

表扫描的成本为 O（n），其中 n 表示表中的记录数，而索引扫描的成本为 O（log n）。在计算复杂性理论中，大 O 符号经常用于描述输入数据的大小如何影响算法——计算资源的使用。其他明显的影响包括表示索引所需的空间以及在数据更改时维护此结构所需的命中率。由于从时间、CPU 和功耗方面来看，I/O 是最昂贵的操作，因此开发人员应该努力减少它。对于闪存等存储设备，写入也应受到限制，以防止对该技术施加的最大写入擦除周期和空间回收周期产生负面影响。

那么问题就变成了：开发人员如何以低于 O（log n） 的成本维护这种关系信息？

重新引入网络数据模型

图 3 显示了通过网络数据模型调整的相同数据表示。

图 3

网络数据模型早于关系模型，可以看作是它的超集。这意味着在关系模型中表达的任何东西都可以在网络模型中表达，甚至 SQL 支持。主要优点是可以对关系进行建模的方式。在图 3 中，以前显示为外键索引的关系现在被分解为多个指针列表，称为集合。指针可以被视为 C 应用程序中的 void 指针，可以直接查找堆，但堆现在是持久存储。消除外键数据结构和fname重复不仅减少了需要存储的数据量，而且还减少了不必要的数据结构维护。

图中简化了一个所有者有两个指针，第一个和最后一个成员记录，而成员有三个，所有者加上前一个和下一个成员。根据指针的本质，它不与任何特定的数据类型绑定，因此关系可以对任意数量的记录类型之间的复杂关系进行建模，而不仅仅是关系模型强加的两个之间的关系。本文不会讨论复杂的建模功能，但它说明了网络模型的灵活性。

图 4

成本影响

从一个记录到一组记录转换为恒定成本。只要数据尚未驻留在数据库 RAM 缓存中，最多只需要一个 I/O 周期。使用外键实现，在定位实际记录之前，将首先遍历 B 树，成本为 O（log n）。很明显，遍历 B 树有 CPU 和 I/O 开销，但也有内存开销。任何数据库缓存都会存储最近访问过的数据，甚至是 B-tree 数据。由于 B-tree 扫描最终在缓存中，因此缓存必须很大，否则需要额外的 I/O 来刷新其数据。

写操作也需要恒定的成本。开发人员将新记录添加到专辑表并将新记录加入现有艺术家专辑集需要采取以下步骤来完成操作：

添加新专辑记录。

将新记录设置为当前艺术家的所有者指针。

设置新记录，即指向当前艺术家的前一个指针，即最后一个记录。

将新记录的 next 指针设置为 0。

将当前艺术家的最后一条记录设置为指向新记录的下一个指针。

将所有者的最后一个指针设置为新记录。

在这一系列操作期间不进行扫描，导致成本不变。使用 B-tree 实现，开发人员将：

1.添加新专辑记录。

2. 扫描 B-tree 找到新记录的索引位置。

3.如果B-tree中没有空间，则拆分并重组树。

4. 在 B 树中写入对新记录的引用。

在此序列中，开发人员在步骤 2 中遇到 O（log n） 成本。更重要的是，步骤 3 可能会通过要求重新组织部分或整个树而产生巨大的成本。重组是不可预测的，因为它取决于树的完整性以及必须在树中的哪个位置进行更改。包含数据的节点越多，重组的机会就越大。在大多数情况下，B-tree 更改是在本地完成的，只影响少数几个节点，但有时会触及许多节点，给应用程序增加了不确定性。因此，如果开发人员发现自己需要可预测的性能，他们应该检查他们的数据是如何表示的。

MP3 播放器基准测试

那么开发者使用网络模型可以节省多少硬件资源呢？在一个示例中，Birdstep Technology 实施了艺术家-》专辑-》歌曲的三向关系，允许商业 MP3 播放器制造商获得一些关于资源节约的确凿事实。开发人员仔细比较了 Birdstep Technology 的 RDM Embedded 数据库引擎，它是一种网络模型，以及使用台式计算机和消费电子硬件的公共领域关系数据库引擎。如表 1 所示，硬件资源受限越多，节省的差异就越大。

在这两种硬件解决方案上，网络模型用于存储相同数量的记录和关系的磁盘空间减少了 27%。所有的存储节省都可以归功于用指针替换了艺术家-》专辑和专辑-》歌曲的外键索引。删除这些数据结构对存储需求产生了巨大影响。B 树索引通常需要 1.3 倍于它的索引空间。

应用程序驱动数据库决策

在寻求在应用程序中添加或替换现有数据管理组件时，开发人员应仔细考虑选择。应用程序应该推动决策，而不是行业。有几种不同的解决方案可用，从简单的库到完整的客户端服务器解决方案，增加了本文所述的功能。选择正确的技术并对数据进行正确建模可以对应用程序的成本产生巨大影响，从而带来更高的利润率、更高质量的产品和更好的最终用户体验。

审核编辑：郭婷