论坛应用， postgresql 一行的数据大小在什么范围内比较好，超过 1mb 会有什么问题吗？

[annoygaga]

比较典型的互联网论坛服务

目前有一个富文本的需求，不考虑 CDN 的情况下，现在希望把 content 的内容数据都存在一个 row 里，想问问一 row 在各公司一般限制多大呀？我之前有个前辈和我说最好不要太大，影响网络传输，但是是不是不打满网卡的话其实问题不大？

postgresql 一行的数据大小在什么范围内比较好，超过 1mb 会有什么问题吗？

（至于为什么要都塞进一 row 有很多原因，目前限制条件是这样，我也不是很想）

[CEBBCAT]

可以计算和多试试不同尺寸下的性能，结合 Google

[annoygaga]

@CEBBCAT 随机读写么？目前貌似看不太出来区别，可能是测试方法不对，或者测得不够狠

[sagaxu]

pgsql 有 TOAST 存储，超过 TOAST_TUPLE_TARGET(通常 2KB)的字段会尝试压缩，压缩不下去就存储在物理行外。

mysql 用户处理类似需求的时候，喜欢把大字段单独放一个表，在主表行中存储大字段那个表的 id 。

当然，在 pgsql 中你也可以这么做，但是要避免 pgsql 给你的副表再搞一个副副表。

[ShuWei]

你是要存什么？除了文字，难不成还打算存图片之类的？不然要大量超过 1mb ，对 bbs 来说也不容易啊

[kandaakihito]

用 pg 存文本感觉性能上有点麻烦？我们项目一开始就是用 pg 存的文本，当然我们疑似有点极端了吧可能，一段文本就是 200MB 起步，光是测试环节就能一天生成几千条这种数据（

最后还是得迁移，大部分塞 mongo ，冷数据转换成 txt 文件塞 minio

[dode]

通过视图，把数据汇聚到一行呢

[xuld]

不用担心性能。怎么简单怎么来。
如果一个论坛需要你担心性能问题的时候，肯定也有足够的钱来找高手指导

[ny562kPWNJK9g86f]

在 PostgreSQL 中，TEXT 类型可以存储最多 1 GB 的文本数据，所以存储下来不是问题。
问题是要不要采用这种方案，如果你的文本并不需要全文搜索，那可以考虑外部存储的方案。
可以看看 MinIO 、Ceph 、OpenStack Swift 、SeaweedFS 、Zenko 等

[webszy]

@xuld 好思维，确实如此

[bthulu]

换 SQL SERVER, 轻松搞定

[CEBBCAT]

其实俺也觉得自建对象存储比较妥，这样后面再换公有云服务也是比较轻松的，只是被楼主“至于为什么要都塞进一 row 有很多原因”塞住嘴了。

同时，假如未来没有很大很大的前景，我也觉得 xuld 说的先便宜行事的方式比较好，比如，就像我们写博客，挑了半天 WP 、Typecho 、Hugo 、Hexo ，结果一篇博文没写 😁

[encro]

论坛这个我懂，毕竟搞过几个门户，都是几百万几千万级别用户的。。。一个月 uv 也是千万级别吧。

数据库可以直接存 id ，文本另外存一个表即可，这样做主要是方便写 select * from post 。

至于性能，那是搜索引擎（我们那时候是 sphinxsearch 和 elasticsearch)和缓存（数据缓存，页面缓存，客户端缓存）的事情，数据库负责写，负载大部分应该在缓存和搜索引擎。

[cslive]

TEXT 随便存，你也塞不爆这个类型上限

[annoygaga]

@sagaxu 并发可能比较高的话呢？且无缓存的情况

[annoygaga]

@ShuWei 不完全是 bbs ，做法有很多问题，但目前必须这么搞，并发也特别高，所以怕网络成为问题

[annoygaga]

@xuld 并发非常高，不是一个 bbs 服务，只是长得很像，这种情况下会不会有问题呢

[annoygaga]

@encro 其实不完全是 bbs ，并发非常高，有很多因素导致了这个解决方案，现在就是担心网络会不会成为问题

[sagaxu]

@annoygaga 并发高(每秒读 1000 次以上)，性能肯定有影响，按 1M 一条算，假设你写 select *读 1 条，每秒就是 1K * 1M=1G 的数据，数据不压缩则打满 10G 网卡，数据压缩则打满 CPU ，都会导致服务不可用。

即使你不搞缓存，DB 层面有缓存，文件系统层面也有缓存(direct io 例外)，SSD 磁盘自己还有一层缓存，但这些缓存解决不了上面说的打满带宽打满 CPU 的问题。

在不狠狠砸钱搞硬件的前提下，必须要优化掉 select *，不能每次都读取完整的 content ，即降低读取和返回的数据规模，如果 content 能做摘要，入库时存个摘要，非必要只读摘要不读完整原文。

如果是并发超高(QPS>=3 万)，那自己必须再做一层缓存了，redis 集群或文件系统级缓存等等。

[catamaran]

感觉挺累的，一直强调不完全是 bbs ，有很多因素，反正不能细说呗

[annoygaga]

@catamaran 准确说是，很多设计很别扭，细说就很长了，有很多历史原因，倒不是不能说，不过问题倒是很简单，就是 row 数据可能超过 1MB ，并发比较高