这是一个创建于 2785 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在有一批用户设计的数据, 最后前端会用 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 PRO 最简单改动最小的就是还用 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