超过 100 列的表，这样的设计存在什么优缺点？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2264 天前的主题，其中的信息可能已经有所发展或是发生改变。

业务背景：
需要和硬件每分钟通信，写一次记录。
读取可能是挑其中部分列，列一般不会变，列名会存在另一个表里。
除了 100 个数据列还有识别的字段和时间戳。

感觉至少是不方便用 ORM 来做了，不知道还有什么其他的优缺点，读写性能和存储上的考虑之类。
或者有没有可能的替代方案

优缺点

字段

列名

orm

31 条回复 • 2018-09-19 17:40:31 +08:00

sampeng

2018-09-18 11:55:13 +08:00

你这个需要 nosql。。100 列。。。mysql 之类不是不可以。。就是存储各方面都会变得大。哪怕你留空

kelthuzadzbt

2018-09-18 11:55:23 +08:00

可以存 json 字符串吗，日志表存{pid:v} pid 对应列名在另一个表里的主键 id，100 多列的话；
ps：菜鸟轻喷

betulachen

2018-09-18 12:17:09 +08:00

换数据库,rrd

nullcoder

2018-09-18 12:20:11 +08:00 via Android

@kelthuzadzbt 关系型数据库一般不用这种设计

nullcoder

2018-09-18 12:21:06 +08:00 via Android

@betulachen rrd 全称是什么？

hjc4869

2018-09-18 12:30:27 +08:00

数据冗余，浪费空间。
有些情况下性能可能好一些，因为不需要多表查询。不过一般写业务还是尽可能 3NF

hcymk2

2018-09-18 12:51:53 +08:00

可以尝试下时序数据库。

littlewing

2018-09-18 13:04:27 +08:00

nosql 或时序数据库

nullcoder

2018-09-18 13:05:16 +08:00 via Android

@hjc4869 数据冗余在哪里？
100 列一个时间戳和一个识别字段还好吧

betulachen

2018-09-18 13:27:40 +08:00 via iPhone

百度 rrd 数据库第一条就是

wingyiu

2018-09-18 13:39:46 +08:00

hbase

reus

2018-09-18 13:53:29 +08:00

postgresql + json 列
关系数据库当然可以这样设计，还能用列内的值创建索引

yejinmo

2018-09-18 13:57:19 +08:00

实时数据库了解下？

ebingtel

2018-09-18 14:05:19 +08:00

我宁愿用 E-A-V 的方式存储，<id、列名、值>

wccc

2018-09-18 14:10:53 +08:00

时序数据库 influxdb 前东家做法

loveCoding

2018-09-18 14:11:40 +08:00

http://liubin.org/blog/2016/02/25/tsdb-list-part-1/

hjc4869

2018-09-18 14:25:21 +08:00

@nullcoder 理解错了, Sorry.

LadyChunsKite

2018-09-18 14:33:53 +08:00

@reus 为什么不用 hstore ？

reus

2018-09-18 16:12:58 +08:00

@LadyChunsKite jsonb 可以完全替代 hstore

nullcoder

2018-09-18 16:47:40 +08:00

@ebingtel 这样缺了时间戳，如果加上冗余量就大了

viver

2018-09-18 17:03:13 +08:00

postgresql 支持 json，可以考虑下

nullcoder

2018-09-18 17:15:31 +08:00

@reus @viver 看了一下，这种方案还是很方便的。
这种设计有没有什么可能的缺点呢？

opengps

2018-09-18 17:20:23 +08:00

看具体业务规则，以我做过的 gps 监控为例子，曾经用过关系型数据库：时间列聚集索引达到类似于“时序数据库”的效果。这张表也用途也设计的超级简单（花了很大精力实现“简单”），单行密集写入，按时间区间批量读取。

gfreezy

2018-09-18 18:18:05 +08:00

只取少量字段的时候稍微慢一点吧。MySQL 行存储需要遍历更多的数据。

absente

2018-09-18 18:47:11 +08:00

列的多少一般不是问题（当然是有上限的）。一个 erlang 程序随随便便几百上千的微线程，一样跑的好好的。不同之处在于，行式关系型数据库，是一个 x 乘以 y 的关系（如果数据充足）。列式数据库就没这个问题，当然，这已经算 nosql 了

wizardforcel

2018-09-18 22:03:11 +08:00 via Android

日志最好存 nosql，因为（ 1 ）不需要事务，（ 2 ）不怕丢失

liprais

2018-09-18 22:35:08 +08:00

pgsql 搞定

luozic

2018-09-18 23:41:24 +08:00 via iPhone

你这明显是时序数据，又没有多少需要关联的，直接走时序数据库不就搞定了，不过为了后面扩展可以搞 pgsql+json

nullcoder

2018-09-19 09:05:37 +08:00

@wizardforcel 不是日志，是数据记录，后面会用来做分析。

viver

2018-09-19 14:03:57 +08:00

@nullcoder pgsql 在数据量比较大的时候(包含 json，并且对 json 进行操作)，应该只适合数据的写入和读取，如果对单个 json 的 key 值进行操作，效率都会比较低，决解这个问题可以维护基于 json 串的 GIN 索引。数据量小的话，读写性能和普通的字段应该差距不大,建议是 pgsql 只用来数据的存储，对数据的操作尽量在代码层面上搞定。

nullcoder

2018-09-19 17:40:31 +08:00

@viver 现在看因为原始数据一般是类似与 int 数组，所以可能不考虑 json 这种方案了。
目前主要业务在关系型数据库里，配置时序数据库需要多数据源的配置处理，还在了解这块。
现在先简单考虑用反射机制解决 ORM 对象属性过多问题。