企业官网建设流程全解析

在业务系统选型时，经常遇到一个绕不开的问题：数据到底该放进哪类数据库。传统关系型数据库能解决大部分问题，但当数据变成“每秒钟产生的监控指标”或“一段文本的语义向量”时，直接往 MySQL 里硬塞往往越用越别扭。这篇博客把时序数据库和向量数据库放到“数据库家谱”里做一次系统梳理，说明白它们各自诞生于什么需求、擅长解决什么问题、适合放在什么场景中。

数据库家谱：时序数据库和向量数据库，各自解决什么问题？

最近在整理团队内部技术选型笔记时，我发现很多开发同学对数据库的理解还停留在“MySQL 存业务数据，Redis 做缓存，Elasticsearch 做搜索”这个层面。一旦遇到 IoT 设备上报的传感器数据、App 埋点日志、推荐系统里的用户向量特征，就开始纠结：这些东西能不能用同一套存储？为什么一定要引入新的数据库？

我的建议是：先别急着“选”，先把数据库的“家谱”理清楚。只有知道每一类数据库是为什么问题而生的，才能判断它适不适合你的业务。本文重点对比两个最近几年非常热门的成员：时序数据库和向量数据库。它们名字里都带“数据库”，解决的问题却完全不同，很多初学者会混淆。

读者可以带着三个问题来读这篇文章：

1. 时序数据和向量数据分别是什么样子的？
2. 这两类数据库各自解决了传统数据库解决不了什么问题？
3. 我的业务到底该选哪一个？

读完你应该能掌握它们的核心定位、适用场景、基础用法和选型思路。

1. 数据库家族谱系：为什么会有这么多数据库

1.1 一个容易被忽略的事实：数据库不是为了“存数据”而诞生的

很多人理解数据库，第一反应是“用来存数据的软件”。这个说法没错，但不够准确。数据库真正的价值，是在特定数据模型下，提供高效的写入、查询、分析、生命周期管理能力。

同样一段文字，如果只是存成一个字符串，MySQL 没问题；如果要做全文搜索，MySQL 的 LIKE 查询会慢到让人怀疑人生，这时就有了 Elasticsearch；如果数据带有大量关联关系，比如“好友的好友”这种图结构，MySQL 写 SQL 也会很痛苦，于是有了图数据库。

所以数据库的演化路径，本质上是一条“数据模型 + 访问模式”的演化路径。

1.2 数据库家谱的简化版

按数据模型和访问模式，可以把常见数据库粗略分成以下几大分支：

这个表格不是严格的分类学，但它能帮你建立第一印象。本文重点看最后两行：时序数据库和向量数据库。

1.3 两类数据库的共同起点：传统数据库不够用

为什么传统关系型数据库处理不了时序数据和向量数据？原因不太一样。

对于时序数据，比如一台服务器每秒上报一条 CPU 使用率，一天就是 86400 条，一个月就是 259 万条，如果几百台设备一起上报，数据量会迅速膨胀。传统数据库的 B+ 树索引结构在这种高并发写入 + 海量时间范围扫描的场景下，写入性能和存储成本都不理想，更不用说还要做按时间窗口的聚合分析。

对于向量数据，比如把一段文本通过模型转成 768 维的向量，一个普通的业务表可能只有几万条、几十万条数据，数量并不大。但问题是：我们要做的不是精确匹配，而是“找到和某个向量最接近的 K 条”。这种基于向量距离的相似度检索，传统 B+ 树很难高效支持，必须用专门的向量索引结构和近邻搜索算法。

所以本质上，这两类数据库是因为传统数据库在特定数据形态 + 特定查询模式下不够高效，才被独立出来的。

2. 时序数据库：为“带时间戳的指标流”而生

2.1 什么是时序数据

时序数据，简单理解就是“每隔一段时间就会产生一条，且每条都带有时间戳的数据”。常见例子：

