假设项目需要存储审计客户的财务数据（包含结构化报表数据和非结构化审计报告），请设计数据库架构（如关系型+文档型混合），并说明如何通过索引、分区等优化查询性能和扩展性。
德勤中国项目实习生-数据分析与智能产品难度：中等
答案
1) 【一句话结论】采用关系型数据库（RDBMS）存储结构化财务报表数据，文档型数据库（NoSQL）存储非结构化审计报告，通过分库分表、索引优化、跨数据库事务/消息队列保障一致性，实现混合架构下的性能与扩展性。
2) 【原理/概念讲解】老师口吻，解释核心概念：
结构化数据（如报表中的“科目、金额、日期”）类似“有固定格式的表格行”，需要严格规范；非结构化数据（如审计报告的“文本、附件”）类似“自由文档”，格式不固定。
- 关系型数据库（如MySQL）：以“表”形式存储，强一致性（ACID）、事务支持（如两阶段提交），适合结构化数据（比如财务报表的科目、金额需严格规范）。
- 文档型数据库（如MongoDB）：以“文档（BSON）”形式存储，Schema灵活，适合非结构化数据（比如审计报告的全文、附件无需固定字段）。
混合架构优势：利用RDBMS的强一致性处理结构化数据，用NoSQL的灵活Schema处理非结构化数据，避免单一数据库的局限性。
3) 【对比与适用场景】
| 特性/类型 | 关系型数据库（RDBMS，如MySQL） | 文档型数据库（NoSQL，如MongoDB） |
|---|---|---|
| 定义 | 以“表”形式存储，强结构化，固定Schema | 以“文档（BSON）”形式存储，Schema灵活 |
| 特性 | 强一致性（ACID）、事务支持、事务隔离（如MVCC） | 高扩展性、灵活Schema、最终一致性（BASE） |
| 使用场景 | 结构化财务报表数据（科目、金额、日期等字段严格规范） | 非结构化审计报告（文本、附件、格式不固定） |
| 注意点 | 分库分表后跨库查询需优化（如读写分离、缓存）；索引过多影响写入性能 | 避免Schema过于灵活导致数据不一致；非结构化数据量极大时需分片、压缩 |
| 数据一致性保障 | 事务（两阶段提交）或分布式事务（如XA协议） | 消息队列（如Kafka）+重试机制或Saga模式（最终一致性） |
4) 【示例】
- 关系型数据库（MySQL）分库分表策略：按
client_id分库（分10个库，每个库存储特定客户ID范围，如库1存储client_id 1-1000），按report_date分表（如按年分表，2024_01、2024_02）。索引设计：在client_id、report_date、report_type建复合索引（idx_client_date_type）。 - 文档型数据库（MongoDB）分片策略：按
client_id分片（分片因子10，即10个分片，每个分片存储特定客户ID范围的审计报告，如分片0存储client_id 1-1000）。索引设计：在client_id、report_content（全文索引）、generated_at建复合索引（idx_client_content_at）。 - 数据一致性保障：当更新审计报告时，通过两阶段提交（2PC）确保财务报表关联数据同步（如审计报告更新时，触发事务更新财务报表中的关联字段）。
- 跨库查询优化：读写分离（主库写，从库读）；Redis缓存常用查询结果（如客户ID对应的财务报表摘要）；分库分表后的路由机制（如通过Sharding Key路由到对应分片）。
5) 【面试口播版答案】
面试官您好，针对存储结构化财务报表和非结构化审计报告的需求，我建议采用关系型数据库+文档型数据库的混合架构。具体来说，结构化的财务报表数据（如科目、金额、日期等）用MySQL存储，通过按客户ID分库、按日期分表，并在client_id、report_date建复合索引优化查询；非结构化的审计报告（文本、附件）用MongoDB存储，按客户ID分片，并在client_id、report_content建全文索引提升检索效率。同时，通过两阶段提交保障数据一致性（如审计报告更新时同步财务报表关联数据），通过读写分离和Redis缓存优化性能与扩展性，满足未来数据增长的需求。
6) 【追问清单】
- 问题1：如何选择关系型和文档型数据库的具体产品（如MySQL vs PostgreSQL，MongoDB vs Elasticsearch）？
回答要点：根据数据规模、查询复杂度、团队技术栈选择，比如MySQL适合事务密集型结构化数据（如财务报表），MongoDB适合非结构化文档（如审计报告）；Elasticsearch适合大规模全文检索（如审计报告全文）。 - 问题2：分库分表策略中，分片因子如何选择？比如按客户ID分片，分片因子10是否合理？
回答要点：分片因子需根据数据量、并发访问量选择，比如客户ID范围较大时，分片因子10（10个分片）可平衡扩展性与查询性能，未来数据增长时可增加分片数量（如分片因子20）。 - 问题3：数据一致性如何保证？比如审计报告更新时，财务报表中的关联数据是否同步？
回答要点：通过两阶段提交（2PC）或Saga模式（最终一致性）保障一致性，比如审计报告更新时，触发事务更新财务报表中的关联字段，确保数据同步。
7) 【常见坑/雷区】
- 坑1：只选择单一数据库类型，忽略结构化与非结构化的差异，导致性能瓶颈（如用关系型存储非结构化数据，导致Schema灵活性问题）。
- 坑2：分库分表策略不合理，比如按日期分表导致跨日期查询性能差（如按年分表，跨年查询需跨多个表）。
- 坑3：忽略数据一致性，比如非结构化数据更新时，结构化数据未同步，导致数据不一致（如审计报告更新后，财务报表中的关联字段未更新）。