Couchbase文档大小超20MB（含千条产品数据）的处理方法咨询

当用户关联的产品数据达1000条导致Couchbase文档超出20MB限制时，可通过以下几种实用方案处理：

1. 拆分大文档为多文档（核心方案） #

将原有的用户+产品合并文档拆分为用户主文档和产品子文档：

• 用户主文档仅存储用户核心信息（如ID、姓名、基础设置等），键名示例：user::123
• 产品数据拆分为独立文档，可按批次或单条存储：
  • 按批次：每200条产品数据存一个文档，键名示例：user::123::products::batch1、user::123::products::batch2
  • 按单条：每条产品数据存一个文档，键名示例：user::123::product::456（456为产品ID）
• 查询时，通过N1QL语句批量获取关联的产品文档，示例：

  SELECT u.*, p.* 
  FROM bucket u
  JOIN bucket p ON META(p).id LIKE CONCAT('user::', u.id, '::products%')
  WHERE u.id = '123'
  

这种方式符合Couchbase的文档设计原则，单文档专注单一实体或小集合，从根源上避免超大小限制。

2. 精简产品数据字段 #

检查产品数据中的冗余信息，只保留用户关联场景下必需的字段：

• 若已有独立的产品主文档库，用户关联文档中仅存储产品ID、名称、缩略图URL等轻量信息，无需重复存储产品详情、规格等大字段
• 如需获取产品完整信息，再通过产品ID关联查询产品主文档
  这种方式能大幅压缩单文档体积，比如原每条产品数据占10KB，精简后仅占1KB，1000条总大小仅1MB，远低于20MB限制。

3. 利用子文档API做增量操作 #

如果暂时不想拆分文档，可通过Couchbase的子文档API（LookupIn、MutateIn）操作产品数组的局部元素：

• 新增产品时，仅向数组末尾追加单条数据，无需全量更新整个大文档
• 修改或删除产品时，直接定位数组中的指定元素进行操作
  但这种方式仅适合增量维护，无法解决已超20MB的文档问题，若数据持续增长，最终还是要拆分文档。

4. 优化索引提升查询效率 #

文档拆分后，为了保证关联查询的性能，可创建针对性的N1QL索引：

• 示例：为用户ID关联的产品文档建索引

  CREATE INDEX idx_user_products ON bucket(userId) 
  WHERE META().id LIKE 'user::%::products%'
  

这样查询用户所有关联产品时，能快速定位到对应的子文档，避免全表扫描。

5. 用集合（Collection）做逻辑隔离 #

将用户主文档和产品子文档放在同一个Scope下的不同Collection中：

• 比如创建user_data Scope，下分user_profiles（存用户主文档）和user_products（存产品子文档）两个Collection
• 这种方式能让数据逻辑更清晰，管理和维护更方便，同时不影响查询效率

内容的提问来源于stack exchange，提问作者Metin SevTHP