NoSQL 数据库并不是“不要 SQL 的数据库”这么简单，而是针对缓存、文档、搜索与向量检索等不同场景，对数据模型和访问方式做出的不同取舍。

本文主要介绍 Redis、MongoDB 与 Milvus，并从 Linux 运维视角理解它们的部署、配置、数据安全、备份恢复与故障排查。

一、NoSQL 数据库概述#

传统关系型数据库以表、行、列和 SQL 为核心，适合结构化数据以及复杂事务处理。

NoSQL（Not Only SQL）则泛指一类非关系型或非纯关系模型数据库。它们通常针对某类数据模型或访问场景进行了专门优化。

常见类型包括：

类型	代表系统	核心模型	常见场景
Key-Value	Redis	Key → Value	缓存、Session、计数器、排行榜
Document	MongoDB	BSON/Document	JSON 类业务数据、内容系统
Wide Column	Cassandra、HBase	列族	海量分布式数据
Graph	Neo4j	Node + Edge	社交关系、知识图谱
Vector Database	Milvus	Vector + Scalar	向量检索、RAG、语义搜索

因此，NoSQL 不是某一种数据库，而是一类数据库系统的统称。

本文选择 Redis、MongoDB 和 Milvus，是因为三者分别代表了当前应用开发与基础设施场景中非常典型的三种数据存储需求：

1
                  NoSQL / 非关系型数据系统
2
                           │
3
          ┌────────────────┼────────────────┐
4
          │                │                │
5
        Redis           MongoDB          Milvus
6
          │                │                │
7
       Key-Value        Document        Vector
8
          │                │                │
9
      高速缓存         灵活业务数据      向量相似度检索

二、Redis 基础与 Linux 部署#

2.1 Redis 是什么#

Redis 是一种内存型数据存储系统，核心特点是将数据保存在内存中，并提供丰富的数据结构和高性能的数据访问能力。

它最常见的使用方式并不是替代 MySQL、PostgreSQL，而是作为应用系统旁边的一层高速数据存储。

例如：

1
用户请求
2
   │
3
   ▼
4
 Web / API 服务
5
   │
6
   ├──── Redis ────► 高速缓存
7
   │
8
   └──── MySQL ────► 持久业务数据

因此，一个典型 Web 系统可能同时使用：

1
MySQL / PostgreSQL
2
        │
3
        │ 主业务数据
4
        ▼
5
      应用服务
6
        │
7
        │ 高频访问数据
8
        ▼
9
       Redis

Redis 官方文档： Redis Documentation

2.2 Redis 常见数据类型#

Redis 最重要的特点之一，是它提供了多种内置数据结构。

String#

最基础的数据类型：

1
key → value

例如：

1
user:1001:name → "Alice"

可以保存字符串、数字甚至二进制数据。

常见操作：

1
SET user:1001:name Alice
2
GET user:1001:name

String 还非常适合计数器：

1
SET page:view 100
2
INCR page:view

执行后：

1
101

官方文档： Redis Data Types

Hash#

Hash 可以表示一个对象中的多个字段：

1
user:1001
2
 ├── name → Alice
3
 ├── age  → 20
4
 └── city → Guangzhou

例如：

1
HSET user:1001 name Alice age 20 city Guangzhou
2
HGET user:1001 name
3
HGETALL user:1001

它非常适合保存简单对象。

List#

List 是有序字符串集合：

1
LPUSH queue task1
2
LPUSH queue task2
3
RPOP queue

常用于：

简单任务队列
消息缓冲
最新数据列表

Set#

Set 中的元素具有唯一性：

1
SADD tags linux
2
SADD tags docker
3
SADD tags linux

第二次添加 linux 不会产生重复元素。

常用于：

标签集合
去重
集合运算

Sorted Set#

Sorted Set 在元素之外还具有一个 score：

1
user1 → 100
2
user2 → 80
3
user3 → 95

因此特别适合排行榜：

1
ZADD ranking 100 user1
2
ZADD ranking 80 user2
3
ZADD ranking 95 user3

然后按照分数排序获取结果。

Stream#

Redis Stream 用于保存一系列消息记录：

1
message1
2
message2
3
message3
4
...

更适合事件流、消息处理等场景。

因此 Redis 常见数据结构可以简单理解为：

类型	主要特征	常见用途
String	单值	缓存、计数器
Hash	字段集合	对象
List	有序序列	队列、列表
Set	唯一集合	去重、集合运算
Sorted Set	元素 + 分数	排行榜
Stream	消息流	事件、消息处理

