首先看性能用途对比

LocalPV LVM 与 LocalPV ZFS 对比表

项目LocalPV LVMLocalPV ZFS对比结果
性能（尤其是写）更好（接近裸盘，overhead 极低）；写性能通常比 ZFS 高 30%~5x（取决于 workload）较好，但有明显 overhead（CoW、checksum、ARC 等）；写性能一般比 LVM 慢LVM 胜
读性能优秀优秀（有 ARC 缓存加持时经常很强）差不多，ZFS 有时更好
CPU / 内存占用很低（轻量）较高（ZFS 需要较多 RAM 做 ARC 缓存，推荐每节点至少 8-16GB 空闲 RAM）LVM 胜
功能丰富度基础（Thin Provisioning、Snapshot、Resize）远强（快照几乎零成本、Compression、Deduplication、Checksumming 自愈、Encryption、zfs send/recv、RAIDZ 等）ZFS 大胜
数据完整性一般（需额外配 dm-integrity）极强（内置 checksum + 自愈）ZFS 大胜
快照（Snapshot）支持，但有性能损耗极佳（Copy-on-Write，几乎零成本）ZFS 大胜
Thin Provisioning + 扩容支持支持平手
运维复杂度较低稍高（ZFS pool 管理、tuning）LVM 胜
Near bare-metal 性能是（OpenEBS 官方表格明确标 Yes）否（有 ZFS 层 overhead）LVM 胜

LocalPV LVM、LocalPV ZFS、Mayastor 三种存储方案对比表

对比项目LocalPV LVM（LocalPV）LocalPV ZFS（ZFS）Mayastor（Replicated）
数据位置单个节点本地单个节点本地跨节点分布（多节点同步）
节点故障影响数据不可访问（单节点依赖）数据不可访问（单节点依赖）无影响（多节点副本备份）
写性能极高（无额外开销，接近裸盘）中等（有 CoW 及校验 overhead）较高（低开销，同步复制）
CPU 占用极低（仅内核层处理）中等（需维护 ARC 缓存）中等（需同步节点数据）
功能丰富度基础（快照、扩容、薄置）极高（压缩、加密、自愈等）较高（副本同步、故障转移）
数据完整性一般（需额外配置完整性校验）极强（内置校验、自愈）极强（多副本校验同步）
运维复杂度低（仅管理 LVM 卷组）中等（需维护 ZFS 池）中等（需管理节点同步）
资源占用低（无额外内存消耗）较高（需预留 ARC 缓存内存）中等（需维护节点同步）
适用场景追求极致性能、简单运维场景需数据高可靠性、功能丰富场景需高可用、跨节点备份场景

存储方案性能对比表

存储方案随机读 IOPS（4K）随机写 IOPS（4K）读延迟写延迟顺序吞吐（MB/s）CPU 开销备注
裸 NVMe / LocalPV LVM500K–1M+300K–800K+~0.05–0.2 ms~0.1–0.3 ms3000–7000+最低最高性能基准
Mayastor (Replicated)45K–500K+35K–400K+0.1–1.5 ms1–2.5 ms2000–3500+高（polling）接近本地，replicas=2–3
LocalPV ZFS50K–200K20K–100K0.2–0.8 ms0.3–1.5 ms1000–3000中等（ARC 缓存）快照强
Longhorn (v1/v2)15K–60K12K–50K2–6 ms3–10 ms600–1200中低简单易用
Rook/Ceph RBD25K–150K20K–100K0.5–2 ms1–3 ms1000–2800中高规模大但开销高
cStor (旧引擎)~7K–20K低高高低-已不推荐

总结 最好的就是lvm够了性能好，开销

快速部署Local PV LVM

部署前提

apt install lvm2

在所有节点上创建卷组，LVM驱动将用于部署卷
pvcreate /dev/sdb
vgcreate lvmvg /dev/sdb

在上述命令中，是要创建的卷组名称。lvmvg
只安装lvm
helm install openebs openebs/openebs \
  --namespace openebs \
  --set engines.replicated.mayastor.enabled=false \
  --set engines.local.zfs.enabled=false \
  --set engines.local.hostpath.enabled=false \
  --set loki.enabled=false \
  --set alloy.enabled=false
