Jakarta ee 使用HDFS存储不同大小的文件

我有一个相当理论性的问题

我的团队正在开发和支持一个中型java应用程序（目前有400k行），它处理大量二进制文件。目前，我们将所有数据存储在FS存储器上。我们开发了一个小的“框架”，它将允许我们在将来扩展文件存储，但是，我强烈怀疑在Windows/Linux文件系统上存储数据仍然是一个瓶颈（不用说，在分布式数据处理中重新发明一个轮子，然后依靠它似乎不是一个真正好的解决方案：）

我们处理的数据大小从每个文件1-2mb到数百mb（很少是千兆字节），并且经常访问。但我想强调的是，这些文件大部分都很小。同时考虑到我们向大数据和ML分析发展的长期计划，我正在研究将Hadoop生态系统集成到我们的应用程序中的可能性

我目前的问题是HDFS和HBase是否能在我们的环境中发挥良好的作用？据我所知，HDFS的设计目的是存储非常大的二进制数据，但也许使用HBase和一些配置调整，可以让它在更小的数据中工作？我还必须提到，性能对读取和写入文件都很重要

我很想听听你对我提到的技术的经验，也许任何人都可以推荐解决这个问题的替代方案（Apache拼花地板？）

此外，我们的团队在分布式大数据解决方案方面没有Hadoop提供的经验，因此，如果您认为这些框架可能适用于我们的案例，也许您可以就它们的集成提供反馈，或者就从何处开始我的调查提供任何提示。谢谢您的关注。：）

---

另外，除了FS之外，我们还使用S3来归档旧数据和存储大型（>1gb）二进制文件，因此从这个角度来看，引入单一存储系统也会很酷。

经过一番小调查，我了解到，分布式文件存储（如HDFS和noSQL存储）不太适合于以低延迟为目标的应用程序

这些系统被设计为在大数据世界中运行，在大数据世界中，高总吞吐量比延迟更有价值，二进制文件的大小也是巨大的

---

对于大多数与真实用户交互或为此类应用程序提供服务的基于云的应用程序，最合适的数据存储是对象存储，如Amazon S3。它们提供了方便的API、合理的延迟、高可用性和几乎不受限制的性能。最重要的是，它们通常由第三方管理，这消除了开发人员的大量工作和顾虑。

对于单个文件，它是一次写入，多次读取吗？@daemon12是的，这是正确的。另外，目前我们有很多拷贝操作，但在迁移到另一个存储系统时，也许我们可以避免这些操作。另外，目前大部分代码都是遗留的，我们正在一个模块一个模块地迁移到新的平台，因此我们可能可以重构业务逻辑，这样就不需要太多的复制。