2.3 Linux 安装 Redis#

Redis 官方提供了 Linux 安装方式。

Ubuntu / Debian 可以使用官方 APT 源：

1
sudo apt-get install lsb-release curl gpg
2

3
curl -fsSL https://packages.redis.io/gpg \
4
  | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
5

6
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
7

8
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] \
9
https://packages.redis.io/deb $(lsb_release -cs) main" \
10
| sudo tee /etc/apt/sources.list.d/redis.list
11

12
sudo apt-get update
13
sudo apt-get install redis

参考： Redis - Install on Linux

安装完成后，可以查看服务：

1
sudo systemctl status redis-server

启动：

1
sudo systemctl start redis-server

设置开机启动：

1
sudo systemctl enable redis-server

停止：

1
sudo systemctl stop redis-server

重启：

1
sudo systemctl restart redis-server

2.4 Redis 默认端口#

Redis 默认监听：

1
6379

可以使用：

1
ss -lntp | grep 6379

检查监听状态。

也可以直接使用客户端：

1
redis-cli

测试：

1
127.0.0.1:6379> PING
2
PONG

如果出现：

1
PONG

说明客户端已经成功连接 Redis。

2.5 Redis 配置文件#

Redis 的具体配置位置取决于安装方式和发行版。

常见配置项包括：

1
bind
2
port
3
protected-mode
4
requirepass / ACL
5
maxmemory
6
maxmemory-policy
7
appendonly
8
save
9
dir

查看当前实例配置可以使用：

1
redis-cli CONFIG GET port

或者：

1
redis-cli CONFIG GET maxmemory

运维过程中首先应该确认：

1
配置文件
2
   │
3
   ├── 监听地址
4
   ├── 监听端口
5
   ├── 内存限制
6
   ├── 持久化策略
7
   ├── 日志
8
   └── 认证与访问控制

三、Redis 缓存与常见应用场景#

3.1 Redis 为什么适合缓存#

缓存的核心思想是：

1
             Cache Hit
2
请求 ───► Redis ─────────► 返回结果
3
           │
4
           │ Cache Miss
5
           ▼
6
        MySQL / API

如果 Redis 中已经存在需要的数据，应用就不需要再次访问数据库。

例如：

1
GET user:1001

如果缓存存在：

1
Redis → 用户信息

否则：

1
Redis Miss
2
   │
3
   ▼
4
MySQL 查询
5
   │
6
   ▼
7
写入 Redis
8
   │
9
   ▼
10
返回客户端

这可以减少数据库压力，同时降低响应延迟。

3.2 Cache#

最典型的缓存形式：

1
key:
2
user:1001
3

4
value:
5
{
6
    "name": "Alice",
7
    "age": 20
8
}

并设置过期时间：

1
SET user:1001 Alice EX 300

表示 300 秒后自动过期。

常见缓存策略包括：

Cache Aside#

应用先查询缓存：

1
查询 Redis
2
   │
3
   ├── 命中 → 返回
4
   │
5
   └── 未命中
6
         │
7
         ▼
8
      查询数据库
9
         │
10
         ▼
11
      写入 Redis

这是业务系统中非常常见的模式。

3.3 Session#

Web 应用的 Session 也可以放入 Redis：

1
Browser
2
   │
3
   │ Cookie: SESSION_ID
4
   ▼
5
Application
6
   │
7
   ▼
8
Redis
9
   │
10
   └── Session Data

这样在多个应用实例之间就可以共享 Session：

1
             ┌── Web 1 ──┐
2
Client ──────┼── Web 2 ──┼──── Redis
3
             └── Web 3 ──┘

这对于负载均衡后的多实例部署非常有用。

3.4 计数器#

Redis 的原子递增操作适合实现：

1
访问量
2
点赞数
3
库存计数
4
API 调用次数
5
限流计数

例如：

1
INCR article:1001:view

原子操作#

Redis 提供很多原子操作，例如：

1
INCR counter
2
DECR counter

这比先读取再写回更加适合并发计数场景。

3.5 排行榜#

Sorted Set 天然适合排行榜：

1
100 userA
2
98  userC
3
85  userB

应用可以根据 score 获取排名。

例如：

1
ZREVRANGE ranking 0 9 WITHSCORES

获取前 10 名。

3.6 分布式锁#

