云原生存储与数据库选型实战：从传统数据库到云原生数据库的演进
大家好，我是迪哥。随着业务从传统架构向云原生架构演进，存储和数据库的选型变得越来越重要。从 MySQL 到 TiDB，从 Redis 到 Dragonfly，从本地存储到分布式存储，我们经历了多次技术选型的纠结。今天就和大家聊聊云原生时代的存储和数据库选型策略。
存储架构演进
传统存储 → 分布式存储 → 云原生存储 SAN/NAS Ceph/Gluster CSI/Cloud Storage
云原生存储方案对比
| 方案 | 适用场景 | 特点 |
|---|
| Local PV | 单节点状态应用 | 高性能，低延迟 |
| HostPath | 开发测试环境 | 简单，不推荐生产 |
| NFS | 多节点共享 | 兼容性好，性能一般 |
| Ceph | 大规模分布式存储 | 高可用，弹性伸缩 |
| CSI Volume | 云厂商存储 | 托管服务，省心 |
CSI 配置示例
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: csi-disk
数据库选型策略
关系型数据库
| 数据库 | 适用场景 | 特点 |
|---|
| MySQL | 通用场景 | 成熟稳定，生态完善 |
| PostgreSQL | 复杂查询 | 功能强大，支持JSON |
| TiDB | 分布式事务 | 水平扩展，强一致 |
| CockroachDB | 全球分布式 | 多活，强一致 |
NoSQL 数据库
| 数据库 | 适用场景 | 特点 |
|---|
| Redis | 缓存/会话 | 高性能，支持多种数据结构 |
| Dragonfly | 替代Redis | 更高性能，兼容Redis协议 |
| MongoDB | 文档存储 | 灵活schema，水平扩展 |
| Cassandra | 时序/日志 | 高写入，分布式 |
选型决策树
┌─────────────────┐ │ 需要事务吗？ │ └────────┬────────┘ │ ┌─────────────┴─────────────┐ │ │ Yes │ │ No ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ 需要水平扩展？ │ │ 数据结构？ │ └────────┬────────┘ └────────┬────────┘ │ │ ┌──────┴──────┐ ┌─────────┴─────────┐ │ │ │ │ Yes │ │ No Key-Value Document ▼ ▼ ▼ ▼ TiDB/CRDB MySQL Redis/Dragonfly MongoDB
TiDB 实战配置
apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: basic spec: version: v6.5.0 timezone: UTC pvReclaimPolicy: Retain discovery: {} tikv: baseImage: pingcap/tikv replicas: 3 storageClaims: - resources: requests: storage: 100Gi tidb: baseImage: pingcap/tidb replicas: 2 service: type: NodePort
Dragonfly 替代 Redis
# Dragonfly 配置 apiVersion: v1 kind: Deployment metadata: name: dragonfly spec: replicas: 3 selector: matchLabels: app: dragonfly template: spec: containers: - name: dragonfly image: docker.dragonflydb.io/dragonflydb/dragonfly args: - --dbfilename=dragonfly - --dir=/data - --bind=0.0.0.0 - --port=6379 ports: - containerPort: 6379 volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: dragonfly-pvc
数据库高可用配置
MySQL 主从复制
apiVersion: v1 kind: Service metadata: name: mysql spec: selector: app: mysql ports: - name: mysql port: 3306 --- apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: replicas: 3 selector: matchLabels: app: mysql serviceName: mysql template: spec: containers: - name: mysql image: mysql:8.0 env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: password ports: - containerPort: 3306 volumeMounts: - name: data mountPath: /var/lib/mysql volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 50Gi
备份与恢复
Velero 备份配置
apiVersion: velero.io/v1 kind: Schedule metadata: name: daily-backup spec: schedule: "0 0 * * *" template: includedNamespaces: - default - prod snapshotVolumes: true ttl: 720h
最佳实践清单
| 维度 | 最佳实践 |
|---|
| 存储 | 使用 CSI Volume，避免 HostPath |
| 数据库 | 关键业务用 TiDB，缓存用 Dragonfly |
| 高可用 | 至少 3 副本，跨 AZ 部署 |
| 备份 | 定期备份，测试恢复流程 |
| 监控 | 监控存储使用率、IOPS、延迟 |
说到存储，我家那只叫 Docker 的哈士奇最近学会了"分布式存储"——把玩具藏到家里各个角落，美其名曰"数据备份"，这备份策略比我们的 Velero 还强 😂
我是迪哥，我们下期再见！
