七座城堡④ 时序（下）

收获不止数据库

已于 2025-05-02 17:55:03 修改

阅读量602

点赞数 22

分类专栏：七座城堡的故事文章标签：时序数据库数据库大数据超融合数据库数据分析童话数据库开发

于 2025-04-08 11:20:04 首次发布

本文链接：https://blog.youkuaiyun.com/weixin_39534833/article/details/147056816

版权

七座城堡的故事专栏收录该内容

21 篇文章

订阅专栏

梁敬彬梁敬弘兄弟出品

往期回顾
七座城堡⓵ OLTP（上）
七座城堡⓵ OLTP（下）
七座城堡② OLAP（上）
七座城堡② OLAP（下）
七座城堡③ HTAP（上）
七座城堡③ HTAP（下）
七座城堡④ 时序（上）

16. 时序场景需要强大的扩展能力

老王：老柯，要应对如此大规模数据，你建时序城堡时有什么特别的应对策略吗？

老柯：为应对当下这种量级的数据，并⽀撑未来可预期的增⻓，数据库架构需要⾮常好的线性扩展能⼒和弹性能⼒，也就是不但能⽀持线性扩展，⽽且扩容速度需要做到⾮常快。所以我的初步想法是，建一个基于NoSQL架构的KV数据库，来应对我们的时序场景。

老王（有点懵）：啥，NoSQL，KV？

老柯：NoSQL是指非关系型数据库的简称。它是一种与传统的关系型数据库不同的数据库管理系统类型。其设计目标是为了应对大规模数据存储和处理的需求，并提供更高的可扩展性、性能和灵活性，NoSQL数据库通常使用分布式存储架构，将数据分散存储在多个节点上，以实现横向扩展和高可用性。接下来开始回答您第二个问题了，什么是KV ？NoSQL数据库有多种类型，其中KV数据库（Key-Value Store）就是NoSQL数据库的一种，用键值对来组织和存储数据，每个键关联一个唯一的值，可以说是一种非常简单的数据模型。

对比KV如此简单的数据模型，关系型数据库的数据模型可就复杂的多。是采用表格的结构来组织和存储数据，使用基于关系的模型，其中数据以行和列的形式存储。

由于KV库没有固定的表结构和关联，也不需要考虑关系模型的复杂性，可以通过直接查找键来快速检索数据，所以通常情况下其读写速度比关系型数据库更优。
在这里插入图片描述

老王（有些顿悟）：哦，我想明白了，这种结构特别简单，简化了数据库很多内部的机制，所以读写性能要更优。而且我体会到这个妙处了，这种键值恰好满足时序的场景，每个设备在某个时刻的每个指标就是一个K，其对应的值就是一个V。然后各个指标和设备之间似乎也没有什么必然需要关联之处，感觉你说的这个KV库完美的迎合了时序的场景啊。

17. 时序城堡的诞生

老柯：说的非常好！就照您所说的，类似：涂装设备1+温度+时间戳1=51度，涂装设备1+温度+时间戳2=52度…最关键的就是如您所说的，这种键值形式恰好满足了时序的场景。比如之前说的关系型数据库的ACID，这个KV数据库肯定就无法支持了。另外这种简单也带来了灵活性。反之如果是关系型数据库，建表时需根据指标数来考虑列的设计，在指标不固定时有些麻烦。

读写更快、设计灵活固然重要，其实最关键的还是NoSQL数据库的分布式能力，在允许淡化ACID的情况下，分布式架构的设计变得容易了很多，而关系型数据库受限于严格的数据模型结构，难以解决分布式事务等难题，在分布式架构上实现的难度较大，性能也难以突破。KV数据库是NoSQL的一种，能通过地址、端口、路由及分布式协议，将数据以哈希等分片模式将数据分布到多个节点上，每个节点负责管理一部分数据，并处理相关的读写请求。为了提高数据的可靠性和容错能力，KV数据库通常会在不同的节点上创建数据的副本。这样，即使某个节点发生故障，数据仍然可用。

老王：明白了，基于这种KV数据库设计，如果时序数据量大幅增加，KV数据库就有通过增加节点来完成扩容，如果数据可以转走或者清理，就可以通过减少节点来完成缩容，就能应对时序数据库的可怕的数据规模。对了，你不是在在进行另外三个城堡的扩建工作吗，能用到这个技术吗？

老柯：目前我们正在研究，基于关系型的分布式数据库实现的难度比NoSQL数据库的难度高出许多，所以您还得再给我们一点时间去完善。不过我们已经取得了重大的突破，相信很快也能实现灵活高效的分布式架构。”

老王：对了，你接下来想基于KV数据库来建设时序数据库城堡，对此我还有一个疑惑，KV数据库是靠牺牲了很多特性换取了可扩展性、灵活性和高性能等。但是在分析起问题来，我担心会不会有一些麻烦。我想到一件事，不同的设备有关联关系，而这些关联关系要展示出来，我们能实现吗？

老柯：刚想和您探讨这个问题，您就先提出来了。这个KV的模式其实是非常灵活的，简单的Key和Value还是有玄机的，这个Value除了存储具体的值，比如刚才那个温度值，还能存放存放设备之间的关联关系，类似维护一个字典。”

老王：原来如此！还有一个问题，这个Key一次存一个指标还是多个指标？

老柯：通常是一次性写入多个指标，对应的Vaulue也是多个值，这样不仅效率高，还可以保证数据的完整性。

老王：明白了，又学到好多东西。老柯啊，就照着你的思路去打造时序数据库城堡吧，此外不要忘记了咱们另外三个城堡的扩容技术，希望能克服难关，将NoSQL分布式能力结合进咱们的关系型数据库中去。

老柯：您放心！关系型数据库的分布式能力是一定能突破的。此外这个时序城堡建成之际可能也只能满足当下的时序场景。随着时序场景的不断丰富，我担心KV数据库的查询分析能力不足、缺乏事务等一系列问题会成为瓶颈。包括之前我提到的异频上传和乱序上传等处理代价也很大。所以我们后续可能要适应未来变化随时调整，做好随时回归关系型数据库模式的准备。

在这里插入图片描述