企业官网建设流程全解析

做后端开发的人，大概率都遇到过这样的选型困惑：同一个系统里，既有设备上报的监控数据，又有文本搜索需求，还想要支持“找相似文章”的推荐功能。MySQL 明显扛不住高频写入的海量指标，Redis 只能解决缓存问题，Elasticsearch 能搜文本但不擅长算相似度。于是，时序数据库、向量数据库这些名词开始频繁出现在技术方案里。

这两个数据库经常被放在一起讨论，但它们并不是竞品。放到数据库家谱里看，它们是两个完全不同的分支：时序数据库解决的是“数据随时间不断追加，怎么高效写入、压缩和聚合”的问题；向量数据库解决的是“怎样在高维空间里快速找到最相似的向量”的问题。把这两类数据库放在一起对比，不是为了分出谁更强，而是为了搞清楚自己手头的业务到底属于哪一种数据形态。

这篇文章会用对比的方式，把时序数据库和向量数据库的概念、核心能力、适用边界、实操示例和排查思路讲清楚。读完以后，你应该能回答三个问题：这两类数据库分别解决什么问题？它们的底层差别在哪里？如果我要引入其中一种，第一步应该怎么做。

1. 数据库家谱的两个分支：怎么从“通用数据库”长出了专用数据库

数据库家族的谱系，最早其实很简单。上世纪九十年代到现在，关系型数据库一直是业务系统的绝对主角，MySQL、PostgreSQL、Oracle 这类产品解决的核心问题，是“有结构的事务数据怎么可靠存储和查询”。订单、用户、库存、账务，这些数据之间存在明确的关系，需要外键、事务、ACID 保证，所以关系模型是最匹配的。

但数据世界不会只停留在“一张订单表存一百条记录”的阶段。当数据的形态和访问模式发生变化时，通用数据库开始显得力不从心，于是新的分支不断从家族谱里长出来：

• 业务状态数据：关系型数据库 MySQL、PostgreSQL。
• 缓存型数据：内存数据库 Redis。
• 全文检索数据：搜索引擎 Elasticsearch。
• 海量离线分析数据：分析型数据库 ClickHouse、Doris。
• 不断追加的时序数据：时序数据库 InfluxDB、TDengine、Prometheus。
• 高维向量数据：向量数据库 Milvus、Qdrant、Weaviate，以及 PostgreSQL + pgvector 这类轻量方案。

1.1 通用数据库解决的是“关系建模”

关系型数据库默认的数据模型是“表 + 行 + 列”，一切设计都围绕范式展开。它擅长的是等值查询、范围查询、多表关联、事务一致性。它的索引结构（B+Tree）对“按主键查找一条记录”这种访问模式非常友好，大部分业务系统的核心 OLTP 场景，都建立在这个基础上。

但关系型数据库的劣势也很明显：它对“数据形态”有要求。如果数据是一条一条不断追加、几乎不更新的日志型数据，或者数据是一串代表语义的高维向量，你用表结构硬建模，不仅存储效率低，查询也很别扭。

1.2 时序数据为什么不能直接用关系型数据库

举个例子。你有一个工业设备监控系统，每台设备每 5 秒上报一次温度、湿度、电压、电流。一台设备一天会产生 17280 条数据，1000 台设备一天就是 1728 万条。这样的数据有几个显著特征：

• 只有追加，几乎没有更新。
• 写入量巨大且持续不断。
• 查询一般按时间窗口进行，比如“最近 5 分钟”“最近 1 小时”的平均值。
• 数据有明显的时效性，超过保留周期后就可以清理。

如果把这种数据存进 MySQL，首先会碰到写入瓶颈，单机 MySQL 能承受的稳定写入速率是有上限的；其次，一张表里堆积几亿行历史数据后，聚合查询会非常慢，需要不断加索引，但索引又拖慢写入；最后，清理过期数据只能 DELETE，严重的时候还会产生锁竞争。这本质上是因为 B+Tree 和事务机制为“状态记录”做了太多额外工作，而时序数据根本不需要这些保证。

1.3 向量数据为什么不能直接用关系型数据库

向量数据的形态完全不同。一段文本、一张图片、一段语音，经过神经网络模型处理后，会变成一个固定维度的数组，比如 768 维或者 1024 维浮点数。业务需要做的事情，是“给定一个目标向量，找出库里最相似的 N 个向量”。

有人会说，这不就是一个 ORDER BY distance 的问题吗？按欧氏距离或者余弦相似度排序，SQL 也能写。问题是，向量维度一高，关系型数据库的 B+Tree 索引就失效了。B+Tree 适合排序数据，而高维向量的维度之间没有自然大小关系，“找最近邻居”本质上是在高维空间做近邻搜索。在没有空间索引的情况下，只能全表扫描计算距离，一百万个向量时勉强能撑住，一亿个向量时性能会彻底失控。

所以，专用数据库解决的是“通用数据库它擅长和不擅长之间那道清晰的分界线”问题。

2. 时序数据库：为“随时间不断追加的数据”而生

时序数据库（Time Series Database，TSDB）最核心的假设是：数据一定带有时间戳，并且按照时间顺序不断产生。

2.1 时序数据长什么样

时序数据可以拆成几个部分：

• 时间戳：数据产生的时间。
• 度量值：实际监控的数值，比如温度、CPU 使用率、订单数。
• 标签：描述数据来源的维度，比如设备 ID、机房、城市、应用名。
• 字段：附加的属性信息。

用 InfluxDB 的行协议来表达，大概是这样的格式：

sensor_data,device_id=dev-001,region=beijing temperature=23.5,humidity=60.2 1700000000000000000

这行数据包含：measurement 是 sensor_data，tags 是 device_id=dev-001 和 region=beijing，fields 是 temperature=23.5 和 humidity=60.2，最后一个数字是纳秒级时间戳。

这套模型把“用于过滤的维度”和“用于计算的数值”分开，和普通关系表的设计思路有明显区别。

2.2 时序数据库的核心能力

时序数据库能解决业务问题，靠的是下面几个能力：

• 顺序写入优化：时序数据天然是追加写，TSDB 会把这一特征发挥到极致，通常写入吞吐量远高于关系型数据库。
• 列式存储与压缩：相同类型的数值连续排列，压缩率很高，能大大降低存储成本。
• 保留策略与自动清理：可以设置数据只保留 30 天，过期数据自动删除，避免手动维护。
• 降采样：把原始数据按时间窗口聚合，比如把 5 秒粒度聚合成 1 分钟粒度的平均值，支持多级存储。
• 连续查询：定期预计算一些常用聚合指标，查询时直接读结果。

2.3 时序数据库的典型场景

时序数据库最适合三类场景：

• 基础设施监控：主机 CPU、内存、磁盘、网络指标。
• 物联网设备数据：传感器上报、车联网轨迹、工业设备状态。
• 业务指标监控：实时订单量、接口延迟、错误率。

但要注意，时序数据库并不适合存储“需要频繁更新”的业务数据。如果某些数据会不断修改，整体上更像业务状态，而不是时序数据，那应该继续放在关系型数据库里。

3. 向量数据库：为“相似度搜索”而生

向量数据库（Vector Database）的崛起，和 AI 应用的高速发展紧密相关。大模型带火了 RAG（检索增强生成）架构，而 RAG 的一环，就是要把知识库切成片段、转成向量、存起来，然后在用户提问时检索最相关的片段。

3.1 先从嵌入（Embedding）讲起

嵌入是深度学习模型的一种数据表示方法。一个句子不能直接参与数学运算，但它的语义可以通过一个高维向量来表达，语义相近的句子在向量空间中的距离更近。

比如“今天天气怎么样”和“今天天气如何”语义接近，它们对应的向量在 768 维空间中的余弦距离就会很小；“Java 和 Python 哪个好学”对应的向量则距离较远。嵌入模型输出的这些向量，就是向量数据库的输入。

3.2 向量数据库的核心能力

向量数据库要解决的核心问题，是“在千万甚至上亿级别的向量中，快速返回与查询向量最相似的 TopN 个结果”。仅仅做到这一点还不够，还需要支持：

• 高维索引：常用的有 HNSW（基于图的算法）和 IVF（倒排文件）等近似最近邻索引。
• 相似度度量：余弦相似度、欧氏距离、内积等。
• 元数据过滤：比如过滤掉 class 不为 A 的向量再检索。
• 实时增删改：支撑文档更新后的重写和删除。

近年来的一个趋势是“混合检索”。单纯做向量相似度，可能在语义上抓到相关句子，但无法精确控制关键词约束；单纯用 BM25 做关键词检索，又理解不了同义改写。所以很多系统会把两种结果合并排序，提升检索效果。现在主流向量数据库基本都会同时提供全文检索能力，例如 Milvus 的混合检索方案、Qdrant 对 payload 过滤的支持。

3.3 向量数据库的典型场景

向量数据库最常见的应用包括：

• RAG 知识库问答：把企业文档转成向量，用户提问时找到相关片段再送给大模型。
• 相似图片搜索：以图搜图、素材库去重。
• 推荐系统：把用户和物品映射到向量空间，计算用户向量和物品向量的相似度。
• 异常检测：把行为序列转成向量，找出离群样本。

一句话概括：只要计算对象能在模型层变成向量，并且业务核心是“找相似”，向量数据库就比传统数据库更适合。

4. 两者对比：数据形状、读写模型和适用场景

时序数据库和向量数据库经常被混提，是因为它们都属于“专用数据库”，路径依赖不一样。但如果把它们放在一起对比，差异非常明显。

4.1 数据结构对比

4.2 写入模式和读取模式对比

时序数据库的写入是典型的“追加型写入”，数据按时间有序到达，几乎不存在随机写。这种模式对 LSM-Tree、分段文件、预分配内存池这些技术非常友好，所以优秀 TSDB 的写入吞吐量可以达到每秒几十万甚至上百万点。查询则以时间范围为主，比如拖出某台设备最近 6 小时的全部指标，或者按 5 分钟窗口做 AVG、MAX、MIN 聚合。

向量数据库写的是一条条“带语义的向量”，写入时不仅要把向量落盘，还要更新向量索引。HNSW 这种图索引在插入数据时需要逐层查找并建立连接，写入成本比普通键值存储要高一些。读取模式则是近似最近邻查询，给一个向量，返回距离最小的 N 条记录，本质是 ANN 搜索。

4.3 索引和扩展方式对比

时序数据库的索引主要服务“时间范围 + 标签过滤”，通常用倒排索引配合布隆过滤器，快速定位符合条件的序列。水平扩展时，最常用的是按时间分区，把不同时间范围的数据分布到不同节点。

向量数据库的索引是 ANN 索引。HNSW 把向量组织成层次化图结构，搜索时从顶层开始逐层接近目标；IVF 则先做聚类，查询时只扫描少数几个聚类桶。向量库的水平扩展，一般会把向量集合按分片拆分到不同节点，每个节点持有部分数据。

4.4 典型用途对照表

5. 实操示例：先用简单工具跑通两个场景

这里不讨论大型生产集群，先用最轻量的方式把两个方向跑通。

5.1 环境准备与选型

时序数据库选 InfluxDB 或者 TDengine 都可以。InfluxDB 的行协议简洁，TDengine 的优势是 SQL 风格语法，贴近国内开发者的习惯。本文以 TDengine 为例演示时序场景，因为它可以直接用类似 SQL 的语法操作，学习成本比较低。版本请以实际项目为准，本文不绑定具体版本号。

向量数据库选 PostgreSQL + pgvector 作为入口。原因是它能在现有 PostgreSQL 环境里直接添加扩展，不需要单独部署一套新服务，适合做 POC。如果数据量达到千万级以上，再评估独立的向量数据库。

演示环境假设如下：

• Linux 或 macOS，已安装 Docker。
• Python 3.9+，已安装 psycopg2-binary。
• 已经获取向量数据库的访问地址和账号。

5.2 时序数据建模和写入示例

假设有一个设备监控系统，设备每 10 秒上报一次温度和湿度。TDengine 的建模思路是创建超级表，把静态标签放 TAGS，把动态采集值放字段。

-- 进入 TDengine 命令行 CREATE DATABASE monitor KEEP 30 DURATION 10; USE monitor; CREATE STABLE devices ( ts TIMESTAMP, temperature FLOAT, humidity FLOAT ) TAGS ( device_id VARCHAR(64), region VARCHAR(32) ); INSERT INTO devices VALUES ('2024-01-01 10:00:00', 23.5, 60.1, 'dev-001', 'beijing'), ('2024-01-01 10:00:10', 23.6, 60.0, 'dev-001', 'beijing'), ('2024-01-01 10:00:20', 23.8, 59.8, 'dev-001', 'beijing');

这里的关键是：TIMESTAMP列存储时间，TAGS里的 device_id 和 region 会作为索引维度，查询时能快速过滤出某个设备的数据。KEEP 30表示数据保留 30 天，DURATION 10表示按 10 天一个文件分片，过期自动清理。

5.3 时序数据聚合查询示例

写入数据后，最常用的操作是计算某个设备最近 5 分钟的平均温度和最大湿度。

SELECT _wstart, AVG(temperature) AS avg_temp, MAX(humidity) AS max_humidity FROM devices WHERE device_id = 'dev-001' AND ts >= NOW - 5m GROUP BY _wstart INTERVAL(1m);

GROUP BY _wstart配合INTERVAL(1m)，是在一秒钟范围内聚合数据，结果可能包括 5 个窗口，每个窗口有该分钟内的平均温度和最高湿度。这种聚合能力，是传统关系型数据库很难做得又简单又快的。

如果未来数据量增大，还可以用连续查询，把 1 分钟粒度聚合结果预先算好，长期保存；原始数据可以只保留更短的时间。

5.4 向量数据初步存储和相似度查询示例

先创建表和索引：

CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE documents ( id serial PRIMARY KEY, content text, embedding vector(768) ); CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

这里建了一张文档表，embedding 字段是 768 维向量，实际维度要按你用的嵌入模型来定，例如 BGE、OpenAI 的 text-embedding-3 系列等。HNSW索引是近似最近邻索引，vector_cosine_ops表示使用余弦相似度。

插入一条数据，向量部分用字符串数组表示：

INSERT INTO documents (content, embedding) VALUES ( '时序数据库适合处理设备监控和指标存储', '[0.0123, -0.0456, 0.0789, ...]' );

中文省略号表示中间省略了实际向量数据，真实场景里你会用模型把文本转成完整数组。

查询最相似的 5 条记录：

SELECT id, content, 1 - (embedding <=> '[0.0123, -0.0456, 0.0789, ...]') AS similarity FROM documents ORDER BY embedding <=> '[0.0123, -0.0456, 0.0789, ...]' LIMIT 5;

<=>在 pgvector 里表示余弦距离，取相反方向，1 - 余弦距离正好等于余弦相似度，值越接近 1 越相似。这里的核心是：查询不是“等于”，而是“按距离排序”。

5.5 示例运行后的预期结果

时序查询的预期输出大约是这样的：

向量查询的预期输出则是按 similarity 降序排列的文档列表，第一条应该是与查询文本语义最接近的那条内容。

6. 运行结果与效果验证

跑通以后，不能只满足于“数据能查出来”，还要明确怎么判断效果。

6.1 时序场景的验证指标

时序数据库的效果主要看四个点：

• 写入速率：用压测工具持续写入，看每秒能否支撑几十万点，观察是否有背压或限流。
• 查询延迟：按设备维度拉取一段时间的数据，正常应该在毫秒级或者百毫秒级。
• 压缩比：看原始数据量和占用磁盘的关系，是否达到预期压缩率。
• 过期清理：在保留窗口外插入旧数据，确认被自动清理。

6.2 向量场景的验证指标

向量数据库的效果主要看三个点：

• 时延：在百万级向量规模，单次查询应该能稳定在几十毫秒内完成。
• 召回率：对比暴力全量计算得到的真实 TopK，看 ANN 索引结果有多少重合。
• 写入索引延迟：批量写入后，索引更新的延迟是否在可接受范围内。

在中小型 POC 阶段，可以先不纠结召回率，直接用一条明显相似的文本做查询，确认相似度最高的记录是“语义相关”的数据，而不是随机结果。

6.3 出现失败时优先检查什么

时序场景跑不出数据，先查三处：

• 是否切换到了正确的数据库和表。
• 时间条件是否超出了保留窗口。
• 标签过滤条件是否写错。

向量场景查询时报错，也先查三处：

