理解数据库之外，真实系统还需要哪些数据能力。
文件与 Excel、内容与媒体、数据看板、账号与权限、库存与抢购等场景
文件存储、缓存和搜索是三类专用数据系统，分别解决大文件保存、高速访问和复杂检索。
图片、PDF、Excel、热点数据和全文搜索无法只靠普通业务表高效完成。
位于后端周围，与数据库共同组成数据能力层。
对象存储、上传流程、CDN、浏览器缓存、Redis、搜索引擎和数据库。
头像上传、报告下载、页面加速、登录会话和文档搜索都依赖这些能力。
数据库擅长结构化记录，对象存储擅长保存大量二进制文件。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户上传合同、图片和 Excel 附件，并在项目详情中查看。
把大文件直接塞进关系型数据库会增加备份、迁移和查询压力。
文件存入 Object Storage 的 Bucket，数据库只保存文件名、大小、类型、权限和地址等 Metadata。
设计上传、预览、下载、删除、版本和权限时，要区分文件本体与文件记录。
图片、视频、PDF 和 Excel 体积较大，访问方式也和普通表记录不同。对象存储以 Bucket 和 Object 管理文件，提供高容量、低成本和稳定下载。
数据库通常保存文件名称、URL、大小、类型、上传人、业务归属和状态。这样既能查询业务关系，也能让文件系统独立扩展。
文件卡片展示的信息来自数据库，真正下载的内容来自对象存储。
上传涉及客户端、后端、存储和数据库多个环节。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
创作者上传长视频，移动网络中途断开。
普通单次上传需要从头重传，文件越大失败成本越高。
客户端通过 Presigned URL 直传对象存储，Multipart Upload 分片上传，Checksum 验证完整性。
需要设计分片进度、暂停继续、失败重试、取消和上传后处理状态。
文件本体已经到达对象存储，系统仍需读取、校验和写入数据。
把上传完成和业务处理完成混为一体，会让用户误以为数据已经可用。
上传成功后创建异步导入任务，文件状态与解析任务状态分别保存。
进度条要区分“上传”和“处理”，失败后提供错误报告与重试。
客户端先选择文件并检查类型与大小。后端可以接收文件后转存，也可以生成 Presigned URL，让客户端直接上传到对象存储。
上传完成后，系统保存文件元信息并与业务对象关联。大文件还要处理分片、断点续传、进度、取消、重试和病毒扫描。
上传界面需要覆盖选择、校验、传输、处理中、成功、失败、取消和重新上传。
用户上传 Excel 后，文件先进入对象存储，后台 Worker 再异步解析，页面显示“上传中—解析中—成功/失败”。
CDN 把内容缓存到更靠近用户的边缘节点。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
图片源站在东京，欧洲用户浏览包含几十张高清图的详情页。
每次都从源站跨洲下载会增加延迟和带宽压力。
CDN 把静态资源缓存到附近 Edge Node，并通过 Cache-Control 决定缓存时长。
设计图片尺寸、渐进加载、失败占位和版本更新，避免旧资源长期缓存。
用户请求图片或脚本时，CDN 优先从附近节点返回；没有缓存时再回源到对象存储或服务器。这样可以降低延迟和源站压力。
缓存时间、版本文件名和刷新策略决定内容何时更新。资源地址变化或内容版本化可以避免用户拿到旧文件。
图片加载速度、缩略图质量和多尺寸裁切会直接影响内容型产品体验。
缓存用临时副本减少重复请求和计算。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
几千名用户反复查看相同的经营指标。
每次实时计算会压垮数据库，但缓存又可能让页面数据过期。
浏览器、CDN、后端和 Redis 都可缓存结果，TTL 决定过期时间，业务变更时需要 Cache Invalidation。
显示更新时间、刷新入口和数据时效说明；刷新期间可保留旧数据并标注正在更新。
浏览器可以缓存静态资源，CDN 缓存公共内容，后端内存缓存局部结果，Redis 缓存跨实例共享的数据。不同层的命中范围和失效方式不同。
缓存的难点在更新。数据改变后要删除、覆盖或等待过期，否则用户会看到旧数据。缓存适合高频读取、变化相对可控的内容。
看到“刷新后才更新”或不同端数据不一致时，可以怀疑缓存与同步策略。
缓存通常保存可重建的临时副本；数据库承担长期事实数据。
Redis 是高速内存数据服务，常用于缓存和短期协调。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户频繁点击发送验证码，攻击脚本也可能批量调用接口。
短信成本上升，接口可能被滥用。
Redis 用 Key-Value 保存手机号的发送次数和 TTL，实现快速 Rate Limit。
按钮显示倒计时、剩余次数和恢复时间，限制原因要清楚。
高峰期多个服务器同时处理同一张券的领取请求。
多个请求都可能读取到“剩余 1 张”，造成超发。
Redis 可参与原子扣减或 Distributed Lock，保证关键更新按规则执行。
页面要处理排队、已抢完、结果确认中和重复领取。
Redis 支持字符串、集合、哈希、队列等结构，常用于热点数据、登录 Session、验证码、计数器、排行榜和限流。
它也可以实现简单分布式锁或消息能力，但要评估持久性、一致性和故障恢复。核心业务事实通常仍保存在数据库。
倒计时、在线状态、排行榜和实时计数可能来自 Redis，而非直接查询主数据库。
全文检索需要分词、相关性和倒排索引等专门能力。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
电商用户输入自然语言，希望命中包含相关词、同义词和不同排序的商品。
关系型数据库适合精确过滤，复杂全文匹配和相关性排序能力有限。
Search Engine 通过 Inverted Index 快速查找词项，并按 Relevance 排序。
需要设计拼写纠错、筛选、排序、无结果推荐和高亮命中词。
数据库擅长精确条件和结构化关系，搜索引擎擅长关键词、模糊匹配、同义词、权重、高亮和聚合。Elasticsearch 等系统会把业务数据建立成搜索索引。
数据库仍是事实来源，索引通常通过同步任务更新。同步存在延迟时，用户可能刚创建内容却暂时搜索不到。
搜索体验要设计关键词建议、无结果、纠错、筛选、相关性和索引延迟。
先看数据形态、访问方式、一致性和生命周期。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
一个 SaaS 同时保存核心账户、图片文件、短期会话和海量搜索行为。
按“工具流行”选择存储会让一致性、成本和查询方式不匹配。
账户数据库作为 Source of Truth；头像放对象存储；会话放 Redis；日志进入分析系统。选择依据是 Access Pattern 和 Data Lifecycle。
产品方案中标注数据是否关键、是否允许延迟、保留多久、如何查询和删除。
结构化核心业务放关系型数据库，大文件放对象存储，高频临时结果放缓存，全文检索放搜索引擎。日志、指标和向量也可能使用专门存储。
成熟系统经常同时使用多种数据系统。增加一种技术会增加同步、监控、备份和维护成本，选择要由真实需求推动。
听到“都放一个地方最简单”时，先判断当前规模；听到“每种都上”时，也要考虑运维成本。
为“上传并搜索课程资料”画出数据库、对象存储、Redis、搜索引擎各自保存什么。