Redis 也经常被用于实现分布式协调机制。

最基本的思想是利用带条件的写入：

1
SET lock_key unique_value NX EX 30

其中：

NX：仅当 key 不存在时设置
EX 30：30 秒后自动过期

实际生产环境中的分布式锁要考虑过期、续期、客户端异常和释放锁安全等问题，因此不能简单理解成“SET 一个 key 就完成了分布式锁”。

四、Redis 持久化与数据安全#

虽然 Redis 主要使用内存，但它并不是只能存在内存中。

Redis 提供多种持久化方式，其中最核心的是：

1
RDB
2
AOF

也可以组合使用。

官方文档： Redis Persistence

4.1 RDB#

RDB 是定期生成数据快照。

可以理解为：

1
Redis 内存数据
2
      │
3
      │ 某个时间点
4
      ▼
5
   RDB Snapshot
6
      │
7
      ▼
8
   磁盘文件

它保存的是某一时刻的数据状态。

优点：

文件紧凑
恢复速度通常较快
对长期归档和备份比较方便

缺点：

两次快照之间发生故障可能丢失部分数据
快照生成可能带来额外资源开销

4.2 AOF#

AOF（Append Only File）记录写操作。

例如：

1
SET user Alice
2
INCR counter
3
DEL session

这些写操作会被写入 AOF，Redis 重启后可以重新执行这些操作来恢复数据。

可以理解为：

1
客户端写入
2
    │
3
    ▼
4
 Redis
5
    │
6
    └──► AOF
7
            │
8
            ▼
9
        重放写操作
10
            │
11
            ▼
12
        恢复数据

AOF 一般比普通快照具有更细粒度的数据恢复能力，但也会带来额外的磁盘和恢复开销。

4.3 RDB + AOF#

Redis 可以同时使用 RDB 和 AOF。

典型思路是：

1
RDB → 快速恢复的基础快照
2
AOF → 更细粒度的写操作记录

应该根据业务的：

1
数据重要性
2
可接受数据丢失量
3
恢复时间要求
4
磁盘资源

选择持久化策略。

4.4 备份不能等于持久化#

这是运维中非常容易混淆的概念：

1
开启 AOF
2
≠
3
已经完成备份

因为 AOF/RDB 本身也是数据库运行时产生的数据文件。

真正的备份还需要考虑：

1
数据库文件
2
      │
3
      ▼
4
独立存储
5
      │
6
      ├── 本机其他磁盘
7
      ├── NAS
8
      ├── 对象存储
9
      └── 远程备份服务器

备份必须与原机器故障隔离。

4.5 Redis 数据安全#

生产环境不要直接把 Redis 暴露到公网。

应该至少考虑：

1
网络隔离
2
防火墙
3
访问控制
4
认证
5
最小权限
6
TLS
7
备份
8
监控

尤其不能简单认为：

1
Redis 默认端口 6379
2
→ 改掉端口
3
→ 就安全了

修改端口只能降低一部分自动化扫描风险，并不能替代认证和网络访问控制。

五、Redis 常见故障与性能排查#

Redis 的故障排查应该从：

1
服务
2
 │
3
 ├── 进程
4
 ├── 端口
5
 ├── 连接
6
 ├── 内存
7
 ├── 慢查询
8
 ├── 热点 Key
9
 └── 持久化

逐层分析。

5.1 服务无法启动#

首先：

1
systemctl status redis-server

查看日志：

1
journalctl -u redis-server

然后检查：

1
配置文件
2
端口占用
3
目录权限
4
磁盘空间
5
日志

检查端口：

1
ss -lntp | grep 6379

5.2 Redis 内存过高#

查看：

1
redis-cli INFO memory

重点关注：

1
used_memory
2
used_memory_peak
3
maxmemory
4
mem_fragmentation_ratio

如果 Redis 是缓存，通常应该设置合理的：

1
maxmemory
2
maxmemory-policy

例如缓存场景中可以使用淘汰策略：

1
allkeys-lru
2
allkeys-lfu
3
volatile-lru
4
volatile-lfu

具体选择需要结合业务访问模式。

5.3 连接过多#

可以查看：

1
redis-cli INFO clients

以及：

1
redis-cli CLIENT LIST

常见原因包括：

1
连接池配置不合理
2
客户端没有及时释放连接
3
大量短连接
4
应用实例数量过多
5
连接泄漏