• 服务器 CPU 使用率、内存使用率、磁盘 IO。
• 工业设备温度、压力、振动频率。
• 车辆 GPS 坐标、速度。
• App 用户活跃数、接口响应耗时。
• 天气站点的温度、湿度、风速。

这类数据的显著特点有四个：

• 高写入吞吐：数据持续不断产生，尤其 IoT 场景，可能每秒写入几十万条。
• 追加写入为主：通常只在末尾追加，极少修改历史数据。
• 按时间维度查询：查询基本都带时间范围，比如“最近 5 分钟”“最近 24 小时”。
• 数据有生命周期：老数据价值衰减很快，需要自动清理或降精度保存。

2.2 时序数据库解决什么问题

时序数据库的核心目标是解决两个矛盾：

第一个矛盾是**“海量写入”和“聚合查询”并存**。举个例子，你采集了 1000 台设备一周的 CPU 数据，可能有数亿条记录。业务方不会一条条看，而是想看“这一周每台设备的平均 CPU”“每天最大内存峰值”。如果每条数据都放在 MySQL 里，聚合查询可能需要扫描大量行。而时序数据库通常把数据按时间分区，配合预聚合、压缩和列式存储，可以大幅减少扫描量。

第二个矛盾是**“数据永不停歇”和“存储资源有限”**。时序数据的价值随时间递减，全部原始数据永远保留既不现实也不经济。时序数据库一般提供数据保留策略，自动把超过 N 天的旧数据删除，或者通过降采样把原始精度数据聚合成分钟级、小时级数据。

所以时序数据库的价值可以概括为：高效写入、按时间高效查询、自动老化处理、内置时间类聚合分析。

2.3 与传统数据库的关键差异

传统数据库做时序场景也不是完全不行，但代价很高。举个例子，MySQL 里建一张监控表：

CREATE TABLE metrics ( device_id VARCHAR(64) NOT NULL, ts TIMESTAMP NOT NULL, metric_name VARCHAR(32) NOT NULL, metric_value DOUBLE NOT NULL, PRIMARY KEY (device_id, ts) );

这张表能存数据，查询也能写出来。但问题出在几个地方：

1. 每条指标一行，如果设备多、指标多，行数膨胀得特别快。
2. 按时间范围做GROUP BY聚合时，MySQL 往往要扫描大量行，还需要额外建索引去优化，索引又反过来拖慢写入。
3. 冷数据清理要自己写定时任务，删除千万级历史数据时性能风险很大。

而时序数据库的底层设计会针对这些点做专门优化。以常见的时序数据库为例，写入链路通常使用类 LSM 结构，顺序写入友好；存储层会对相同标签和指标做压缩；查询引擎会按时间片裁剪数据，并提供降采样操作。

2.4 时序数据库核心功能一览

不同时序数据库产品功能强弱有差异，但以下几个概念几乎是标配：

• 数据模型：一般围绕“采集目标/标签 + 指标 + 时间戳”建模。比如 TDengine 的超级表，InfluxDB 的 measurement + tag + field。
• 数据保留策略 / 自动老化：定义数据保留周期。
• 降采样 / 连续查询：把原始精度数据转化为粗粒度数据。
• 时间窗口聚合：time_bucket、interval这类按时间段分组的查询能力。
• 流式写入支持：通过 HTTP API、MQTT、Kafka Connector 等方式接收数据。

下面用一个 InfluxDB 风格的示例来演示时序查询的基本思路。需要注意不同版本语法略有变化，这里重点展示概念。

-- 概念示例：按1分钟窗口计算平均CPU使用率 SELECT mean(cpu_usage) AS avg_cpu FROM metrics WHERE host = 'server-01' AND time >= now() - interval '1 hour' GROUP BY time(1m)

这段查询表达的是：从metrics中筛出server-01最近一小时的数据，按照分钟窗口做平均。在传统 SQL 表里也能写类似逻辑，但时序数据库会针对时间索引和时间分区做裁剪，避免全表扫描。

2.5 时序数据库的典型业务场景

时序数据库最成熟的应用场景是：

• 基础设施监控：采集服务器 CPU、内存、网络指标，配合 Prometheus、Grafana 做监控大盘，这是监控体系里的标准方案。
• IoT 设备数据采集：海量设备持续上报传感器数据，要求高并发写入和数据老化策略。
• 金融行情与量化指标：股票行情、交易撮合延迟等按时间排序的数据。
• 车联网与物流轨迹：车辆位置、速度、里程数据的高频采集与区间分析。

在这些场景里，业务关注的不是“某一条数据”，而是“一段时间的趋势、异常和聚合值”。如果你发现自己写的 SQL 总是where create_time between ... and ...，且数据量已经到千万、亿级，那说明时序数据库值得纳入选型范围。

3. 向量数据库：为“近似语义匹配”而生

3.1 什么是向量数据

向量数据是指把非结构化数据通过某种方式映射成一组数字。比如把文本“我喜欢编程”用预训练模型转成长度为 768 或 1024 的浮点数数组，这个数组就是文本的“向量表示”，也叫嵌入向量。同样，图片、音频、用户行为序列都可以转成向量。

向量数据有几个特点：

• 维度很高：常见的有 128 维、512 维、768 维、1024 维。
• 本身没有直观含义：向量里的单个数字不代表某个业务字段，而是模型学习出来的特征分布。
• 查询目标不是“相等”：更多是“哪个向量和我查询的向量最接近”。

这里的接近度通常用数学距离来衡量，最常用的是余弦相似度、欧几里得距离、内积。

• 余弦相似度：更适合衡量方向是否一致，常用于文本语义相似度。
• 欧几里得距离：更适合衡量数值空间中的绝对距离。
• 内积：在推荐场景中比较常见，和向量模长也有关。

3.2 为什么传统数据库做不了向量检索

也许你会想：向量不就是数组吗？MySQL 不是也能存 JSON 数组吗？为什么还要专门的向量数据库？

关键在于查询方式不一样。传统数据库的索引适合等值查询和范围查询，比如id = 123、age BETWEEN 20 AND 30。而“找出与某向量最相似的 Top K 个向量”是一个最近邻搜索问题。

如果数据只有几百条，暴力计算没问题。但向量数据通常配合 AI 场景，规模至少几十万、上百万甚至数十亿条，这时候就不可能每条都算一遍距离。向量数据库的核心能力是提供近似最近邻搜索，例如：

• HNSW：基于分层跳跃表结构的图索引，适合高召回、低延迟在线检索。
• IVF：先聚类，再在候选分区内搜索，适合大规模数据、内存受限的场景。
• PQ 量化：对向量压缩后计算，能节省内存但会损失一定精度。

这些索引算法被集成到 Milvus、Qdrant、Weaviate、Elasticsearch（向量模块）等产品中。开发者在业务代码里调用搜索接口时，其实不需要手写这些算法，但理解索引原理对你选择参数、排查召回不准问题非常有帮助。

3.3 向量数据库解决什么问题

向量数据库解决的问题，本质上是让程序能够按“语义相似”来检索数据。

以文本场景为例，传统搜索是关键词匹配，搜“苹果”能匹配到包含“苹果”两个字的文档。而向量检索会把查询文本和候选文本分别编码成向量，即使文档里写的是“水果公司”“库克”，只要语义相近，向量距离也会很近。这大大提升了搜索、推荐、去重、知识问答等场景的体验。

向量数据库的典型能力可以总结为：

• 相似度检索：给定一个查询向量，返回最近的 Top K 个向量。
• 混合过滤：在向量检索基础上，按标签、业务字段做条件过滤。
• 规模扩展：分布式存储海量向量，支持上亿级别数据。
• 和 AI 模型无缝配合：嵌入向量由模型生成，向量数据库负责存储和检索。

