Minio 实验

[bingoohuang]

Minio 实验

据说：在对象存储领域，minio大有kafka(java技术栈)在消息队列领域舍我其谁的气概:)。

实验目标：

1. 初识一下minio
2. 了解底层存储实现

步骤：

下载

https://min.io/download

curl -LO https://dl.min.io/server/minio/release/darwin-amd64/minio
chmod +x minio

单节点启动

MINIO_ROOT_USER=admin MINIO_ROOT_PASSWORD=password ./minio server ./data

访问: http://127.0.0.1:9000

$ ls -lh
-rw-rw-r-- 1 d5k d5k  38K Apr 26 12:54 stock-photo-1028690444.jpg
-rw-rw-r-- 1 d5k d5k  80K Apr 26 12:54 stock-photo-1028691321.jpg
-rw-rw-r-- 1 d5k d5k  54K Apr 26 12:54 stock-photo-1028691977.jpg
-rw-rw-r-- 1 d5k d5k  63K Apr 26 11:00 stock-photo-1028696105.jpg
-rw-rw-r-- 1 d5k d5k  29K Apr 26 12:54 stock-photo-1028700540.jpg

结论：

1. 上传多少个文件，磁盘上就有多少个文件存在
2. 从界面上删除某个文件，磁盘上这个文件也就被删除了，反之亦然

单机集群部署

$ more start.sh
#!/bin/bash

export MINIO_ACCESS_KEY="minio"
export MINIO_SECRET_KEY="minio123"

dir="/home/minio_data"
addr=""

for i in {01..04}; do
    addr+=" http://127.0.0.1:22${i}${dir}/data${i}"
done

mkdir -p ${dir}/log

for i in {01..04}; do
    nohup ./minio server --address ":22${i}" ${addr} > ${dir}/log/22${i}.log& 2>&1
done

访问: http://127.0.0.1:2201

$ ps aux|awk 'NR==1 || /minio server/'
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
license   5982  0.0  0.0 113556   960 pts/2    S+   11:25   0:00 awk NR==1 || /minio server/
license  28438  0.9  2.8 6929432 1876660 ?     Sl   4月26  11:00 ./minio server --address :2201 http://127.0.0.1:2201/home/minio_data/data01 http://127.0.0.1:2202/home/minio_data/data02 http://127.0.0.1:2203/home/minio_data/data03 http://127.0.0.1:2204/home/minio_data/data04
license  28439  0.8  0.7 1437836 461700 ?      Sl   4月26  10:55 ./minio server --address :2202 http://127.0.0.1:2201/home/minio_data/data01 http://127.0.0.1:2202/home/minio_data/data02 http://127.0.0.1:2203/home/minio_data/data03 http://127.0.0.1:2204/home/minio_data/data04
license  28440  0.8  0.6 1438284 416976 ?      Sl   4月26  10:42 ./minio server --address :2203 http://127.0.0.1:2201/home/minio_data/data01 http://127.0.0.1:2202/home/minio_data/data02 http://127.0.0.1:2203/home/minio_data/data03 http://127.0.0.1:2204/home/minio_data/data04
license  28441  0.8  0.6 1505856 456472 ?      Sl   4月26  10:46 ./minio server --address :2204 http://127.0.0.1:2201/home/minio_data/data01 http://127.0.0.1:2202/home/minio_data/data02 http://127.0.0.1:2203/home/minio_data/data03 http://127.0.0.1:2204/home/minio_data/data04

找一个63K的文件，看看磁盘情况，看来是分片和副本了：

$ find . -name stock-photo-1028696105.jpg -exec ls -lhR {} \;
./data02/bingoo/500px/stock-photo-1028696105.jpg:
总用量 32K
-rw-rw-r-- 1 license license 32K 4月  26 15:09 xl.meta
./data01/bingoo/500px/stock-photo-1028696105.jpg:
总用量 32K
-rw-rw-r-- 1 license license 32K 4月  26 15:09 xl.meta
./data03/bingoo/500px/stock-photo-1028696105.jpg:
总用量 32K
-rw-rw-r-- 1 license license 32K 4月  26 15:09 xl.meta
./data04/bingoo/500px/stock-photo-1028696105.jpg:
总用量 32K
-rw-rw-r-- 1 license license 32K 4月  26 15:09 xl.meta

也就是，只在单节点/单驱动器上运行时，会看到 MinIO 将文件作为文件在您的文件系统上处理，在分布式模式下，我们将文件分块并在多个节点之间进行弹性分割。

seaweedfs Compared to MinIO

source

MinIO follows AWS S3 closely and is ideal for testing for S3 API. It has good UI, policies, versionings, etc. SeaweedFS is trying to catch up here. It is also possible to put MinIO as a gateway in front of SeaweedFS later.

MinIO metadata are in simple files. Each file write will incur extra writes to corresponding meta file.

MinIO does not have optimization for lots of small files. The files are simply stored as is to local disks. Plus the extra meta file and shards for erasure coding, it only amplifies the LOSF problem.

MinIO has multiple disk IO to read one file. SeaweedFS has O(1) disk reads, even for erasure coded files.

MinIO has full-time erasure coding. SeaweedFS uses replication on hot data for faster speed and optionally applies erasure coding on warm data.

MinIO does not have POSIX-like API support.

MinIO has specific requirements on storage layout. It is not flexible to adjust capacity. In SeaweedFS, just start one volume server pointing to the master. That's all.

resources

1. 使用minio搭建高性能对象存储

[bingoohuang]

Facebook图片存储系统Haystack

1. Facebook图片存储系统Haystack
2. Haystack：Facebook 的照片存储系统

一篇14页的论文Facebook-Haystack， 看完之后我的印象里就四句话：

1. 因为【传统文件系统的弊端】
2. 因为【缓存无法解决长尾问题】
3. 所以【多个图片信息(Needle)存在同一个文件(SuperBlock)中】
4. 所以【显著提高性能】

传统文件系统的弊端

传统的 POSIX 文件系统不适合高性能的图片存储， 主要原因是基于该文件系统来存储的话，是讲每个图片存储成某目录下的一个文件， 每次读取文件的时候需要有N次磁盘IO，当目录下文件数是K级别是， 读取一次文件需要超过10次的文件IO，即使目录下的文件数是0.1K级别时， 也需要3次的文件IO（1:读取目录元数据,2:读取inode,3:读取文件内容）。

缓存无法解决长尾问题

图片存储的应用场景如图：

在 PhotoStorage 之前还有一些 CDN 保驾护航， CDN 就是靠缓存吃饭的，对于那些热门的图片都能被 CDN 很好的缓存下来， 所以需要访问的 PhotoStorage 一般都是非热门图片， 所以在这样的场景之下， 在 PhotoStorage 改进缓存显然是无法解决问题的。 你懂的，缓存对于长尾问题基本上都是束手无策的。 因为如果缓存能解决的问题，就不叫长尾问题了。

多个图片信息存在同一个文件中

每次读取一个图片需要多次磁盘IO的原因是因为一个图片存成一个文件， 文件系统里面每次读取文件需要先读取文件的元信息等，导致多次磁盘IO， 而当我们将多个图片信息存在同一个文件中， 当然这个文件会很大， 然后在内存中存储该图片存储在文件中的偏移地址和图片大小， 所以每次读取图片的时候， 根据偏移地址直接读取读取， 大部分情况下能做到只需要一次磁盘IO即可。 从而显著提高性能。