1. 使用内存作为存储介质 如上图是存储金字塔，展示了存储介质价格与速度的关系。 目前，企业之所以广泛采用磁带和磁盘作为存储介质，主要是因为它们的价格优势。市场价格受市场供需影响，即便是价格较高的存储介质，如果生产成本低廉，具有足够大的市场，生产过

1. Jindo 直接加速 OSS 配置环境变量 1 2 3 4 export ENDPOINT=oss-cn-beijing-internal.aliyuncs.com export BUCKET= export AK= export SK= 创建凭证 1 2 3 4 5 6 7 8 9 10 kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: myosssecret type: Opaque stringData: fs.oss.accessKeyId: ${AK} fs.oss.accessKeySecret: ${SK} EOF 创建 Dataset 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 kubectl apply -f - <<EOF apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: myoss-jindo spec: mounts: - mountPoint: oss://${BUCKET}/test2/ options: fs.oss.endpoint: ${ENDPOINT} encryptOptions: - name: fs.oss.accessKeyId valueFrom: secretKeyRef: name: myosssecret key: fs.oss.accessKeyId - name: fs.oss.accessKeySecret valueFrom:

1. 关于 JuiceFS 的缓存 在主机上，预热的缓存是直接放在主机上的。 在集群中，分为两级缓存: Worker，提供集群级别共享的缓存 Fuse，提供仅当前节点级别的缓存 2. 使用 JuiceFS 客户端预热数据 需要注意的是在 Fuse 层预热，仅对当前节点有效，如果需要预热整个集群，需要在

1. 现象 基于 Kubernetes 的 Elasticsearch 频繁重启，导致服务几乎不可用。 在导入数据过程中，Pod 的内存使用持续增长 Pod 内存使用接近 Limit 之后，继续导入就会触发 Pod 异常退出，错误日志 ERROR: Elasticsearch exited unexpectedly Pod 内存使用率并不会下降，而是维持在 Limit 附近，不久又异常退出 Elasticsearch Pod 内存限制在 64GB，而 JVM 内

1. 在主机上挂载内存存储目录 创建目录用于挂载 1 mkdir /mnt/memory_storage 挂载 tmpfs 文件系统 1 mount -t tmpfs -o size=800G tmpfs /mnt/memory_storage 存储空间会按需使用，也就是使用 100G 存储时才会占用 100G 内存。主机节点上有 2T 内存，这里分配 800G 内存用于存储 Elasticsearch 数据。 提前创建好目录 1 2 3 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-0 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-1 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-2 如果没有提前创建好目录，并