因此 Redis 连接数异常时，不应该只看 Redis，还需要检查应用侧。

5.4 慢查询#

Redis 可以记录执行时间较长的命令。

查看慢查询：

1
redis-cli SLOWLOG GET

需要注意：

Redis 单线程执行模型意味着，一个运行时间过长的命令可能阻塞其他请求。

因此应避免对超大数据集合执行不合理操作，例如：

1
KEYS *

在生产环境中应谨慎使用。

可以优先考虑：

1
SCAN 0

进行渐进式遍历。

5.5 热点 Key#

所谓热点 Key，就是某些 Key 被大量请求访问：

1
大量请求
2
   │
3
   ├──► key:A
4
   ├──► key:A
5
   ├──► key:A
6
   └──► key:A

如果某个 Redis Key 的访问量远高于其他 Key，可能导致：

1
单节点压力过高
2
CPU 增加
3
网络集中
4
请求延迟增加

排查热点 Key 时需要结合业务访问模式、监控以及 Redis 统计信息综合判断。

六、MongoDB 基础与 Linux 部署#

6.1 MongoDB 是什么#

MongoDB 是一种文档型数据库。

它不是：

1
Table → Row → Column

而是更接近：

1
Database
2
   │
3
   └── Collection
4
          │
5
          ├── Document
6
          ├── Document
7
          └── Document

Document 通常使用 BSON 表示，形式上与 JSON 很接近：

1
{
2
  "_id": 1001,
3
  "name": "Alice",
4
  "age": 20,
5
  "tags": ["linux", "docker"]
6
}

MongoDB 官方文档： MongoDB Documentation

6.2 Database、Collection、Document#

MongoDB 的核心层级：

1
MongoDB
2
  │
3
  └── Database
4
        │
5
        └── Collection
6
              │
7
              └── Document

可以类比关系数据库：

MongoDB	关系数据库
Database	Database
Collection	Table
Document	Row
Field	Column

但这种对应关系只是帮助理解，两者的数据模型并不完全相同。

6.3 MongoDB 文档模型#

MongoDB 的一个优势是文档结构灵活。

例如：

1
{
2
  "name": "Alice",
3
  "address": {
4
    "city": "Guangzhou",
5
    "country": "China"
6
  }
7
}

也可以保存数组：

1
{
2
  "name": "Alice",
3
  "skills": [
4
    "Linux",
5
    "Docker",
6
    "Kubernetes"
7
  ]
8
}

这非常适合结构变化较快的业务数据。

6.4 MongoDB 安装#

MongoDB 官方建议在 Ubuntu 上使用官方软件源和 APT 安装。

例如 MongoDB 8.0 的 Ubuntu 安装流程：

1
sudo apt-get update
2
sudo apt-get install -y \
3
  ca-certificates \
4
  curl \
5
  gnupg

随后配置 MongoDB 官方仓库并安装：

1
sudo apt-get install -y mongodb-org

不同 Ubuntu 版本对应的软件源配置不同，因此实际安装时应以 MongoDB 官方对应版本文档为准：

Install MongoDB Community Edition on Ubuntu

6.5 systemd 服务管理#

安装后可以通过：

1
sudo systemctl start mongod

启动 MongoDB。

查看状态：

1
sudo systemctl status mongod

开机启动：

1
sudo systemctl enable mongod

停止：

1
sudo systemctl stop mongod

重启：

1
sudo systemctl restart mongod

日志通常可以从 MongoDB 日志文件或 systemd 日志中查看。

6.6 MongoDB 默认端口#

MongoDB 默认端口通常是：

1
27017

检查：

1
ss -lntp | grep 27017

然后可以使用：

1
mongosh

连接数据库。

七、MongoDB 配置、用户与权限#

7.1 MongoDB 配置#

MongoDB 常用配置内容包括：

1
bindIp
2
port
3
dbPath
4
systemLog
5
security

其中：

bindIp：控制监听哪些网络地址
port：控制监听端口
dbPath：数据库文件目录
systemLog：日志配置
security：安全配置

生产环境最重要的原则之一仍然是：

1
不要无防护暴露数据库到公网

7.2 用户与角色#

MongoDB 使用基于角色的访问控制。

可以创建用户：

1
use admin
2

3
db.createUser({
4
  user: "admin",
5
  pwd: "strong-password",
6
  roles: [
7
    { role: "userAdminAnyDatabase", db: "admin" }
8
  ]
9
})