3.4 一个最小化向量检索示例

下面用一个极简的思路展示“向量检索”的逻辑，用 Python 的numpy就能跑通核心步骤。假设我们已经有了几条预置向量，查询向量是中间那条文本编码出来的。

import numpy as np # 假设这是3条候选文本的向量表示，实际项目里通常由嵌入模型生成 candidate_vectors = np.array([ [0.12, 0.34, 0.56, 0.78], [0.21, 0.43, 0.65, 0.87], [0.98, 0.76, 0.54, 0.32], ]) # 查询向量 query_vector = np.array([0.20, 0.40, 0.60, 0.80]) # 计算余弦相似度 def cosine_similarity(a, b): return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) # 计算每条候选和查询的相似度 for idx, vec in enumerate(candidate_vectors): score = cosine_similarity(query_vector, vec) print(f"第 {idx + 1} 条候选向量相似度: {score:.4f}")

运行结果大致是第一条相似度最高，因为两个向量方向几乎一致。真实项目里你不会手动写这个计算逻辑，而是调用向量数据库的search接口，但理解这层距离计算原理，能帮你明白为什么向量检索和传统 SQL 完全不一样。

如果接入 Milvus 这类产品，调用方式会变成类似这样：

# 伪代码演示：向量数据库查询接口的抽象形态 from pymilvus import connections, Collection connections.connect(host="127.0.0.1", port="19530") collection = Collection("article_embeddings") results = collection.search( data=[query_vector], anns_field="embedding", param={"metric_type": "COSINE", "params": {"ef": 64}}, limit=10, output_fields=["doc_id", "title"], )

同样的代码逻辑在不同产品中 API 名称会不一样，所以这只是“接口形态”示例。你想说明的核心是：向量数据库把“距离计算 + 索引检索 + 候选召回”这个过程封装成了类似search的高层接口。

3.5 向量数据库的典型业务场景

向量数据库目前最活跃的场景是：

• 大模型知识库 / RAG：把文档拆成 chunk，转成向量后存储，用户提问时先检索相关文档片段，再交给大模型生成答案。
• 以图搜图 / 以文搜图：商品图片检索、相似图片去重。
• 推荐系统召回阶段：用户和物品向量化后做相似召回。
• 企业文档去重与查重：判断相似文档，避免重复审核。
• 人脸识别 / 语音识别后处理：把识别结果转成向量做身份比对。

如果你发现自己的业务需求是“语义相近”“相似内容”“匹配一下最像的”，那大概率需要向量检索能力。

4. 时序数据库和向量数据库的核心对比

4.1 它们解决的本质问题不同

一句话总结：

• 时序数据库解决的是“海量带时间标签的数据如何写入、聚合、老化”的问题。
• 向量数据库解决的是“高维数据如何按距离快速检索相似项”的问题。

这两个问题完全不同。前者是时间维度 + 数据量的挑战，后者是维度高 + 距离计算复杂度的挑战。

4.2 从数据形态维度对比

4.3 能不能用一套系统同时解决两类问题

这是很多团队在选型时纠结的点。我的建议是：优先看主查询模式，不要想着一个系统包打天下。

如果你的业务是“监控指标 + 少量向量标签过滤”，那应该以时序数据库为主，把向量检索当成扩展能力接入。如果你的业务是“AI 语义检索 + 附带的业务过滤”，那应该以向量数据库为主，再配合传统数据库存储原始业务数据。

不少多模型数据库产品也在尝试同时支持时序和向量，比如 PostgreSQL 的扩展可以处理 JSON、数组、甚至向量索引，但这不等于你可以完全忽略专用数据库。在数据量和查询复杂度上来之后，专用数据库的运维、性能、生态往往更有优势。

5. 实战选型：拿到业务需求，怎么判断用哪类数据库

5.1 选型前的四个问题

如果接到一个需求，先不要急着引入新数据库。问自己四个问题：

问题一：数据最核心的维度是什么？