• 向量维度和表定义是否一致。
• 插入的向量是否真的是合法浮点数组。
• 索引创建时使用的距离算子，是否和查询时一致。

7. 常见问题与排查思路

这些排查思路不局限于某一个数据库产品，在其他 TSDB 或向量数据库产品上同样适用。

8. 最佳实践与工程建议

8.1 数据建模原则

时序数据建模时，不要照搬关系型思维。把高频查询过滤条件设计成 TAGS，而不是 FIELDS。因为标签会走索引，字段值则参与计算，如果拿字段做过滤，查询性能会明显下降。

向量数据建模时，要保证每条向量都有业务主键和元数据。后续的过滤、去重、删除，都需要借助主键来完成。向量维度不要随意调整，一旦混合使用多个不同维度的模型，清洗成本会很高。

8.2 容量与保留策略

时序数据最典型的成本问题，是“明明只关心最近 30 天的数据，却把所有历史数据长期保留”。生产环境建议分层设计：

• 热数据：保留最近 7 天，粒度最细，服务实时监控和告警。
• 温数据：保留 1 个月到 3 个月，用降采样后的聚合数据，服务趋势分析。
• 冷数据：如果要做年度统计，可以归档到对象存储或分析型数据库。

向量数据的主要成本在于索引内存。HNSW 索引对内存消耗较高，生产部署时要评估参数：M控制每个节点的连接数，efConstruction控制建索引时的搜索宽度，过大会导致建索引慢、内存占用增加。建议先用小规模数据测试，观察内存和查询时延，再逐步调参。

8.3 向量索引和混合检索

如果数据量在百万级以下，pgvector 这类关系型扩展可以直接胜任。如果目标是十亿级向量，或者需要复杂过滤、动态更新、多租户隔离，独立向量数据库会更合适。

在 RAG 场景中，只用向量检索不一定是好方案。可以先走 BM25 全文检索召回候选，再用向量相似度重排；或者先做元数据范围过滤，再做向量检索，这样既能控制召回范围，又能提升业务相关性。

8.4 安全与权限规范

无论是时序数据库还是向量数据库，接入生产环境后都必须避免使用默认账号和弱密码。权限遵循最小原则：

• 业务应用只授予读写自身业务库的权限，不授予管理权限。
• 创建单独账号用于数据迁移和任务调度。
• 向量库如果存储用户敏感信息，要注意脱敏，避免把身份证号、手机号直接放进向量。
• 删除数据前先备份，恢复前不轻易执行 DROP。

8.5 避免过度设计

并不是所有监控类数据都必须上时序数据库。如果你一天只有几百条日志，MySQL 加个时间索引完全够用。也并不是所有推荐功能都必须上向量数据库。只有当“相似度检索”成为真实瓶颈，或者关系型数据库已经出现明显性能问题时，再引入专用库才是合理的。

技术选型要警惕“全家桶冲动”：指标数据非要放到数据库家族里的每个分支跑一遍，反而增加了维护成本。

9. 总结与后续学习方向

时序数据库和向量数据库，名义上都叫“数据库”，定位却完全不同。时序数据库解决的是持续追加的数据怎么高效写入、压缩、聚合和清理的问题，核心是时间维度和高吞吐写入；向量数据库解决的是高维空间下怎么快速找相似的问题，核心是向量索引和最近邻检索。理解数据形态、写入模式、查询模式、索引机制这四条差异线，就足以在早期阶段为自己的系统找到正确方向。

如果你准备进一步实践，可以从三条路径继续：

• 把设备或应用监控数据完整跑一遍 TDengine 或 InfluxDB，尝试设计保留策略和降采样规则。
• 在 PostgreSQL 里用 pgvector 做一个小型 RAG，用中文嵌入模型把文档切块、存储、查询，观察不同 embedding 模型对召回效果的影响。
• 如果业务的数据量已经超过百万级，可以去了解 Milvus 或 Qdrant 的分片部署和索引配置。

最后提醒一句：数据库选型不是越新越好，也不是越专用越好。一个项目里同时有 MySQL、Redis、Elasticsearch、时序数据库、向量数据库，不一定代表架构先进，也可能代表技术团队没有认真思考数据之间的关系。先把问题的数据形态想清楚，再做选型，很多弯路原本都可以不走。