之后应用应该使用业务专用账号，而不是管理员账号。

例如：

1
admin
2
 │
3
 ├── 管理员账号
4
 │
5
 └── application_user
6
       │
7
       └── 只访问 application 数据库

MongoDB 官方： Users and Roles

7.3 最小权限#

数据库用户应该遵循最小权限原则：

1
应用只需要读
2
→ 授予读权限
3

4
应用需要读写
5
→ 授予读写权限
6

7
运维账号
8
→ 根据管理职责授予管理权限

不要让普通应用直接使用超级管理员账号。

八、MongoDB 数据备份与恢复#

MongoDB 常见逻辑备份工具包括：

1
mongodump
2
mongorestore

8.1 mongodump#

备份数据库：

1
mongodump \
2
  --uri="mongodb://localhost:27017/mydb" \
3
  --out=/backup/mydb

结果可能类似：

1
/backup/mydb/
2
├── collection1.bson
3
├── collection1.metadata.json
4
├── collection2.bson
5
└── collection2.metadata.json

8.2 mongorestore#

恢复：

1
mongorestore \
2
  --uri="mongodb://localhost:27017/mydb" \
3
  /backup/mydb

备份和恢复首先解决的是：

1
数据误删
2
数据库损坏
3
机器故障后的数据恢复

但真正的生产备份还必须考虑：

1
备份频率
2
备份位置
3
备份保留时间
4
恢复测试
5
RPO
6
RTO

MongoDB 官方： Backup and Restore Methods

8.3 备份恢复测试#

“已经执行备份命令”不等于“已经具备恢复能力”。

完整流程应该是：

1
生产 MongoDB
2
      │
3
      ▼
4
    Backup
5
      │
6
      ▼
7
独立存储
8
      │
9
      ▼
10
   定期恢复测试
11
      │
12
      ▼
13
确认数据可以恢复

对于运维而言：

1
Backup
2
  +
3
Restore Test

才构成真正可验证的备份体系。

九、MongoDB 索引与性能基础#

9.1 为什么需要索引#

没有索引时，数据库可能需要扫描大量文档：

1
Collection
2
 ├── Document 1
3
 ├── Document 2
4
 ├── Document 3
5
 ├── ...
6
 └── Document N

如果查询：

1
db.users.find({ name: "Alice" })

没有适合的索引，就可能扫描大量数据。

建立索引：

1
db.users.createIndex({ name: 1 })

数据库可以利用索引快速定位数据。

MongoDB 官方： Indexes

9.2 单字段索引#

1
db.users.createIndex({ name: 1 })

表示按照 name 建立索引。

9.3 复合索引#

1
db.users.createIndex({
2
  city: 1,
3
  age: -1
4
})

字段顺序非常重要。

索引设计必须结合实际查询：

1
经常查询什么？
2
排序什么？
3
过滤什么？
4
查询字段组合是什么？

而不是“索引越多越好”。

9.4 索引的代价#

索引会提升部分查询性能，但也会带来：

1
额外磁盘空间
2
写入成本
3
内存占用
4
维护成本

因此需要在：

1
读性能
2
写性能
3
存储空间

之间进行权衡。

十、MongoDB 常见故障排查#

10.1 服务无法启动#

首先：

1
sudo systemctl status mongod

再查看日志。

重点检查：

1
配置文件
2
dbPath
3
目录权限
4
端口占用
5
磁盘空间
6
日志

10.2 磁盘空间不足#

MongoDB 数据库通常会随着数据量增长而扩大。

查看：

1
df -h

数据库目录：

1
du -sh /var/lib/mongodb

如果磁盘接近 100%，数据库可能出现写入失败等问题。

10.3 查询变慢#

重点检查：

1
索引
2
查询条件
3
返回数据量
4
排序
5
并发
6
磁盘 I/O

可以使用查询分析工具，例如：

1
db.users.find({ name: "Alice" }).explain("executionStats")

重点观察：

1
执行计划
2
扫描文档数量
3
返回文档数量
4
执行时间

10.4 连接问题#

从：

1
客户端
2
  │
3
  ▼
4
MongoDB 端口
5
  │
6
  ▼
7
认证
8
  │
9
  ▼
10
权限
11
  │
12
  ▼
13
数据库

逐层排查。

例如先确认：

1
ss -lntp | grep 27017

再确认网络和认证。

十一、Milvus 与向量数据库#

11.1 什么是向量数据库#