如下：
# kubectl get pods
NAME                                             READY   STATUS    RESTARTS        AGE
openebs-localpv-provisioner-89447ff8-jt45m       1/1     Running   2 (5h41m ago)   24h
openebs-lvm-localpv-controller-95d4c9856-ldjkn   5/5     Running   0               24h
openebs-lvm-localpv-node-9wlll                   2/2     Running   0               24h
openebs-lvm-localpv-node-bn5rt                   2/2     Running   0               24h
openebs-lvm-localpv-node-w5ks9                   2/2     Running   0               24h
创建sc
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-lvm
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"   # 如果你不想让它成为默认，可以不加这行
provisioner: local.csi.openebs.io
parameters:
  storage: "lvm"
  volgroup: "lvmvg"  # ← 必须和你之前用 vgcreate 创建的卷组名称一致
  fsType: xfs
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true

测试

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: openebs-lvm
  resources:
    requests:
      storage: 20Gi
---

apiVersion: v1
kind: Pod
metadata:
 name: fio
spec:
 restartPolicy: Never
 containers:
 - name: perfrunner
   image: openebs/tests-fio
   command: ["/bin/bash"]
   args: ["-c", "while true ;do sleep 50; done"]
   volumeMounts:
      - mountPath: /datadir
        name: fio-vol
   tty: true
 volumes:
 - name: fio-vol
   persistentVolumeClaim:
     claimName: my-pvc
插件命令
root@sr-demon1:/usr/local/src# openebs -n openebs localpv-lvm get volumes
 NAME                                      NODE        STATUS  CAPACITY   VOLGROUP  PVC-NAME  SC-NAME
 pvc-094022d1-836c-4c59-8504-5da2486a6e17  sr-demon-3  Ready   20.00 GiB  lvmvg     my-pvc    openebs-lvm
 pvc-bb516bcf-2d06-43e2-9166-ba9b54e3f2e8  sr-demon-3  Ready   20.00 GiB  lvmvg     my-pvc    openebs-lvm
root@sr-demon1:/usr/local/src# openebs localpv-lvm get volume-groups  -n openebs
 NAME   NODE        UUID                                    TOTAL-SIZE  FREE-SIZE  LV-COUNT  PV-COUNT  SNAP-COUNT
 lvmvg  sr-demon-2  doENw0-nkym-L8oT-rtO8-bJ8g-kDTR-9wIhLn  204796Mi    204796Mi   0         1         0
 lvmvg  sr-demon-3  Dbr6Ij-pwLf-OIIJ-domO-zu5E-3b40-hObUg7  204796Mi    163836Mi   2         1         0
 lvmvg  sr-demon-4  7p2svV-u0mq-0xUi-3wj8-biFI-SNws-YvESbB  204796Mi    204796Mi   0         1         0

机械盘跑starrocks 集群性能还是不错的

在这里插入图片描述
在这里插入图片描述

# kubernetes
Logo
腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

Elasticsearch复杂数据类型终极指南：从入门到精通

Elasticsearch作为功能强大的搜索引擎，支持多种复杂数据类型，让开发者能够灵活处理各种结构化和非结构化数据。本文将带你全面了解Elasticsearch中的复杂数据类型，从基础概念到实际应用，助你轻松掌握数据建模的核心技巧。## 内部对象：构建层级化数据结构在Elasticsearch中，对象类型（Object）是最基础的复杂数据类型之一，用于表示具有嵌套关系的数据。例如，我们可

avatar 腾讯云开发者社区

终极指南：Flink SQL连接器版本管理从混乱到有序的升级之路

Apache Flink作为流处理领域的佼佼者，其SQL连接器的版本管理一直是开发者面临的核心挑战。本文将系统讲解Flink SQL连接器版本管理的最佳实践，帮助你轻松应对版本兼容性问题，实现从混乱到有序的升级之旅。## 连接器版本管理的常见痛点 😫在Flink应用开发中，连接器版本管理常常让开发者头疼不已。不同版本的连接器可能导致各种兼容性问题，例如API变更、功能差异甚至运行时错误。

avatar 腾讯云开发者社区

如何快速搭建Neon无服务器PostgreSQL：面向初学者的完整指南

Neon是一款革命性的无服务器PostgreSQL解决方案，它通过分离存储和计算层，实现了自动扩缩容、类代码式数据库分支以及零级扩展能力。本指南将帮助你从零开始搭建Neon开发环境，体验这款创新数据库的强大功能。## 准备工作：环境要求与依赖项在开始搭建Neon环境前，请确保你的系统满足以下要求：- Linux操作系统（推荐Ubuntu 20.04+或Debian 11+）- Git

avatar 腾讯云开发者社区