• 如果每条记录都强依赖“时间先后顺序”，查询基本都带时间范围，优先考虑时序数据库。
• 如果查询是“给我最相似的 Top K”，且数据是模型生成的向量，优先考虑向量数据库。

问题二：数据量级有多大？

• 每秒写入几万条、总数据量达到百亿的指标数据，传统数据库扛不住，应该用时序数据库。
• 数据量只有十万条，但你要做语义检索且要求毫秒级响应，暴力计算已经不行，应该用向量数据库。

问题三：查询模式是聚合还是相似度？

• “过去一小时每分钟的平均 CPU”是聚合，时序数据库最擅长。
• “找和我这段文本语义最接近的 10 条”是相似度，向量数据库最擅长。

问题四：和 AI 流程是否有强关联？

• 如果数据是模型的 embedding 输出，通常绕不开向量数据库。
• 如果数据来自设备上报、监控系统，通常绕不开时序数据库。

5.2 一个业务描述到选型结果的示例

假设业务需求是：一套工业设备管理系统，每台设备 5 秒上报一次温度、压力、运行状态；同时维护一份设备说明书知识库，客服输入问题后要搜索最相关的文档段落。

这个系统同时存在两类数据和两类查询模式：

• 设备监控数据：高频上报、按时间聚合，分析设备异常趋势 → 时序数据库。
• 说明书知识库：文本向量化后做语义检索，帮客服快速找到答案 → 向量数据库。

所以结论很清晰，不是一个二选一的问题，而是两类数据库在同一个业务中分别承担不同职责。这也是大型系统中常见的组合方式。

5.3 混合架构形态

在很多实际项目中，时序数据库、向量数据库、关系型数据库会并存。一种常见的参考架构是：

1. 关系型数据库存用户、订单、设备档案等主数据，保证事务。
2. 时序数据库存设备运行指标，支撑监控大屏、告警分析。
3. 向量数据库存文档、图片、商品特征向量，支撑语义检索和推荐。
4. 消息队列连接上述环节，数据进入不同数据库进行专职存储。

架构图不画了，用文字描述：设备 → 采集程序 → 消息队列 → 时序数据库；文档 → 解析/切分 → Embedding 模型 → 向量数据库。这种专职分工的思路，比把所有数据塞进一个大而全的系统更可控。

6. 常见误区与理解偏差

6.1 误区一：时序数据库只能做监控

监控确实是时序数据库最经典的应用，但不是全部。金融行情、设备日志分析、车联网轨迹、能源采集，都是时序数据的典型场景。它的本质是“按时间序列产生、需要高吞吐写入和时间聚合的数据”。

6.2 误区二：向量数据库就是“给数据库加一个搜索功能”

有些开发同学觉得，Elasticsearch 已经支持向量检索了，是不是不需要向量数据库？这个想法有一定道理。如果你的向量数据量不大、并发不高，用带向量插件的搜索引擎确实可以。但数据量到千万级以上，或者你需要更高密度的向量索引、更灵活的分区管理，专用向量数据库的分布式能力和索引优化会更深厚。选型要看规模和场景，不能只看某个功能点。

6.3 误区三：向量数据库能取代传统数据库

向量数据库不适合做事务、不适合做精确统计报表，也不适合作为唯一的数据源保存业务主数据。正常做法是传统数据库保存“业务事实”，向量数据库保存“语义索引”，两者通过 ID 关联。例如商品表在 MySQL，商品向量在 Milvus，搜到向量后再回 MySQL 查商品详情。

6.4 误区四：时序数据库不需要考虑建模

时序数据库虽然写入简单，但建模同样重要。如果标签设计不合理，比如把高基数的设备 ID 塞进标签，又建了很多不合适的索引，查询性能依然会崩。时序数据的模型设计核心是：把“过滤条件字段”作为标签，把“数值指标”作为字段，把高基数唯一标识作为表主键的一部分。