Redis 和 MongoDB 主要解决的是：

1
Key-Value
2
Document

而 Milvus 解决的是：

1
Vector Similarity Search

也就是向量相似度搜索。

例如一段文本经过 Embedding 模型后：

1
"Linux 网络故障排查"
2
       │
3
       ▼
4
Embedding Model
5
       │
6
       ▼
7
[0.13, 0.82, 0.21, ...]

得到一个高维向量。

另一段文本：

1
"Linux 网络连接异常怎么办"

也可以转换成向量。

虽然两段文本的字面内容不同，但它们的语义可能很接近，因此向量之间的距离也可能较小。

于是可以进行：

1
Query Vector
2
      │
3
      ▼
4
Vector Database
5
      │
6
      ▼
7
寻找最相似的 Top-K 向量

这就是向量相似度搜索。

Milvus 官方： Milvus Documentation

11.2 Milvus 的基本模型#

Milvus 的核心概念可以简单理解为：

1
Database
2
   │
3
   └── Collection
4
          │
5
          ├── Vector Field
6
          ├── Scalar Field
7
          └── Primary Key

例如：

1
documents
2
├── id
3
├── text
4
├── category
5
└── embedding

其中：

1
embedding
2
    │
3
    └── [0.12, 0.35, 0.92, ...]

就是向量字段。

而：

1
category
2
text
3
id

属于标量数据。

11.3 为什么普通数据库也能保存向量，却还需要 Milvus#

理论上，向量可以保存到普通数据库中。

但是随着数据量增加：

1
向量维度
2
      ×
3
向量数量
4
      ×
5
搜索请求数量

相似度检索的计算量会迅速增加。

因此，向量数据库通常会针对：

1
向量存储
2
向量索引
3
相似度搜索
4
Top-K 检索

进行专门优化。

Milvus 官方提供多种索引和相似度搜索能力，适合构建大规模向量检索系统。

十二、Milvus Linux / Docker 部署#

Milvus 的部署方式与 Redis、MongoDB 有明显不同。

Redis / MongoDB 可以直接作为系统服务运行，而 Milvus 很常见的部署方式是：

1
Docker
2
Docker Compose
3
Kubernetes

Milvus 官方当前提供 Docker 和 Docker Compose 部署文档。

参考： Run Milvus in Docker

12.1 Docker 部署#

准备 Docker 环境后，可以使用官方脚本：

1
curl -sfL \
2
  https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh \
3
  -o standalone_embed.sh

启动：

1
bash standalone_embed.sh start

查看容器：

1
docker ps

停止：

1
bash standalone_embed.sh stop

当前 Milvus 官方文档中的 Standalone Docker 部署默认使用：

1
Milvus
2
19530

同时会涉及元数据、存储等相关组件；实际部署结构会随 Milvus 版本演进，因此生产环境应以对应版本官方文档为准。

12.2 Docker Compose#

如果需要更明确地管理组件和数据卷，可以使用 Docker Compose。

典型结构：

1
Docker Compose
2
      │
3
      ├── Milvus
4
      ├── Metadata Store
5
      └── Object Storage

官方文档： Run Milvus with Docker Compose

12.3 Milvus 端口#

Standalone 部署常见服务端口：

1
19530 → Milvus 服务

某些部署中还会提供 Web UI，例如：

1
9091

可以检查：

1
ss -lntp

或者：

1
docker ps

确认端口映射。

十三、Milvus 数据组织与向量搜索#

13.1 Collection#

Collection 可以理解为 Milvus 中的一组数据集合。

例如：

1
documents

内部包含：

1
id
2
title
3
content
4
embedding
5
category

其中：

1
id          → 主键
2
title       → 标量字段
3
content     → 标量字段
4
embedding   → 向量字段
5
category    → 标量字段

13.2 Insert#

向量经过 Embedding 模型生成后写入 Milvus：

1
文本
2
 │
3
 ▼
4
Embedding Model
5
 │
6
 ▼
7
Vector
8
 │
9
 ▼
10
Milvus Collection

例如：

1
文档 A
2
→ [0.12, 0.34, 0.78, ...]
3

4
文档 B
5
→ [0.18, 0.31, 0.75, ...]
6

7
文档 C
8
→ [0.93, 0.12, 0.08, ...]

13.3 Similarity Search#

用户输入：

1
Linux 网络连接异常怎么办？

首先转换成查询向量：

