Django结合Postgres存储大型JSON对象的性能优化方案咨询

• 替换字段类型 + 应用层压缩：
  由于你无需在服务端解析该JSON内容，完全可以放弃JSONField，改用BinaryField存储压缩后的二进制数据，省掉数据库对JSON的格式校验、序列化开销。压缩算法优先选zstd（压缩率高、编解码速度极快），兼容要求高的场景可选gzip。
  更极致的优化：如果前端支持对应压缩格式的响应解码，你可以直接将存储的压缩二进制数据作为响应返回，设置好Content-Encoding响应头即可，连应用层的解压步骤都可以省略，同时大幅降低传输带宽占用。
• 查询逻辑优化：
  所有不需要获取JSON字段的查询，统一使用defer('json')（未分表场景）或者only('需要的字段名')过滤字段，避免每次查询都拉取10MB级的冗余数据到内存，既降低内存占用也减少IO耗时。

强烈建议将大JSON字段拆分到独立的一对一关联表，优势如下：

• 原Test表仅保留小字段，单行行长大幅缩小，InnoDB单数据页可存储的行数翻倍提升，所有针对Test表的查询、更新操作的IO开销都会大幅降低，MVCC、行锁带来的额外开销也会更小
• 避免更新Test表其他字段时，和大JSON字段的读写操作产生IO资源竞争，也不会因为大字段的存在拖慢整表的操作性能

分表后的模型示例：

class Test(models.Model):
    title = models.CharField(max_length=32, verbose_name='title', default='')
    # 其他原有小字段，移除json字段
    ...

class TestJsonContent(models.Model):
    test = models.OneToOneField(Test, on_delete=models.CASCADE, related_name='json_content')
    compressed_json = models.BinaryField(verbose_name='压缩后的JSON数据')

如果暂时不做分表，更新Test表其他字段时必须直接调用Test.objects.filter(筛选条件).update(字段=值)，绝对不能先把Test实例查出来再调用save()，否则查询实例时如果没有主动defer('json')，会直接把10MB的JSON字段拉取到应用内存，产生完全不必要的开销。

内容的提问来源于stack exchange，提问作者Kabiljan Tanaguzov