这是一个创建于 1489 天前的主题，其中的信息可能已经有所发展或是发生改变。
一个表是 table1,另一个表是 table2， table1:
id:int
name: varchar
table2
id:int
table1_id:int
content: varchar
如有一条 table1 记录，可能下面有几千条 table2 记录，当 table1 表不停增加，我发现 table2 表数据最后能达到几亿条，然后如果把 table1 改成
talbe1: id: int name: varchar items: jsonb
比如这样保存, table1 中把关联保存成这样
items: [{content: "content1"}, {content: 'content2'}.....]
这样，如果 table1 有 100 万条，不用生成 table2 的 100 万*几千条，不知道这样行不行？这样 table2 不会出现几亿甚至几十亿条数据，主要我是担心这个上几亿速度会变很慢。
第 1 条附言 · 2020-12-03 14:56:18 +08:00
这两天测试了下，table1 加到 10 万条，然后 items 列保存成 jsonb，items 各 2000 项，然后，查询时慢的不行，顺便试了下 mongodb 的 Embedded Document，没这方面问题，
 |
1
echowuhao 2020-12-01 11:47:30 +08:00
不可取。1. 肯定会更慢，取决于你查询的内容。
2. 仅 content 一个词，一亿条记录就增加了快 650M 的空间占用。 你可以弄个几万条记录测试一下，我只是猜想。 |
|
2
echowuhao 2020-12-01 11:50:25 +08:00
|
 |
3
FightPig OP @echowuhao 谢谢，上面说的有点错，现在 table1 这个表不停增长，大约后期有 100w 条多，一个 table1 最多关联 2000 多条 table2 数据吧，这样一算，table2 这数据量有点太大，如果保存成 jsonb，那这样也就只有 100w 多条 table1，感觉查询应该比查询 100w*2000 这样的数量好查询，主要是 table2 这个表不断膨胀，如果保存成 jsonb 形式的，没有 1 亿条了，只有 table1 的条数 100w 多吧。
|
|
4
echowuhao 2020-12-01 12:06:15 +08:00
你实际测一下。表虽然 row size 多了一点，但是 postgres 可以有更多信息优化，你堆到 jsonb 里面，postgres 能知道的信息更少，查询的时候就要麻烦了。
我个人没有做过那么大的表，所以只能理论说一下。 |
|
5
echowuhao 2020-12-01 12:08:54 +08:00
@FightPig 没有一亿条了，但是 content 字符出现的次数不是 table1 row size 而是 table 2 的。你之前只寸这个字符一次，就是列名，但是你存到 jsonb 里面不是一百万次，而是一亿次。只一亿次是凭空多出来的存储空间。
|
 |
6
2kCS5c0b0ITXE5k2 2020-12-01 12:09:54 +08:00
先确定 table2 需不需要单独查询 如果不需要可以用 jsonb
json 存储起来占用的空间会比较大 |
 |
7
sjzzz 2020-12-01 13:08:04 +08:00
这种最终还是要看 后续的业务逻辑 光分析表结构意义不大。
|
|
8
FightPig OP |
 |
9
liprais 2020-12-01 13:11:38 +08:00
肯定分开啊，不然你 update 别的字段的时候 jsonb 也被读了一遍
|
Select Language