docs: 可扩展性设计与路线图 (scalability roadmap) #26

2026-06-24T13:29:52+08:00

lixu commented

2026-06-24 13:29:52 +08:00

Summary

回答一个长期架构问题:商品量大、品类多(食品/3C/药品/…)时,检索与新增会不会压垮数据库?要不要按品类「分表」?

结论:现在不要按品类手动分表。现有「单表 product + attributes JSONB + archive_kind 框架(kind_field 模板)+ 针对性索引(trgm/tsvector/JSONB GIN)」方向是对的;扩展应靠 分区(非分表) + 读副本 + 缓存 + 专用搜索引擎,按数据量分阶段推进。

关键论点:

核心场景是全局检索,按品类拆表会逼出 UNION ALL 多表 → 更慢更复杂;单表配好索引可承载千万级。
区分分表(sharding) 与 Postgres 原生分区(对上层透明的一张逻辑表)——后者仅超大规模才用。
路线图按里程碑触发:阶段0(keyset 分页 / 部分索引 / Redis 缓存)→ 阶段1(只读副本 + 可选 LIST 分区)→ 阶段2(OpenSearch/Meilisearch/ParadeDB 等专用搜索引擎,Postgres 仍为事实唯一来源)。
写入只有 ingestion 批量 ETL,非高并发,插入不是瓶颈。
回扣最初问题:加「药品」属于阶段0常规扩展,只加 kind_field + 品类子树,不触动架构。

纯文档变更,仅新增 docs/scalability.md,不动任何代码或 schema。

## Summary 回答一个长期架构问题:商品量大、品类多(食品/3C/药品/…)时,检索与新增会不会压垮数据库?要不要按品类「分表」? 结论:**现在不要按品类手动分表**。现有「单表 product + attributes JSONB + archive_kind 框架(kind_field 模板)+ 针对性索引(trgm/tsvector/JSONB GIN)」方向是对的;扩展应靠 **分区(非分表) + 读副本 + 缓存 + 专用搜索引擎**,按数据量分阶段推进。关键论点: - 核心场景是全局检索,按品类拆表会逼出 UNION ALL 多表 → 更慢更复杂;单表配好索引可承载千万级。 - 区分分表(sharding) 与 Postgres 原生分区(对上层透明的一张逻辑表)——后者仅超大规模才用。 - 路线图按里程碑触发:阶段0(keyset 分页 / 部分索引 / Redis 缓存)→ 阶段1(只读副本 + 可选 LIST 分区)→ 阶段2(OpenSearch/Meilisearch/ParadeDB 等专用搜索引擎,Postgres 仍为事实唯一来源)。 - 写入只有 ingestion 批量 ETL,非高并发,插入不是瓶颈。 - 回扣最初问题:加「药品」属于阶段0常规扩展,只加 kind_field + 品类子树,不触动架构。纯文档变更,仅新增 docs/scalability.md,不动任何代码或 schema。

lixu added 1 commit 2026-06-24 13:29:52 +08:00

docs: 新增可扩展性设计与路线图 (scalability roadmap)

CI / Go (api) (pull_request) Successful in 59s

Details

CI / Python (ingestion) (pull_request) Failing after 20s

Details

CI / Migrations (postgres) (pull_request) Successful in 34s

Details

3b62f61288

Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

lixu merged commit 649fcc711c into main

2026-06-24 13:31:21 +08:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lixu/goods#26