13 数据库开发 -- 向量数据库

一、总体架构

Milvus 和 MySQL 这两个具体数据库上，深入解析"写时分离"和"写时一体"的区别及其对应的使用场景。

---

1. "写时分离"和"写时一体"

特性维度	写时一体（MySQL）	写时分离（Milvus）
核心流程	写入数据时，立即修改数据页和索引，使其立即可查	写入数据时，先存为日志，异步处理后才可查
读写关系	读写强耦合，写入可能阻塞读取（锁）	读写解耦，写入基本不阻塞读取
一致性模型	强一致性，写后读一定能读到最新数据	最终一致性，写入后需要短暂延迟才能查到
性能特点	优化低延迟的随机读写	优化高吞吐的批量写入
扩展方式	垂直扩展为主，水平扩展复杂	天然水平扩展，各组件可独立伸缩
技术类比	实时更新的总账本	新闻出版流水线

---

1.1 具体到数据库的运作机制

MySQL（写时一体）

1. 写入路径：

   • 你执行一条 INSERT INTO users ... 语句
   • MySQL 会：
     • 申请行锁，防止其他并发写入
     • 在 Buffer Pool（内存）中修改数据页
     • 写入 Redo Log（重做日志，用于崩溃恢复）
     • 在事务提交时，保证所有修改持久化
   • 一旦事务提交成功，数据立即可被后续查询读到。

2. 设计哲学：

   • 数据的"当前状态"是至高无上的。
   • 任何操作都必须立即反映到这个"当前状态"上，并保证其正确性（ACID）。

Milvus（写时分离）

1. 写入路径：

   • 你通过 SDK 插入一批向量数据
   • Milvus 会：
     • 将这批数据转化为一条日志消息
     • 快速写入到日志存储（如 Kafka/Pulsar）中
     • 随即返回成功给客户端 —— 注意：此时数据还不可查！
     • 后台的 DataNode 组件异步消费这些日志，将其持久化到对象存储（如 S3）并构建索引
   • 经过一小段延迟（通常几百毫秒到秒级），数据才变得可被搜索。

2. 设计哲学：

   • "日志流"是真相的来源。
   • 系统的"当前状态"是通过回放日志计算出来的视图，不是直接修改的对象。

---

1.2 对应的使用场景

MySQL（写时一体）的适用场景

需要强一致性和即时可见性的在线事务处理场景：

• 银行转账：A 向 B 转账 100 元。转账成功后，B 的账户余额必须立即增加 100 元，并且任何后续查询都必须看到这个新余额。
• 电商库存管理：用户下单购买最后一个商品后，库存必须立即扣减为 0，防止超卖。
• 用户注册：新用户注册成功后，必须能立即登录系统。

共同特点：写入操作后，对数据的读取有强即时性要求，且数据之间存在复杂的关联和约束。

Milvus（写时分离）的适用场景

需要海量数据高吞吐写入和复杂相似性搜索的分析型场景：

• 推荐系统：批量导入用户前一天晚上的行为数据（点击、浏览），用于更新今天的推荐模型。允许几分钟的数据延迟，但需要处理数十亿的向量。
• 图片/视频检索：向系统里批量入库数百万张新图片的特征向量，后续支持"以图搜图"。
• AIGC 应用：用户输入一段文本，需要从海量的知识库向量中检索出最相关的片段。写入是批量的知识库更新，查询是并发的相似性搜索。

共同特点：

1. 写入批量大：通常是批量导入数据，而不是单条记录的事务。
2. 允许短暂延迟：数据写入后，不需要"立即可查"，允许秒级甚至分钟级的延迟。
3. 查询计算密集：查询本身是复杂的近似最近邻搜索，需要专用索引和大量计算。

1.3 总结

• 选择 MySQL（写时一体）：当你的业务核心是精确的、实时的、有关联的事务，比如"这个订单支付了吗？"，"这个用户的余额是多少？"。
• 选择 Milvus（写时分离）：当你的业务核心是从海量数据中"模糊地"找出最相似的项，比如"找出和这张图片最像的10张图"，"推荐和用户兴趣最匹配的商品"。

这两种架构没有绝对的优劣，它们是为完全不同的工作负载而生的专用工具。在现代复杂应用中，它们常常协同工作——例如，用 MySQL 存用户和订单的精确数据（写时一体），用 Milvus 存商品和内容的向量数据进行推荐（写时分离）。

2. 搜索引擎

Knowhere 是 Milvus 的核心向量执行引擎，它集成了多个向量相似性搜索库，包括Faiss、Hnswlib和Annoy。Knowhere 的设计还支持异构计算。它可以控制在哪个硬件（CPU 或 GPU）上执行索引构建和搜索请求。这就是 Knowhere 名字的由来--知道在哪里执行操作符。未来的版本将支持更多类型的硬件，包括 DPU 和 TPU。

https://milvus.io/docs/zh/knowhere.md

二、 细节架构

1. wal

WAL(Write Ahead Log)预写日志，是数据库系统中常见的一种手段，用于保证数据操作的原子性和持久性。
在计算机科学中，「预写式日志」（Write-ahead logging，缩写 WAL）是关系数据库系统中用于提供原子性和持久性（ACID 属性中的两个）的一系列技术。在使用 WAL 的系统中，所有的修改在提交之前都要先写入 log 文件中。
https://zhuanlan.zhihu.com/p/137512843

Woodpecker 遵循 “ZeroDisk” 架构，所有日志数据存储于云对象存储（如 Amazon S3、GCS、阿里 OSS），元数据则由 etcd 等分布式 KV 系统管理。这种设计彻底消除了本地磁盘依赖，降低了运维压力，并提升了数据持久性和扩展能力。
https://zhuanlan.zhihu.com/p/1897289691054703094

2.