1
Query
2
 │
3
 ▼
4
Embedding Model
5
 │
6
 ▼
7
Query Vector
8
 │
9
 ▼
10
Milvus
11
 │
12
 ├── Document A → 0.92
13
 ├── Document B → 0.88
14
 ├── Document C → 0.74
15
 └── ...

最后返回 Top-K 结果。

这也是 RAG（Retrieval-Augmented Generation）系统中非常常见的一种架构。

十四、Milvus 的索引与性能基础#

向量数据库的查询性能与索引方式高度相关。

基本思想是：

1
原始向量
2
   │
3
   ▼
4
建立向量索引
5
   │
6
   ▼
7
查询向量
8
   │
9
   ▼
10
快速寻找近似邻居

常见思想包括：

1
精确搜索
2
近似最近邻搜索（ANN）

实际系统会根据：

1
数据规模
2
向量维度
3
召回率要求
4
延迟要求
5
内存
6
磁盘

选择合适的索引和参数。

因此，向量数据库优化并不是简单地：

1
CPU 越高越好
2
内存越大越好

而需要结合：

1
索引
2
数据规模
3
查询模式
4
向量维度
5
Top-K
6
过滤条件

综合调整。

十五、Milvus 数据安全与运维#

虽然 Milvus 经常通过 Docker 部署，但它依然是数据库系统，而不是“启动一个容器就结束”。

运维时需要关注：

1
容器状态
2
数据卷
3
日志
4
端口
5
存储
6
元数据
7
对象存储
8
备份
9
版本升级

15.1 数据卷#

容器本身可以删除，但数据库数据不能依赖容器生命周期。

应该使用：

1
Docker Volume
2
或
3
宿主机持久化目录

例如：

1
Host
2
 │
3
 └── volumes/
4
       └── milvus/
5
             ├── data
6
             └── ...

否则执行：

1
docker rm

等操作时可能造成数据风险。

15.2 备份#

Milvus 的备份不能简单理解成：

1
docker commit

数据库备份需要考虑实际的数据存储、元数据和部署模式。

因此生产环境应该优先采用 Milvus 官方对应版本支持的备份方案，而不是只复制某一个容器目录。

十六、Redis、MongoDB、Milvus 对比#

维度	Redis	MongoDB	Milvus
核心模型	Key-Value / Data Structure	Document	Vector
主要数据	内存数据结构	BSON 文档	向量 + 标量
典型场景	缓存、Session、计数、排行榜	业务文档、内容数据	向量检索、RAG
查询特点	Key / Structure	文档查询	相似度搜索
常见部署	Linux / Docker	Linux / Docker	Docker / Compose / K8s
默认端口	6379	27017	19530
重点运维	内存、连接、慢查询	索引、磁盘、连接	容器、存储、索引
持久化	RDB / AOF	数据文件 / 日志机制	持久化存储体系
典型问题	内存过高、热点 Key	慢查询、磁盘不足	向量检索性能、存储与组件状态

可以用一句话区分：

1
Redis
2
→ 我要快速拿到数据。
3

4
MongoDB
5
→ 我要灵活地存储和查询文档。
6

7
Milvus
8
→ 我要快速找到“最相似”的向量。

十七、NoSQL 数据库故障排查方法#

虽然三种数据库的内部实现完全不同，但运维排障可以使用相似的思路。

1
                数据库故障
2
                    │
3
                    ▼
4
              1. 服务是否正常？
5
                    │
6
                    ▼
7
              2. 端口是否监听？
8
                    │
9
                    ▼
10
              3. 网络是否连通？
11
                    │
12
                    ▼
13
              4. 是否认证成功？
14
                    │
15
                    ▼
16
              5. 是否有权限？
17
                    │
18
                    ▼
19
              6. 数据是否正常？
20
                    │
21
                    ▼
22
              7. 性能是否正常？
23
                    │
24
          ┌─────────┼─────────┐
25
          ▼         ▼         ▼
26
        CPU        Memory      Disk
27
          │         │         │
28
          └─────────┼─────────┘
29
                    ▼
30
                  日志
31
                    │
32
                    ▼
33
                 恢复能力

17.1 服务层#

Linux 下首先看：

1
systemctl status xxx

或者 Docker：

1
docker ps
2
docker logs <container>

确认：

1
服务是否启动
2
容器是否退出
3
是否反复重启

17.2 网络层#

检查监听：

1
ss -lntp

