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

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

感觉至少是不方便用 ORM 来做了,不知道还有什么其他的优缺点,读写性能和存储上的考虑之类。
或者有没有可能的替代方案
4656 次点击
所在节点    数据库
31 条回复
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
日志最好存 nosql,因为( 1 )不需要事务,( 2 )不怕丢失
liprais
2018-09-18 22:35:08 +08:00
pgsql 搞定
luozic
2018-09-18 23:41:24 +08:00
你这明显是时序数据,又没有多少需要关联的,直接走时序数据库不就搞定了,不过为了后面扩展可以搞 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 对象属性过多问题。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/490383

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX