大连海事就业平台需存储大量求职者简历（结构化+非结构化）和港口企业数据，请比较传统关系型数据库与分布式数据库（如TiDB）的适用场景，并说明选择分布式数据库的理由（如扩展性、高可用）。
答案
1) 【一句话结论】：传统关系型数据库适合结构化、强事务场景，但存储大量非结构化简历时单节点扩展性受限（如TEXT字段大文本导致I/O瓶颈）；分布式数据库（如TiDB）通过水平扩展、高可用设计，更适合存储大量结构化+非结构化简历及港口企业数据，能应对数据量增长与业务高可用需求。
2) 【原理/概念讲解】：关系型数据库（RDBMS）基于ACID事务，数据结构化（表、列、行），通过SQL操作，适合事务密集型（如简历提交、企业信息更新），但扩展性受限于单节点性能（垂直扩展成本高，如增加CPU/内存）。分布式数据库（如TiDB）是分布式系统，数据水平分片（如按求职者ID哈希分片到不同节点），支持多节点部署，通过分布式协调（如Paxos保证一致性），实现高可用（节点故障不影响服务），且可动态扩容（增加节点提升性能）。类比：关系型数据库像传统图书馆，按书名索引，新增书籍需加书架（垂直扩展）；分布式数据库像分布式图书馆，每个分馆（节点）存储部分书籍，新增分馆（水平扩展），整体容量和借阅能力提升。
3) 【对比与适用场景】：
| 特性 | 传统关系型数据库（如MySQL） | 分布式数据库（如TiDB） |
|---|---|---|
| 定义 | 单节点集中式，结构化数据，ACID强事务 | 多节点分布式，支持结构化+非结构化，水平扩展 |
| 核心特性 | 事务强一致性（本地事务），垂直扩展 | 水平扩展（节点数量增加提升性能），高可用（故障转移） |
| 数据模型 | 结构化（表、列、行），TEXT/BLOB存储大文本 | 结构化（表）+非结构化（如简历文本、企业图片），支持大文本 |
| 扩展性 | 垂直扩展（提升单节点硬件，成本高） | 水平扩展（增加节点，成本相对低，可弹性伸缩） |
| 事务一致性 | 强（本地事务，事务隔离级别高） | 弱一致性（最终一致性，通过分布式事务保证，可能引入延迟） |
| 适用场景 | 事务密集型OLTP（如简历提交、企业信息更新，需严格一致性） | 大规模数据存储（简历、企业数据），高并发、高可用（如数据量百万级以上，业务需7×24小时服务） |
| 注意点 | 扩展性有限，数据量增长时性能瓶颈（如TEXT字段大文本导致I/O瓶颈），垂直扩展成本高 | 配置复杂（分片键设计、副本策略），学习成本高，但高可用带来的业务价值更高 |
4) 【示例】：假设存储求职者简历，传统关系型数据库（MySQL）创建表：
CREATE TABLE resume (
id BIGINT PRIMARY KEY,
name VARCHAR(100),
phone VARCHAR(20),
resume_text TEXT, -- 非结构化简历文本
port_company_id INT,
FOREIGN KEY (port_company_id) REFERENCES port_company(id)
);
插入数据：
INSERT INTO resume (id, name, phone, resume_text, port_company_id) VALUES (1, '张三', '13800138000', '有5年港口物流经验', 1);
分布式数据库（TiDB）分片策略（按id哈希分片，每个节点存储部分id范围），创建表：
CREATE TABLE resume (
id BIGINT PRIMARY KEY,
name VARCHAR(100),
phone VARCHAR(20),
resume_text TEXT,
port_company_id INT,
PRIMARY KEY (id, port_company_id) -- 复合主键，确保分片键唯一
) ENGINE=InnoDB;
插入数据：
INSERT INTO resume (id, name, phone, resume_text, port_company_id) VALUES (1, '张三', '13800138000', '有5年港口物流经验', 1);
TiDB自动将id=1的数据分片到节点1（假设哈希取模后落在节点1），查询时节点间协调，返回结果。若节点1故障，TiDB通过副本（如3副本）自动切换到节点2，保证数据不丢失。
5) 【面试口播版答案】：面试官您好，传统关系型数据库（如MySQL）适合结构化数据、强事务场景，但存储大量非结构化简历时，单节点扩展性受限——比如简历文本（TEXT字段）大，会导致I/O瓶颈，垂直扩展成本高。而分布式数据库（如TiDB）通过水平扩展，将简历按求职者ID分片到多个节点，新增节点即可提升存储和查询性能。同时，TiDB通过多副本（3副本）和分布式事务（两阶段提交）保证高可用，节点故障时自动切换，数据最终一致。因此，对于大连海事就业平台，选择TiDB能支撑数据量增长，保障业务连续性，满足简历存储和港口企业数据的高并发、高可用需求。
6) 【追问清单】：
- 问题1：分布式数据库如何保证事务一致性？
回答要点：通过分布式事务协议（如两阶段提交），节点间协调，最终保证数据一致性，但可能引入延迟（如事务阻塞）。 - 问题2：非结构化简历数据如何存储在分布式数据库？
回答要点：非结构化数据（如简历文本、附件）可存储在TEXT或BLOB字段，分布式数据库支持大文本存储，分片时按主键（如id）或哈希分片，保证数据分布均匀。 - 问题3：扩展性具体怎么实现？比如增加节点后性能提升？
回答要点：水平扩展，通过增加节点（如从3节点扩到5节点），数据分片负载均衡，查询时节点间并行处理，提升读写性能（如写入时分片，读取时聚合）。 - 问题4：与传统关系型相比，分布式数据库的维护成本如何？
回答要点：配置复杂（分片、副本策略），需要专业运维，但高可用带来的业务连续性价值更高（如避免数据丢失或服务中断）。 - 问题5：如果数据量达到百万级，分布式数据库的分片策略如何设计？
回答要点：按主键范围分片（如id范围），或哈希分片（如id取模），确保数据均匀分布，避免热点节点（如哈希分片可分散热点数据）。
7) 【常见坑/雷区】：
- 雷区1：认为传统关系型数据库能高效存储非结构化简历，忽略单节点I/O瓶颈（如TEXT字段大文本导致性能下降）。
- 雷区2：只说分布式数据库的事务一致性，没提分布式事务的延迟成本（如两阶段提交阻塞问题），导致面试官质疑高可用性。
- 雷区3：分片键选择不当，如按id范围分片导致热点（如新用户集中到某节点），影响性能。
- 雷区4：高可用方案只说节点故障切换，没提副本机制（如多副本备份，故障时自动切换），显得方案不完整。
- 雷区5：忽略传统关系型数据库的垂直扩展局限性，只说水平扩展，缺乏权衡分析（如特定场景下小数据量业务可能用传统数据库更简单）。