我阅读了一些类似的问题，但对我的情况仍然有些困惑。
我的网站允许用户上传大量大图像（书的扫描页）。我的服务器会自动平铺并保存这些图像。因此，每页将变成 10,000 个小平铺（每幅图像为 128px*128px，占用 2k 空间）。我有大约 100GB 的图像，现在它们已经填满了所有的 inode 表。
这是我的一些想法和理解，如果有错，请纠正我。
mysql blob
优点：不再需要担心 inode / 目录结构。
缺点：图像服务速度慢，甚至可能减慢整个数据库的速度。
文件系统
优点：图像服务速度更快
缺点：备份速度慢，额外的目录设计，需要较大的 inode 大小（这也意味着我必须重新格式化服务器磁盘）
mongoDB BinData 与 base64（我不熟悉这个，但它似乎是一个不错的选择）
亚马逊 S3
优点：他们会照顾好一切
缺点：需要钱，并且失去对这些图像的完全控制。
（更新：我可能不允许使用第三方提供商，但我仍然会在这里讨论这个问题，因为根据@Niels 的建议，这对其他人来说可能是一个很好的解决方案。）
其他魔法 绝佳的解决方案。
所以我想知道哪种方法最适合我的情况以及原因。谢谢帮助
答案1
我肯定会选择 S3，除非你有成千上万的活跃用户……即使你做了一些捐赠或广告也应该能覆盖成本。与你自己的服务器相比，S3 存储真的非常便宜。在高冗余级别下，存储 100GB 数据每月将花费你大约 9 美元。这意味着镜像到至少 4 个存储位置，事务保证持久性为 99.9999%，而这笔成本实际上在 3 年内买不到一台服务器。流量可能很昂贵，但你向每个主机托管提供商支付的费用都是这样的，所以除非你得到很大的数字，否则没有真正的区别。
S3 内部是一个高度优化的字符串字典，因此能够存储数百万甚至数十亿个相关文件。
说实话，花点小钱就能省去很多麻烦，摆脱所有备份、冗余和服务器管理的烦恼，然后专注于保持周围网站的性能。而且更有趣。
此外，如果带宽使用量确实非常高，请考虑将您的 Web 服务器用作“边缘”服务器。在大多数大容量存储场景中，1% 的内容在 99% 的时间里被请求（例如 Facebook 照片）。一些脚本可以在本地镜像最近请求的 1GB 图像，并按上次访问时间刷新，这应该很容易做到，并且可能将 S3 带宽成本保持在免费套餐内。
答案2
据我所知，没有办法调整现有文件系统上的 inode 数量。
如果您可以重新创建文件系统，则可以使用该-N选项为新 FS 指定更多的 inode 数量