现在有一批用户设计的数据, 最后前端会用 json 的数据封装, 之前的设计都是直接把这个寸数据库, 导致现在那张表越来越大, text 类型过多会导致臃肿, 那这些数据是要怎么设计处理比较合理呢? 放 redis? 如果数据量一大好像也吃内存什么吧; 还是转对象单独存一张表, 但问题现在的设计数据有好多种类型, 并不一致;
大家有遇到这种的经验吗? 或者让你设计会怎么设计
1
hyhcoder OP 其实就是数据库大文本, 过多会拖慢数据库, 这样要怎么处理, 放 redis 吗, 还是怎么弄
|
2
cstj0505 2018-02-27 17:23:55 +08:00 1
放数据库的话可以考虑 postgresql,支持 json 类型,json 索引,函数。
不过还是建议你们在设计端考虑考虑吧,用 json 存储对象优点偷懒 |
3
jjianwen68 2018-02-27 17:24:55 +08:00 1
mysql5.7 原生支持 json,是不是底层对这种情况做了优化?
|
4
lizhenda 2018-02-27 17:26:56 +08:00 1
mongodb 冗余大数据你值得拥有
|
5
est 2018-02-27 17:29:58 +08:00 2
能问这种问题的,一般 mongodb 能管饱。
如果 mongodb 不管饱,那么你对你的问题就问得更加有针对性了。 |
6
Immortal 2018-02-27 17:31:28 +08:00 1
mongodb
|
7
solee 2018-02-27 17:56:16 +08:00 1
不是 mongodb 么
|
8
lcj2class 2018-02-27 17:56:55 +08:00 1
「用户设计的数据」不需要查找、过滤嘛?如果不需要,感觉可以纵向拆表,把常用的数据与这些数据分开
|
9
maemual 2018-02-27 17:57:27 +08:00 1
这个 json 需要查询么?怎么听起来这个 json 只是当成 text 使用呢?
|
11
hyhcoder OP @maemual 现在的确就是当成一个 text 来用, 但表空间增长得恐怖, 现在一个表 250G 了, 但这些数据其实不是查询相关, 感觉不应该直接放数据库的样子
|
13
ray1888 2018-02-27 18:04:34 +08:00 1
是经常需要读的数据吗?还是需要修改的数据?
|
14
swulling 2018-02-27 18:07:01 +08:00 via iPad 1
|
16
ray1888 2018-02-27 18:37:18 +08:00 via Android
250g 的话,感觉 mongo 可能会坑,感觉可以试试 tidb(他们好像挺标榜性能的,看他们的宣传)或者 hbase 感觉也可以
|
17
th00000 2018-02-27 19:23:39 +08:00
最近接触了 dynamodb 对 json 的支持比较好 , 不负责任的回答
|
18
wweir 2018-02-27 19:29:45 +08:00 via Android
表过大影响速度了吗?
没影响的话,直接对表分区好了 |
19
CoderGeek 2018-02-27 19:32:46 +08:00 via iPhone
数据量太大了 redis 不太合适 小的直接存 json str 到可以
|
20
CoderGeek 2018-02-27 19:33:10 +08:00 via iPhone
或者 mysql5.7 可以存 json 支持查询
|
21
qiayue 2018-02-27 19:36:54 +08:00
最简单改动最小的就是还用 MySQL,增加一个 json 表(可以单表也可以拆分),这个表存 json 字符串,然后原先的表只存这个表的 ID。用的时候再去 json 表取,再配合一定的缓存( Memcached 或者 Redis ),速度飞快。
|
22
prolic 2018-02-27 19:40:14 +08:00 via Android
看起来像类似用户词典之类的东西,还是存成静态文件,拿 key 取比较合适
|
23
pathbox 2018-02-27 19:41:32 +08:00 via iPhone
pg 欢迎你,MySQL 其实也没问题
|
24
wizardforcel 2018-02-27 20:06:23 +08:00
mongodb
无论是 redis 还是关系型数据库,都需要整个拿出来再解码才能查询里面的一个属性,开销太大,mongo 就不用。 |
25
puritania 2018-02-27 21:42:13 +08:00
将大字段从表中拆出去,单独建库,做好分表策略使得单表数据量足以满足查询速度,可以考虑用 redis 缓存数据,每个 key 设置较短的超时时间,每次 get key 时重置超时时间,让热数据一直在 cache 中,冷数据及时过期。
|
26
xpresslink 2018-02-27 21:42:43 +08:00
建议用 postgres 9.5+版,已对 json 和 jsonb 支持相对比较完善了,至少没有其它数据库比得上。存取速度和 mongodb 不相上下,所以直接用 pg 吧。250G 对于 pg 来说只是毛毛雨。
|
27
beginor 2018-02-27 22:44:05 +08:00 via Android
用 pg 吧,妥妥的
|
28
0915240 2018-02-28 00:05:59 +08:00
是单表 250G ???
|
29
killpanda 2018-02-28 00:16:11 +08:00 via iPhone
感觉这种场景可能是设计问题
|
30
Zzde 2018-02-28 00:18:08 +08:00 via iPhone
前段提交的数据不需要过滤拆分吗?需要时候在重新组合返回不行吗?
|
31
changrui0608 2018-02-28 10:21:32 +08:00
NoSQL 用 MongoDB,RDMS 用 PostgreSQL,这俩对 JSON 的直接支持已经有较久的历史了,速度都很快,最近 MySQL 不太了解
印象里 redis 这种大多是拿来存逻辑上可以非持久化的数据的,比如配置、session、数据库查询结果缓存之类的 |
32
iceiceice 2018-02-28 15:10:02 +08:00
我猜你需要 mongodb 真的适合你
|