任务10.3 时序数据库 & 任务10.4 向量数据库
大数据工程技术专业
在前面的学习中，我们掌握了关系型数据库（MySQL）和文档数据库（MongoDB）。它们非常强大，但世界上不是所有数据都适合存进一张表里——不同形状的数据，需要不同形状的"容器"。
如果要记录全校1万名学生每秒钟的心跳数据，持续一年——每天产生8.64亿条记录，传统MySQL每秒要面对数十万次写入，它的B+树索引会在这种压力下瞬间崩溃。
手机的人脸识别，是如何在0.1秒内从几亿张脸中找到"你"的？它不是靠逐像素比对照片——那样比到天荒地老也比不完——而是靠提取512个关键特征点做相似度搜索。
这就是我们今天要学习的两位主角：时序数据库 与 向量数据库
时间就是生命：理解监控与IoT数据的基石
AI的"外挂大脑"：理解非结构化数据的灵魂
大数据工程师的兵器库
Time Series Database: 记录时间的脚印
时序数据 (Time Series Data) 是以时间为主要维度的一系列数据点。每一条数据都必须跟一个"什么时候"绑定——没有时间戳的数据，不叫时序数据。这种数据的特点是：写入频率极高、几乎不修改历史记录、新数据像河水一样源源不断追加进来。
关键特征：每一个数据点都有一个时间戳 (Timestamp)。 有了时间戳，我们才能按时间范围查询、做趋势分析、画时间序列图表——这是时序数据库一切能力的基础。
我们要测量的对象，比如"北京的气温"、"服务器的CPU使用率"、"快递车的行驶速度"。指标回答了"我们在观察什么"——它是数据的主体视角，就像报表的标题。
描述数据的元属性，如"传感器ID: 001"、"地点: 教室三楼"、"设备型号: TH-200"。标签让我们可以在一大堆数据里按条件筛选——"只看教室三楼的温度"，"只看型号TH-200的设备"。
真实的数值本身，如"23.5"、"75%"、"1024"。度量值是我们真正关心的数字——它随时间的波动形成趋势线，是我们做统计计算和画图表的最终原料，也是判断"正常还是异常"的依据。
这三者加上时间戳，就构成了一个完整的时序数据点。理解这个四元组结构，就掌握了时序数据库的"原子单位"。
写入压力巨大：
一个化工厂有10万个传感器，每秒采集一次。MySQL每秒要处理10万次INSERT——每次都要更新B+树索引、写redo日志、检查约束。在这种强度下，磁盘IO瞬间打满，数据库要么慢到不可用，要么直接宕机。更致命的是：时序数据"写多读少"，MySQL花大力气维护的那套复杂索引，绝大多数场景下根本用不到——纯属资源浪费。
"别写了，我的B+树索引调整不过来了！服务器要冒烟了！CPU 100%，磁盘队列排到了明年！"
DELETE FROM table WHERE date < '...' 是大忌——它会逐行删除并逐行调整索引，删一亿行等于数据库自杀，要么死锁要么性能自由落体。于是，专门为时间序列数据量身打造的"时序数据库"诞生了！
时序数据库采用 LSM树 或类似结构，将随机写变为顺序写。数据先写入内存缓冲区，攒够一批再一次性刷入磁盘——就像快递分拣中心把包裹先堆到传送带上，整批装车，效率远超一个一个搬运。
MySQL像是在图书馆里找书架位置放书——每一次都要走到正确的过道、找到正确的格子、小心翼翼地插进去（很慢）；
时序数据库像是在流水线上疯狂往传送带里扔快递——不管什么顺序，来了就堆上去，后续再统一整理（极快）。
时序数据有很多重复项和规律性变化，可以使用专门算法（如 Delta-on-Delta、Gorilla编码）进行极限压缩。这些算法不存绝对值，只存"相比上一个值变了多少"——大多数时候变化量是0或很小，几个字节就够。而MySQL存的是完整浮点数，每条8个字节起步。
100 GB
5 - 10 GB
节省了近 90% 的硬盘空间！这意味着同样一台服务器可以多存十倍的历史数据。
设置"保存策略"后，旧数据到期自动"消失"。和MySQL逐行DELETE不同，时序数据库是按时间段分块存储的——删一个块只需改一条元数据，不产生碎片，不影响在线读写。就像撕掉一整本日历，而不是一页一页撕。
把"每秒"的高频数据自动汇总成"每分钟"或"每小时"的统计值（平均值、最大值、最小值）。既保留了长期趋势用于年报分析，又释放了大量存储空间。核心思想是"数据分层"：越近越精细，越远越粗糙——聪明地平衡了查询灵活性和存储成本。
在时序数据库中，我们很少查"某一秒"的数据——单点没有意义。真正有价值的是"一段时间内的统计规律"：过去一小时的温度变化趋势、最近七天服务器的CPU峰值、上个月每天的用电总量。时序数据库的查询引擎高度优化了时间范围过滤和时间聚合这两类操作，比MySQL的GROUP BY快数十倍。
查询示例 (InfluxQL):
SELECT MEAN("temperature") FROM "sensors" WHERE time > now() - 1h GROUP BY time(1m)
意思：查询过去1小时内，每分钟的平均气温。注意两个关键操作——时间范围过滤（WHERE time条件）和时间聚合（GROUP BY time）。
智能工厂里的机器人臂、电表、水表、温湿度传感器——数以万计的设备每时每刻都在发射数据信号。一个中型工厂每天可能产生数十亿条传感器记录。
核心应用：实时监控设备健康状态，通过分析振动频率、温度变化等时序数据，提前预测零件何时会坏——这就是"预测性维护"，每年为工厂节省数百万的意外停机损失。
另一个典型场景：电网智能电表每15分钟上报一次用电量，电力公司需要实时掌握全城用电峰谷，动态调度发电——底层全是时序数据库在支撑。
这是大数据工程师最常用的场景：监控服务器集群的CPU使用率、内存消耗、磁盘IO、网络流量。当某个指标超过阈值，系统自动发短信或钉钉报警——在问题影响到用户之前就发现它。
Prometheus定期抓取各服务器指标
TSDB高效存储海量监控点
Grafana画出炫酷的实时大屏
这套"Prometheus + TSDB + Grafana"组合，是当今互联网公司运维监控的事实标准——你以后工作中一定会遇到。
股票价格每毫秒的变动都是一条时序数据。你在炒股软件上看到的那根K线，背后是几百万条原始tick数据的聚合——时序数据库在几毫秒内完成了这个计算。
高频交易系统需要在极短时间内分析过去几分钟的价格变动趋势，判断该买入还是卖出。TSDB提供的毫秒级聚合查询能力，是整个量化交易系统的核心基础设施。
不只股票——加密货币交易所、外汇市场、期货交易，全部依赖于时序数据库来存储和处理以毫秒为粒度的市场数据流。
目前全球最流行的开源时序数据库，用Go语言编写。自带类SQL查询语言（InfluxQL/Flux），上手门槛极低，生态完善，中小企业首选。
云原生监控领域的绝对霸主。CNCF毕业项目，Kubernetes原生集成。它自己就是一个TSDB+采集器+报警引擎的合体，几乎每个互联网公司都在用。
国产开源之光，涛思数据出品。专门针对物联网场景做了极致优化——单机写入性能可达数百万点/秒，特别适合国内制造业和能源行业。
趁热打铁，用刚才学的知识判断一下：下列哪个数据最适合存入时序数据库？
A. 学生的基本信息（姓名、班级、学号）
B. 气象站每隔10分钟上传的降雨量数据
Vector Database: AI时代的"外挂大脑"
在数学中，向量是一串有序数字，如 [0.1, 0.5, -0.2, 0.8, ...]。它表示的是高维空间中的一个"坐标点"——维度可以高达几百甚至上千。人脑无法想象768维空间长什么样，但计算机处理起来毫无压力。
在AI眼里，万物皆可向量。通过深度学习模型，各种数据被"编码"成固定长度的数字序列：
向量代表了事物的语义特征——不是表面的字或像素，而是深层含义的数字表达。相似的东西，在向量空间里"距离"很近；不相似的东西，距离很远。这就是向量数据库一切魔法的起源：通过计算向量距离来度量"像不像"。
如果你要把10亿张脸存进数据库：普通数据库存的是照片文件本身——一堆像素的集合，对计算机来说是"死数据"，它不知道谁和谁长得像。
向量数据库存的却是每张脸经AI模型提取后的512个关键特征点——眼距、鼻高、颧骨位置、脸型比例……这叫"活指纹"，可以直接用来计算两张脸的相似度。
当你想找一个"长得像周杰伦"的人时，不是逐像素比对10亿张照片——那样算到天荒地老也算不完。而是把周杰伦的脸也转成512维向量，然后在向量数据库里瞬间找出"距离最近"的那些向量——它们对应的脸就是最像的。整个过程毫秒级完成。
向量数据库 (Vector Database) 是一种专门设计用于存储、索引和查询大规模向量数据的数据库。它与传统数据库最本质的区别：不靠关键字匹配找数据，而是靠"向量距离计算"找语义上最相似的数据。
它的工作流程（记住这三个关键词）：
1. 嵌入 (Embedding)： 用AI模型（如OpenAI的Embedding模型、视觉模型CLIP）把非结构化数据转成向量。一个PDF、一张猫的图片、一段会议录音——全部变成一串数字。同一个模型产出的向量处于同一个向量空间，可以直接比较。
2. 存储与索引： 把向量连同元信息存入VDB。VDB自动为这些高维向量建立专门的索引结构（如HNSW、IVF），就像给一座巨型图书馆建立了一套"语义导航系统"。
3. 检索： 用户输入查询（文字或图片），同样转成向量，VDB在已建好索引的数亿条向量中找出"距离最近"的K个结果并返回——整个过程在几十毫秒内完成。
传统搜索靠的是关键词匹配——你搜什么字，它就找什么字。多一个字、少一个字、换个说法，它就"不认识了"。这是机械匹配，不是语义理解。
搜"西红柿"，搜不到"番茄"——因为两个字完全不一样，算法不知道它们说的是同一种东西。更糟糕的是：搜"昨天会上说的那个项目进度怎么样了？"，传统搜索只能拆成"昨天""会议""项目进度"去找，完全理解不了这一整句话的真实意图。
搜"西红柿"，能搜到"番茄"——因为AI模型知道它们语义几乎重叠，向量距离极近。搜一段话，能匹配到意思相近的段落，即使用的词完全不同。这就是"语义搜索"：不是找相同的字，而是找相同的含义。
传统数据库无法对非结构化数据（视频、音频、长文本）做语义理解——而这正是AI时代最核心的需求。
向量数据库不找"完全相等"的记录——那叫查字典，不叫搜索。它找的是"最像"的。为了实现这一点，它采用 ANN (近似最近邻) 算法——在速度上做巧妙牺牲，在毫秒级返回"虽然不是100%精准但足够好用"的Top-K结果。
MySQL: SELECT * WHERE id = 10。必须一模一样才返回，差一个字符都不行。这是"查字典"思维。
VDB: 找出相似度 > 95% 的Top 10。不需要精确相等，只要"足够像"就返回。这是"理解"思维。
为什么是"近似"？因为在十亿级高维向量中精确找出绝对最近的K个，计算量太大（暴力计算需要几千秒）。ANN算法通过巧妙的索引结构，把这个时间压缩到几十毫秒——对99%的应用场景，这个精度已经绰绰有余。
普通数据库索引通常是一维的（比如价格从低到高排序就行）。向量数据库处理的是几百甚至上万维的空间——想象一个拥有768个坐标轴的坐标系，每一个数据点都在里面占一个位置。
这些技术能在十亿级向量中实现毫秒级检索。作为对比：暴力计算所有向量距离，十亿条数据即使每条只需1微秒，也要耗时1000秒——而ANN索引把它压缩到几十毫秒，提速了数万倍。
只要能转成向量，它都能存——文本、图片、音频、视频，在向量数据库的眼里，它们只是不同维度的数字序列，一视同仁。这彻底打破了数据类型的壁垒。
JPG/PNG → CLIP等视觉模型 → 512/1024维向量
PDF/DOCX → Embedding模型 → 768/1536维向量
用文字搜图片、用图片搜视频——跨模态检索成为可能
这就是"以文搜图"背后的技术：文字和图片被映射到同一个向量空间，距离近的就是匹配。
抖音、淘宝、Netflix 如何知道你喜欢什么——甚至比你自己更懂你？
推荐系统的向量化流程：
1. 把你的所有浏览历史、点赞、停留时长、搜索记录等行为，汇总转成一个代表你"兴趣偏好"的高维向量。
2. 把平台上成千上万个商品/视频，也各自转成向量。
3. 向量数据库在毫秒内计算离你"兴趣向量"最近的几百个物品向量——这些就是最适合推给你的内容。
结果： 你一刷就是三小时，根本停不下来！这不是巧合——全球最大的视频和电商平台，推荐引擎的核心就是向量数据库驱动的相似度计算。
在百度或谷歌上传一张照片，秒级找到同款商品或相似图片——核心技术正是向量数据库。
用户拍一张想找的商品照片
视觉AI模型提取图像特征
在亿级图片向量库中找最近邻
按相似度排序呈现给用户
安防人脸布控、医疗病理切片比对、电商"拍立淘"——底层全是这套流程。
ChatGPT等大模型有两个致命短板：一是会"胡说八道"（幻觉），编造不存在的事实和数据；二是它不知道你公司内部的文档和最新的行业新闻——它的训练数据截止于某个时间点，对那之后的世界一无所知。
把公司的所有产品文档、技术手册、会议纪要、历史工单全部转成向量，存入向量数据库。当用户提问时：
第一步（检索）： 先去向量数据库里搜索与问题语义最相关的文档片段——这些片段成为给大模型的"参考资料"。
第二步（增强）： 把检索到的资料连同用户的原始问题一起，精心组织成提示词，喂给大模型。
第三步（生成）： 大模型基于真实资料来生成回答，而不是凭空臆想——幻觉被大幅抑制。
向量数据库是大模型的"外挂硬盘"——没有它，大模型是一个记忆力只有7秒的天才；加上它，大模型就有了一个可以随时查阅的无限知识库。
国产开源领军者，Zilliz出品，CNCF毕业项目。支持十亿级向量毫秒检索，已被全球数千家企业用于生产环境。想学向量数据库，从Milvus开始。
硅谷最火的云原生向量数据库，完全托管、无需自己部署运维、按用量付费。初创公司和快速原型开发的首选——几行代码就能用上向量搜索。
欧洲开源项目，自带多种AI模型集成（OpenAI、Cohere、HuggingFace），GraphQL原生支持，开发者体验极佳，上手速度最快的向量数据库。
| 维度 | 时序数据库 (TSDB) | 向量数据库 (VDB) |
|---|---|---|
| 核心轴 | 时间 (When) — 数据何时发生 | 语义特征 (What) — 数据是什么含义 |
| 查询目标 | 趋势、统计、聚合、时间范围 | 相似度、最近邻、Top-K语义匹配 |
| 主要挑战 | 写入吞吐量、存储压缩、数据过期 | 高维检索速度、召回率、索引构建 |
"老师，我觉得数据库好难，我也不会写AI模型，学向量数据库干嘛？"
1. 避开内卷： 所有人都会写SQL增删改查，但只有少数人懂向量数据库的选型、索引调优和RAG架构设计。懂这个，简历的含金量和工资起步线就不一样——这是典型的"人无我有"。
2. AI基建是蓝海： 未来所有AI应用——智能客服、自动驾驶、机器人视觉、AI搜索、智能推荐——底层全部需要向量数据库。你不需要会训练大模型，但你得会为大模型搭建"记忆系统"，这是未来三年最紧缺的工程能力之一。
3. 数据思维升级： 数据正在从"数字"变成"语义"——掌握的不只是"在哪建索引"，而是理解不同类型数据的本质，知道什么时候该用MySQL、什么时候上时序库、什么时候必须用向量库。这种判断力才是大数据工程师的核心竞争力。
很多同学以为"时序"就是简单的"时间顺序"——先把1点存了再存2点，仅此而已。实际上这个词的渊源比这个深得多。
在统计学中，时间序列 (Time Series) 是一个严谨的学术概念，它研究的是"按时间顺序排列的、具有内在相关性的随机变量序列"。翻译成人话：
今天的温度和昨天的温度不是独立的——它们之间有关联（如果昨天30℃，今天不太可能突然降到0℃）。时序数据库不仅记录"发生了什么"，它天然适合分析"数据如何随时间演化"——发现规律、识别异常、甚至预测未来。这就是"时序预测"的魅力所在。
当维度从我们熟悉的3维暴增到768维甚至1536维时，空间的性质发生了剧变——日常直觉完全失效。这就是著名的"维度灾难 (Curse of Dimensionality)"。
随着维度增加，空间的体积呈指数级膨胀。在高维空间中，所有数据点都变得极端稀疏——从任意一个点出发，到它"邻居"的距离都非常远。更可怕的是，传统的欧氏距离在高维空间中失去了区分度：所有点之间的距离都差不多，谁近谁远根本分不出来。
向量数据库存在的意义，就是通过高明的数学手段（如LSH局部敏感哈希、量化编码、HNSW图导航）在这个"巨大的荒漠"里快速定位两颗真正相近的"沙子"——克服维度灾难，让高维搜索变得可行。
在InfluxDB中，Retention Policy让我们对同一份数据的不同粒度版本设置不同的保存期限——这就是"阶梯式存储"思想：数据越老、粒度越粗；越新、越精细。
这就是"阶梯式存储"的精髓：每条数据的保留时长和它的粒度成正比——极大地平衡了查询灵活性和存储成本。
向量搜索用的是"近似搜索"（ANN）——它为了速度，故意不走全量暴力计算。所以它可能漏掉一些本该是最佳匹配的结果，也可能返回一些次优的结果。这不是bug，这是设计取舍。
召回率 (Recall)： 衡量搜索有多"全"。99%的召回率意味着：如果库里真的有100个高度相似的结果，ANN算法成功找回了99个——漏掉的那1个，就是速度和精度的代价。
作为大数据工程师，你需要理解这个核心权衡：
调大搜索参数（如HNSW的ef_search值）→ 召回率更高、结果更准，但查询变慢。
调小搜索参数 → 查询飞一样快，但可能漏掉一些好结果。
根据业务场景在速度和准确度之间找到最优平衡点——这是向量数据库工程师的核心手艺，也是面试中常被问到的深度问题。
某快递公司需要建设全面的信息化数据平台——你会如何做数据库选型？
用来存：快递车实时GPS位置轨迹（每秒上报）、货车油耗曲线、冷库温度监控。高频写入、按时间聚合、自动过期——TSDB的天然主场。
用来存：包裹破损拍照记录的特征。用户上传受损照片后，系统在向量库中检索历史相似案例，匹配责任方和理赔标准——VDB的语义搜索能力。
用来存：订单号、客户手机、收件地址、支付金额、物流状态。需要ACID事务保证、复杂关联查询和数据一致性——MySQL的经典主场。
一个成熟的系统从来不是"只用一个数据库"——而是根据不同数据的特征，为每种数据选择最合适的"家"。
遇到新项目时，先问自己三个问题：数据长什么样？查询要什么结果？有什么特殊约束？
选 TSDB（如InfluxDB）
选 VDB（如Milvus）
选 MySQL / PostgreSQL
未来的数据库可能不再分得这么细——已经出现了 "One Database" 的趋势。Redis Stack开始内置向量搜索模块，PostgreSQL通过pgvector插件支持了向量查询，MongoDB增加了时序集合（Time Series Collections）。
这意味着：未来一个数据库可能同时支持关系查询、文档存储、时序分析和向量检索——你不用在一堆数据库之间来回切换和同步数据。
但作为大二学生，你们要掌握的不是死记某个数据库的命令——那些在AI时代随时可以查。关键是理解不同数据类型的本质特征和针对性的处理思路。有了这种底层的"数据思维"，未来无论出现什么新数据库，你都能快速上手——这才是大学教给你的不可替代的能力。
回顾时序数据库的核心特征，以下哪一项不是时序数据库的设计特点？
向量数据库解决的核心问题是什么？为什么传统数据库做不到？
下节课我们从理论走向实践：
1. 在服务器上亲手安装部署 InfluxDB。
2. 编写Python脚本模拟采集全班同学电脑的温度和CPU使用率数据。
3. 通过 Grafana 连接InfluxDB，画出你人生第一张实时监控大屏——看到数据在屏幕前流动起来的那一刻，你会真正理解时序数据库的威力！
哪里听得云里雾里？尽管问！
（基础越差的同学，你的问题越有价值！）
数据驱动未来，你我皆是见证者。
作业：在手机APP中找出一个你认为使用了"向量数据库"的功能，下节课分享。