【linux】海量小文件的存储方案
在介绍海量文件存储之前，需要先介绍一下常见的系统里面文件是如何存储的
文件inode
在linux下，每个文件或者目录，都会分配一个inode(index node)，它不存储具体的文件内容，而是记录该文件的基础信息。每个inode大小一半是100-200kb(画重点，下面会用)。inode下会记录：
- 文件大小、类型；
- 权限信息，比如所属组，用户，访问控制；
- 文件的操作时间；
- 具体数据在磁盘的位置；
文件系统初始化的时候，磁盘空间一般都会分俩部分。一部分就是存储inode，一部分是真正的存储文件内容。需要注意的系统的inode数量是有上限的，即系统最多可以存储多少个文件。有可能磁盘空间还有很多，但inode已经被用完；那此时系统无法再分配新的inode，你也依旧无法再存储新的文件。查看文件占用多少inode，和系统还有多少inode可以用如下俩个命令：
#某一文件inode占用
[root@why /]# stat my_file
File: my_file
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: xx Inode: 17 Links: 1Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-03-26 11:30:27
Modify: 2024-03-26 11:30:27
Change: 2024-03-26 11:30:27#系统inode使用个数情况，注意是个数。
[root@why /]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
tmpfs 203330 100 203230 1% /dev/shm
tmpfs 203330 100 203230 1% /run
tmpfs 203330 200 203130 1% /sys/fs/cgroup#当使用率100%，那系统则无法再新曾文件。
#
海量文件存储
海量文件的元数据管理
海量文件存储就是数亿数十亿上百亿的文件存储，在如今互联网上，海量文件基本是个常态。图片、视频、商品等，很容易达到这个量级。在这个量级下，当前单机系统存储，是肯定存不下的。比如一个100亿的文件，先不考虑inode数量，光inode的存储大概就得1个TB，再加上具体的文件内容，很容易就超出单机系统了。这是海量文件要解的第一个问题，就是海量文件的元数据管理。
海量文件下如何高速支撑文件读取
假如存储支撑了这么多的元数据，比如单独搞到机器存储元数据，1TB其实压力还是可以的；或者多找几台机器分布式存储机器。此时会引入第二个问题，海量的文件下如何快速访问文件。对于一次文件读取是要先加载inode，找到真实文件存储位置再去读具体文件。一般系统为了加速文件访问，会把inode缓存在系统里(vfscache：https://www.science.unitn.it/~fiorella/guidelinux/tlk/node110.html)。如果这么大量的inode，很难缓存住的，海量文件下如何高速支撑文件读取。
ceph存储系统
对于海量文件业务场景，当前行业一般都会采用对象存储组件。比如腾讯云的cos，其他云厂商的对象存储，还有开源的ceph。
对于ceph来说，常见的块存储，文件存储和对象存储三种业务场景，都可以很好的支持。
整体架构
直接搬运自官方
- 客户端：ceph自己的客户端。
- 监视器：Ceph监视器（Ceph-mon）维护集群状态的映射，包括监视器自身，下边提到的管理器、OSD、MDS和CRUSH。为了容灾设计，通常至少需要三个监视器。
- 管理器：Ceph Manager守护进程（Ceph-mgr）负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率、当前性能指标和系统负载。
- Ceph OSD:对象存储守护程序（Ceph OSD，cosd）存储数据，处理数据复制、恢复、再平衡，并通过检查其他Ceph OSD守护程序的心跳来向Ceph监视器和管理器提供一些监控信息。通常至少需要三个Ceph OSD来实现高可用。
- MDSs:Ceph元数据服务器（MDS，Ceph-MDS）存储Ceph文件系统的元数据。Ceph元数据服务器允许CephFS用户运行基本命令（如ls、find等），而不会给Ceph存储集群带来负担。
继续补充中…