为什么说关系型数据库，纵向设计总是优于横向设计？
black11black · 2020-12-24 12:01:03 +08:00 via Android · 1646 次点击这是一个创建于 1448 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，现假设需求如下:
我有一中央管理系统，下有智能汽车一万台，每台汽车上有若干传感器，以微秒为级别记录数据，假定每天每车平均产生一万条数据。
以前看到过一个说法是，关系型数据库尽量不要采用横向设计。按这个理论的话，数据库应设计为只包含一张大表，表内有主键、汽车编号、传感器编号、时间、数值这五列。
假定缓存一年数据，那可粗略估算数据量为 365 亿行，以某种方式分区。
而按照我个人感觉，则应设计为每车数据储存一张表，共一万张表，每张表不分区。我觉得这样有一个好处是，比如如果全部储存在一张大表中，大表按照时间分区，比如每天一区。那么面对比如调出某车过去一年全部数据这种需求时，效率应不如另一种方案高。
因为是基于数据行数非常大的情况下的假设，真做实验对比的话比较费时间，想先来论坛里问问各位的看法，有没有大佬解惑一下哪种模式好
我有一中央管理系统，下有智能汽车一万台，每台汽车上有若干传感器，以微秒为级别记录数据，假定每天每车平均产生一万条数据。
以前看到过一个说法是，关系型数据库尽量不要采用横向设计。按这个理论的话，数据库应设计为只包含一张大表，表内有主键、汽车编号、传感器编号、时间、数值这五列。
假定缓存一年数据，那可粗略估算数据量为 365 亿行，以某种方式分区。
而按照我个人感觉，则应设计为每车数据储存一张表，共一万张表，每张表不分区。我觉得这样有一个好处是，比如如果全部储存在一张大表中，大表按照时间分区，比如每天一区。那么面对比如调出某车过去一年全部数据这种需求时，效率应不如另一种方案高。
因为是基于数据行数非常大的情况下的假设，真做实验对比的话比较费时间，想先来论坛里问问各位的看法，有没有大佬解惑一下哪种模式好
 |
1
oneisall8955 2020-12-24 12:49:10 +08:00 via Android
mark，菜鸡一名，觉得按汽车 ID hash 后两位分库分表，没必要 1W 张表吧？大佬怎么看(=_=)
|
 |
2
qiayue 2020-12-24 12:55:33 +08:00
这个时候，需要用到时序数据库
|
 |
3
lpts007 2020-12-24 12:57:06 +08:00 via Android
这个场景关系型数据库就算了吧，kv 列存储的数据库选一个
|
 |
4
f6x 2020-12-24 13:15:58 +08:00
你考虑下扩展性.
增加传感器怎么办, 数据量太大了分表怎么分,分库怎么分,怎么备份,插入慢怎么优化,查询慢怎么优化.........sql 怎么维护 |
 |
5
passerbytiny 2020-12-24 13:16:04 +08:00 via Android
谁告诉你看基础设施考虑谁优先，去怼死他。
此外，你的两种设计，第一种是横向而非纵向，第二种是物理模型设计，而横向纵向是逻辑。模型设计。 |
 |
6
monsterxx03 2020-12-24 13:22:10 +08:00
传感器数据, 现在做技术选型可能会考虑时序类数据库了.
把问题限定在传统关系型数据库(不考虑 spanner, tidb 等 NewSQL) 要考虑下面问题: - 单节点内表 sharding 还是多节点 sharding? - 你假设的问题里数据是均匀的, 实际业务里不太可能, 所以会有 hash(id)%N 的做法. 每台车一个表实际造作上很可能是行不通的, 问题里每台车几乎是同时在线的, 意味着数据库需要同时维持 1w 张表是 open 状态, mysql 为例, 一张表至少要打开 frm,ibd 两个文件，需要考虑到操作系统 fd 限制, mysql table_open_cache, innodb_open_files 等参数的调优. 要同时开 1w 张表, 这些参数需要调到很高, 还有持续的同时写入, 文件系统可能就先崩了. |
 |
7
imn1 2020-12-24 13:25:55 +08:00
横向纵向你是怎么定义的？我怎么想到横向是时间，不是汽车？
所以，同意#5，横向纵向是逻辑而已 不熟悉数据库，早年的同事是这样考虑的 1.机器处理能力 2.业务逻辑（需求） 现在好像钱多了，第一条逐渐弱化了，变得不重要 |
 |
8
whileFalse 2020-12-24 13:55:04 +08:00
怎么对所有车的某项特性进行统计？查询一万次吗
|
 |
9
opengps 2020-12-24 14:04:44 +08:00
想明白设计目的就知道了。如果数据量有限，那么横向大表当然用起来省事。
但如果增长巨快，你横向设计得哭。纵向设计倒是可以轻松分布式增加节点 |
 |
10
aegon466 2020-12-24 14:11:25 +08:00
一辆车一张表怎么感觉怪怪的 表是关系模型 应该是静态的 稳定的
|
 |
11
FFFire 2020-12-24 15:10:35 +08:00
所以你查的时候一次查一万张表吗
|
 |
12
prodcd 2020-12-24 17:56:56 +08:00
我就是像你这么想的，也是这么干的。
16 年时候入公司搞的新项目，公司也没啥钱招 dba，只有几个新毕业的 PHPer，甚至连个前端都木有。 本以为这项目前期需求都搞明白了，横向有横向的优势，数据采集频率也不高，直接横向 MySQL 表。 半年以后开发的七七八八，以为可以进行下一个项目，结果这项目一个劲的扩，还要兼容其他近似的产品，越来越发现这种方式的弊端。 不同传感器采集频率不同，延迟采集到的数据不容易补回去，现场传感器有变化，就需要程序员跟进，而不是只需要运维人员就能搞定，丢失很多数据细节，阿里云 MySQL RDS 默认存储引擎是 innoDB，最多只能有 1000 多列。 我们用的第三方采集平台是 PostgreSQL，当初好像是 4 核 8G 的阿里云，所有数据集中在一个表里。我们只要过去查点历史记录就很容易卡死，对方被迫把不同项目的点分配到不同数据表，到后来是单个通道一张表，以适应我们读取需求，但还是有些扛不住。后来我们只好改变策略，把查历史的操作限制到一个线程，也给服务器升级到 8 核 16G，轻易不敢找它要历史数据。 你可以看看时序数据库，我也没玩过，但你要明白，做这活的核心就是别给老板省钱，不然省下的钱都要用你的头发还回去。 |
 |
13
black11black OP @whileFalse
@FFFire 合理的质疑，单独提取某个节点的数据，和统一查询都是常见业务范围。只不过想象一下你有一张百亿行级别的大表，感觉做搜索也不会很轻松，而提取单一节点的数据则会显著变慢，比如一分钟才提取出来，感觉并不划算？ |
|
14
whileFalse 2020-12-25 07:55:00 +08:00
@black11black 感觉这个需求全压在 mysql 上就扯淡
|
|
15
black11black OP @whileFalse 本质上就是需要储存+提取，需求层面讲已经很简化，不压在 sql 上还能压在哪呢。
|
 |
16
volvo007 2020-12-25 20:49:20 +08:00
@black11black 压在 Hive 或者 Spark 这种上面怎么样？
最近我也想做类似的事情，也在发愁数据库要怎么选。不过我的量级大约只有你的百分之一，感觉一个 PostgreSQL 应该撑得住 |
Select Language