在广告投放系统中，如何设计用户行为日志和广告素材的存储方案？请说明数据库选择（如MySQL、HBase、ES）以及索引策略，如何保证查询效率和数据一致性。

1) 【一句话结论】广告投放系统中，用户行为日志因高并发写入与多维度查询需求，采用HBase（时序+宽列存储）并设计时间+用户ID+广告ID联合索引；广告素材元数据用MySQL（主键+多列索引）存储，实际文件存对象存储（如MinIO），兼顾数据一致性与存储扩展性，同时明确业务对用户行为日志的一致性要求（强/最终）并说明HBase的适用性。

2) 【原理/概念讲解】用户行为日志是广告投放的核心数据，包含用户ID、广告ID、行为类型（点击、浏览等）、时间戳、设备信息等多维度信息，具有**高并发写入（秒级）、多维度查询（按时间、用户、广告筛选）**的特点。广告素材是静态文件（图片、视频），包含文件元数据（ID、类型、大小、上传时间）和实际文件（存对象存储）。
数据库选择需匹配数据特性：

• MySQL：适合结构化、事务性数据（如广告素材元数据，需ACID保证一致性）；
• HBase：适合海量、可伸缩的列式存储（如行为日志的宽列结构，支持高并发写入与多维度查询）；
• ES：适合全文搜索（若涉及内容检索，但本题侧重存储方案，故不重点提及）。
  索引策略需针对查询场景设计，如用户行为日志的联合索引覆盖常用查询条件（时间+用户ID+广告ID），减少全表扫描。若业务对用户行为日志有强一致性需求（如实时统计），需结合HBase与分布式事务（如两阶段提交），但需权衡性能。

3) 【对比与适用场景】

数据库类型	定义	特性	使用场景	注意点
MySQL	关系型数据库	事务支持、ACID、结构化存储	广告素材元数据（结构化、需事务）、用户行为日志的少量结构化数据（如统计报表）	写入性能受限于单机，不适合海量写入；强一致性场景需额外事务方案
HBase	Hadoop生态列式存储	海量、可伸缩、时序/宽列、最终一致性（默认）	用户行为日志（高并发写入、多维度查询）、日志数据	需Hadoop集群，写入延迟可能较高；强一致性需分布式事务（如两阶段提交），影响性能
ES	分布式搜索引擎	全文搜索、实时索引	广告素材内容检索（如图片搜索）、用户行为日志的全文查询（如关键词搜索）	不适合结构化数据的高并发写入；索引维护成本较高

4) 【示例】

• 用户行为日志存储（HBase）：
  • 表名：user_action_log
  • 列族：actions（存储行为类型，如click、view）、metadata（存储设备信息，如device_type、os_version）
  • 行键：user_id:ad_id:timestamp（如1001:2001:20230101000000）
  • 示例数据：
    • 行键1001:2001:20230101000000
      • actions:click
      • metadata:device_type=mobile,os_version=11.0
  • 查询（按用户ID和广告ID查询过去7天的点击行为）：
    伪代码：SCAN row => '1001:2001:20230101', row => '1001:2001:20230107', columns => ['actions:click']
• 广告素材元数据存储（MySQL）：
  • 表名：ad_material
  • 字段：material_id（PK）、material_type（VARCHAR）、size（INT）、upload_time（TIMESTAMP）、storage_url（VARCHAR）
  • 索引：material_id（PK）、material_type（INDEX）
  • 示例数据：
    • material_id=1001, material_type=image, size=1024, upload_time=20230101000000, storage_url=minio://ad-materials/1001.jpg
  • 查询（按类型查询图片素材）：
    SQL：SELECT * FROM ad_material WHERE material_type='image'

5) 【面试口播版答案】在广告投放系统中，用户行为日志和广告素材的存储方案要分场景设计。用户行为日志因高并发写入和多维度查询需求，采用HBase（时序+宽列存储），通过时间+用户ID+广告ID的联合索引优化查询效率；广告素材元数据用MySQL（主键+多列索引）存储，实际文件存对象存储（如MinIO），兼顾数据一致性与存储扩展性。同时，明确业务对用户行为日志的一致性要求（强/最终），若需强一致性，可结合HBase与分布式事务（如两阶段提交），但需权衡性能。

6) 【追问清单】

• 如何保证用户行为日志的数据一致性？→ 回答要点：若业务要求强一致性，采用HBase+分布式事务（如两阶段提交），但需注意性能影响；若为最终一致性（日志类数据），HBase默认最终一致性，结合时间戳排序确保数据有序。
• HBase高并发写入如何优化？→ 回答要点：通过批量写入（Batch Write）减少网络开销，预写日志（WAL）保证数据持久性，降低写入延迟。
• 强一致性需求下HBase的适用性如何权衡？→ 回答要点：HBase本身是最终一致性，强一致性需额外事务方案（如两阶段提交），会增加系统复杂度和性能开销，需根据业务场景（如实时统计的容忍度）决定。
• 广告素材版本管理如何实现？→ 回答要点：在MySQL元数据表中增加version字段，每次更新时递增版本号；对象存储中保留历史版本（如MinIO的版本控制），或通过API实现版本回滚。
• 数据备份策略是什么？→ 回答要点：用户行为日志定期全量备份（如每日）+增量备份（如每小时）；广告素材元数据与对象存储文件同步备份（如异地备份，如AWS S3的跨区域复制）。

7) 【常见坑/雷区】

• 直接用MySQL存储用户行为日志导致性能瓶颈：MySQL单机写入性能有限，无法支撑秒级高并发写入，且查询多维度数据时效率低。
• 未明确业务一致性要求就选HBase：HBase默认最终一致性，若业务需要强一致性，未补充分布式事务方案，会导致数据不一致问题。
• 索引设计不合理：未针对查询场景设计联合索引（如时间+用户ID+广告ID），导致查询时全表扫描，影响效率。
• 广告素材用关系型数据库存储大文件：大文件存储在关系型数据库会导致存储效率低下（如1MB文件占100MB空间），且查询性能差（如按文件内容搜索需全文检索，MySQL不适合）。
• 忽略HBase写入延迟优化：未提及批量写入、预写日志等优化措施，显得方案不落地。