从远程客户端测试：

1
nc -vz <host> <port>

例如：

1
nc -vz 192.168.1.10 6379

17.3 认证与权限#

如果：

1
端口能访问

但：

1
应用仍然无法使用数据库

就需要检查：

1
用户名
2
密码
3
认证机制
4
数据库
5
角色
6
权限

不要把所有连接问题都归结为“网络不通”。

17.4 性能层#

当数据库响应变慢时，应区分：

1
CPU
2
Memory
3
Disk I/O
4
Network
5
Database Query
6
Connection Pool

例如 Redis：

1
Memory
2
Hot Key
3
Slow Command
4
Connection

MongoDB：

1
Index
2
Query Plan
3
Disk
4
Lock / Concurrency
5
Connection

Milvus：

1
Vector Index
2
Query Load
3
Memory
4
Storage
5
Component Health

十八、NoSQL 数据库与 Web 应用#

实际项目通常不会只使用一种数据库。

例如一个 AI / Web 应用可能采用：

1
                   Client
2
                      │
3
                      ▼
4
                  API Server
5
                      │
6
        ┌─────────────┼─────────────┐
7
        │             │             │
8
        ▼             ▼             ▼
9
      MySQL         Redis        MongoDB
10
        │             │             │
11
   业务数据        缓存/Session     文档数据
12
                      │
13
                      │
14
                      ▼
15
                   Milvus
16
                      │
17
                      ▼
18
                 Vector Search

进一步结合 RAG：

1
                  用户问题
2
                     │
3
                     ▼
4
               Embedding Model
5
                     │
6
                     ▼
7
                  Milvus
8
                     │
9
                  Top-K
10
                     │
11
                     ▼
12
               相关文档内容
13
                     │
14
                     ▼
15
                LLM / Agent
16
                     │
17
                     ▼
18
                  最终回答

这说明不同数据库并不是简单的竞争关系。

它们解决的是不同问题：

1
关系数据库
2
→ 事务与结构化业务数据
3

4
Redis
5
→ 高速缓存与内存数据结构
6

7
MongoDB
8
→ 灵活文档数据
9

10
Milvus
11
→ 向量检索

十九、从运维视角理解 NoSQL#

学习这些数据库时，不应该只记：

真正重要的是理解数据库运行在整个系统中的位置。

例如 Redis 内存满了：

1
Redis
2
 │
3
 └── maxmemory / eviction
4
       │
5
       ▼
6
应用缓存命中率下降
7
       │
8
       ▼
9
MySQL 查询压力增加
10
       │
11
       ▼
12
整体响应变慢

MongoDB 磁盘满了：

1
MongoDB
2
   │
3
   ▼
4
磁盘空间不足
5
   │
6
   ▼
7
写入失败
8
   │
9
   ▼
10
应用报错

Milvus 存储异常：

1
Milvus
2
   │
3
   ▼
4
数据 / 元数据 / 对象存储异常
5
   │
6
   ▼
7
Collection 或搜索异常
8
   │
9
   ▼
10
RAG 检索失败

因此数据库运维真正关注的是：

1
数据库
2
   │
3
   ├── 进程
4
   ├── 网络
5
   ├── 磁盘
6
   ├── 内存
7
   ├── 配置
8
   ├── 权限
9
   ├── 数据
10
   ├── 性能
11
   ├── 日志
12
   └── 备份恢复

二十、总结#

Redis、MongoDB、Milvus 虽然都可以归入广义的 NoSQL / 非关系型数据系统，但它们的设计目标明显不同：

1
Redis
2
→ 高性能 Key-Value / 内存数据结构
3

4
MongoDB
5
→ 灵活的文档数据模型
6

7
Milvus
8
→ 大规模向量数据与相似度搜索

从 Linux 运维角度，三者可以进一步归纳为：

1
安装
2
 ↓
3
服务管理
4
 ↓
5
配置
6
 ↓
7
网络与端口
8
 ↓
9
认证与权限
10
 ↓
11
数据存储
12
 ↓
13
备份恢复
14
 ↓
15
性能监控
16
 ↓
17
日志排查
18
 ↓
19
故障恢复

而真正进入生产环境之后，数据库运维的目标并不是单纯让数据库“运行起来”，而是保证：

1
可用
2
可靠
3
安全
4
可恢复
5
可观测
6
可扩展

这也是从“会使用数据库”走向“具备数据库运维能力”的关键一步。