这是一个创建于 2460 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在有一批用户设计的数据, 最后前端会用 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 真的适合你
|
Select Language