7. 从“选库”到“用好库”：工程实践建议

7.1 时序数据库的工程实践建议

• 明确保留周期：创建时序表时就定义好数据保留天数，避免磁盘被历史数据占满。
• 合理设计标签与字段：标签尽量使用低基数数据，比如机房、地域、服务名；高基数数据如设备 ID 作为主键一部分处理。
• 优先写入批量数据：比起单条写入，批量写入能明显提升吞吐，减少网络开销。
• 监控写入队列长度：高并发写入时，如果采集程序写入速度跟不上，要注意背压和重试机制。
• 冷热分层要提前规划：原始高频数据保留短周期，降采样后的分钟级、小时级数据保留更久，这样既省钱又满足趋势分析。

7.2 向量数据库的工程实践建议

• 向量维度不是越高越好：高频维度会带来更大的存储和计算开销，实际项目中需要结合模型效果和部署成本来选择。
• 索引参数需要压测：HNSW 的efConstruction、M参数会影响索引构建时间和召回率，不能照搬默认值。
• 建立向量和业务 ID 的映射：向量库里最好只存向量和主键，不要把大文本直接灌进去，业务详情由关系库承担。
• 理解近似检索的召回率问题：向量检索是近似搜索，不是完全精确的暴力搜索，线上评估要关注召回不准确的风险。
• 定期对脏向量做清理：模型版本升级后，老向量可能需要重新生成，否则新旧向量分布不一致会导致检索质量下降。

7.3 安全与合规建议

这两类数据库都涉及数据生命周期管理，使用时要特别注意：

• 访问控制：生产环境的数据库实例必须开启至少账号密码或鉴权，避免裸奔部署。
• 数据传输加密：采集端与数据库之间、应用与数据库之间的连接建议开启 TLS。
• 数据脱敏：如果时序数据中包含用户设备位置、业务操作详单，考虑脱敏后再入库。
• 最小权限思想：普通应用账号只授予所需最小权限，例如机器学习应用只需要对向量集合的读写权限，不需要管理权限。
• 变更操作先在测试环境验证，比如调整索引参数、修改保留策略，先在影子环境看看效果再上生产。

7.4 从数据量的角度做容量评估

无论选时序还是向量，系统上线前都要回答三个容量问题：

1. 每天新增多少原始数据？一个月、一年后总量是多少？
2. 预设查询响应时间是多少？P99 要求多少毫秒？
3. 存储成本和查询性能之间，你更倾向哪个方向？

时序数据库往往通过压缩和降采样控制存储量；向量数据库往往通过索引类型和量化压缩控制内存消耗。评估时不要凭感觉估，建议直接用业务真实数据样本做压测。

8. 最后聊几句选型心态

技术选型最容易陷入的误区是“听到一个新名词，觉得不用就落伍了”。但数据库家谱里没有真正的“银弹”，时序数据库和向量数据库也不是彼此的替代品。它们各自解决不同维度的核心痛点：

• 如果你的数据和时间强相关，高频写入、按时间聚合、自动老化，时序数据库是更匹配的选择。
• 如果你的数据要支持语义相似度检索，查询模式是“最接近的 Top K”，向量数据库是更匹配的选择。
• 如果你的业务两种场景都有，那就按各自适合的场景组合使用，而不是强行用一个库承担所有。

下一步如果你是初学者，我建议动手做两件事。第一，找一个开源时序数据库，比如 InfluxDB 或 TDengine，把一段真实的 CPU 监控数据导进去，写一个按时间窗口求平均的查询。第二，用 Python 把一个文本列表做成向量，接一个向量数据库，跑通“查询 → 召回 → 回表”的完整链路。跑通一次之后，你对这两类数据库的认知会比看十篇对比文章都深。

如果本文对你梳理数据库选型有帮助，可以收藏备用。后续我会继续更新其他几类“专用数据库”的笔记，包括图数据库、列式分析数据库在新一代数据架构中的实际定位。