用于文件系统存储组织和复制的 NoSQL？

Question

我们一直在讨论我们小组内的数据仓库策略设计，以满足测试、再现性和数据同步要求。建议的想法之一是使用 existing tool 来调整 NoSQL 方法，而不是尝试在文件系统上重新实现很多相同的方法。我不知道 NoSQL 方法是否是我们正在努力完成的最佳方法，但如果我描述了我们需要/希望你们所有人都可以提供的帮助。

1. 我们的大多数文件都很大，大小超过 50 Gig，以专有的第三方格式保存。我们需要能够通过名称/日期/源/时间/工件组合访问每个文件。本质上是一种键值对样式查找。
2. 当我们查询文件时，我们不希望将所有文件都加载到内存中。它们真的太大了，会淹没我们的服务器。我们希望能够以某种方式获得对文件的引用，然后使用专有的第三方 API 提取其中的一部分。
3. 我们希望从存储中轻松添加、删除和导出文件。
4. 我们想在两台服务器之间设置自动文件复制（我们可以为此编写一个脚本。）也就是说，将一台服务器的内容与另一台服务器同步。我们不需要一个分布式系统，它看起来好像我们只有一台服务器。我们想要完整的复制。
5. 我们还有其他与大文件有树型关系的小文件。一个文件的内容将指向下一个，依此类推。这不是一个“辐条轮”，而是一棵成熟的树。

我们更喜欢 Python、C 或 C++ API 来使用这样的系统，但我们大多数人都熟悉各种语言。只要它有效，完成工作并节省我们的时间，我们就不会介意。你认为呢？有这样的东西吗？

Answer 1

对我来说，Lustre 和 Ceph 都有一些像 Cassandra 这样的数据库没有的问题。我认为这里的核心问题是 Cassandra 和其他类似的数据库作为 FS 后端有什么缺点。

性能显然可以是一。空间使用情况如何？一致性？

Answer 2

您看过 MongoDB 的 GridFS。 http://www.mongodb.org/display/DOCS/GridFS+Specification

您可以通过默认元数据以及您自己的附加元数据来查询文件。文件被分成小块，你可以指定你想要的部分。此外，文件存储在一个集合中（类似于 RDBMS 表），您可以启动 Mongo 的复制功能。

Answer 3

经过验证的集群文件系统有什么问题？ Lustre 和 ceph 是不错的候选人。

如果您正在寻找对象存储，那么构建 Hadoop 时就考虑到了这一点。以我的经验，使用和维护 Hadoop 很痛苦。