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

Question

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

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

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

我目前的问题是，HDFS和HBase是否会在我们的环境中发挥得很好？正如我所知道的，HDFS的设计是为了存储非常大的二进制数据，但是也许使用HBase和一些配置调优可以使这个东西工作更小的数据？我还必须指出，性能对于读取和写入文件都非常重要。

我很想听听你对我提到的技术的经验，也许任何人都可以为这个问题推荐其他的解决方案(Apache？)。

而且，我们的团队在分布式大数据解决方案方面没有经验，比如Hadoop提供的解决方案，所以如果您认为这些框架可能适用于我们的情况，也许您可以给出您对它们的集成的反馈，或者关于从哪里开始我的调查的任何提示。感谢您的关注。:)

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

Answer 1

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

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

对于大多数与实际用户交互或为这些应用程序提供服务的基于云的应用程序来说，最合适的数据存储是对象存储，比如Amazon。它们提供了方便的API，合理的延迟，高可用性和几乎无限。最重要的是，它们通常是由第三方管理的，消除了开发人员方面的大量工作和关注。