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

Question

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

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

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

Answer 1

你看过MongoDB的GridFS吗？ http://www.mongodb.org/display/DOCS/GridFS+Specification

您可以按默认元数据以及您自己的其他元数据查询文件。文件分为小块，您可以指定所需的部分。此外，文件存储在一个集合中（类似于RDBMS表），您可以启动Mongo的复制功能。

Answer 2

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

如果您正在寻找一个对象存储，Hadoop就是为此而构建的。根据我的经验，Hadoop是一种痛苦的工作和维护。

Answer 3

对我而言，Lustre和Ceph都存在像Cassandra这样的数据库没有的问题。我认为这里的核心问题是Cassandra和其他类似数据库的缺点是FS后端。

性能显然可以是一个。空间使用怎么样？一致性？