我们目前有一个大型文档存储空间，目前在3TB空间运行，每六个月增加1 TB。它们目前存储在Windows文件系统中，这有时会在访问和检索方面造成问题。我们正在寻找利用基于Haddop的文档存储数据库。继续使用Haddop是一个好主意吗？任何人都有同样的曝光？实现同样的挑战和技术障碍可能是什么？
答案 0 :(得分：10)
Hadoop更适用于高数据访问的批处理。你应该看看一些NoSQL系统，比如面向文档的数据库。在不知道您的数据是什么的情况下很难回答。
NoSQL设计的首要规则是首先定义您的查询方案。一旦你真正理解了如何查询数据，那么你可以查看各种NoSQL解决方案。默认的分配单位是关键。因此，您需要记住，您需要能够在节点机器之间有效地分割数据，否则您将最终得到一个水平可伸缩的系统，所有工作仍在一个节点上完成（尽管根据具体情况更好的查询）。
您还需要回顾CAP定理，大多数NoSQL数据库最终都是一致的（CP或AP），而传统的Relational DBMS是CA.这将影响您处理数据和创建某些事物的方式，例如密钥生成可能会变得棘手。显然文件夹中的文件有点不同。
还要记住，在某些系统中，例如HBase，没有索引概念（我猜你在这个Windows FS文档存储上有文件索引设置）。您的应用程序逻辑需要构建所有索引，并且需要对所有更新和删除进行管理。使用Mongo，您实际上可以在字段上创建索引并相对快速地查询它们，还可以将Solr与Mongo集成。您不仅需要在Mongo中按ID进行查询，就像在HBase中进行查询一样，这是一个列族（也称为Google BigTable样式数据库），您实际上拥有嵌套的键值对。
因此，再次涉及到您的数据，您要存储的内容，您计划如何存储它，以及最重要的是您希望如何访问它。 Lily项目看起来非常有前途。我参与的工作是从网络上获取大量数据，我们将其存储，分析，剥离，解析，分析，流式传输，更新等等。我们不只是使用一个系统而是很多最适合手头的工作。对于这个过程，我们在不同阶段使用不同的系统，因为它使我们能够快速访问我们需要的地方，提供实时流式传输和分析数据的能力，重要的是，随时跟踪所有内容（如生产中的数据丢失）系统是一个大问题）。我正在使用Hadoop，HBase，Hive，MongoDB，Solr，MySQL甚至是好的旧文本文件。请记住，使用这些技术生产系统比在服务器上安装Oracle要困难一些，有些版本不稳定，你真的需要先进行测试。在一天结束时，它实际上取决于业务阻力水平和系统的任务关键性。
迄今为止没有人提到的另一条路径是NewSQL--即水平可扩展的RDBMS ......有一些像MySQL集群（我认为）和VoltDB可能适合你的原因。但是再次取决于你的数据（是文件word文档或文本文档与产品，发票或工具或其他东西的信息）...
同样，要了解您的数据和访问模式，NoSQL系统也是非Rel，即非关系，并且更适合非关系数据集。如果您的数据本质上是关系型的，并且您需要一些真正需要执行诸如笛卡尔积（也称为连接）之类的SQL查询功能，那么您可能会更好地坚持使用Oracle并在索引，分片和性能调整方面投入一些时间。
我的建议是实际使用几种不同的系统。看看;
MongoDB - 文档 - CP
CouchDB - 文档 - AP
Cassandra - 专栏系列 - 可用＆amp;分区容忍（AP）
VoltDB - 一个非常好看的产品，一个分布式的关系数据库，可能适用于您的情况（可能更容易移动）。它们似乎也提供了企业支持，这可能更适合产品环境（即为商业用户提供安全感）。
任何方式都是我的2c。玩弄系统真的是你找出真正适用于你的情况的唯一方法。
答案 1 :(得分：0)
HDFS听起来不是正确的解决方案。它针对数据的大规模parralel处理进行了优化，而不是通用文件系统。
具体而言，它具有以下限制，使其成为可能不好的选择：
a）它对文件数量敏感。实际限制应该是几十万个文件。
b）文件是只读的，只能附加，但不能编辑。它适用于分析数据处理，但可能无法满足您的需求。
c）它有单点故障 - namenode。所以它的可靠性有限。
如果您需要具有可比较可扩展性的系统，但对文件数量不敏感，我建议使用OpenStack的Swift。它也没有SPOF。
答案 2 :(得分：0)
我的建议是你可以购买NAS存储设备。可能是EMS isilon你可以考虑的产品。
Hadoop HDFS不适用于文件存储。它是处理数据的存储（用于报告，分析......）
NAS用于文件共享
SAN更适用于数据库
http://www.slideshare.net/jabramo/emc-sanoverviewpresentation
声明：我不是EMC人员，因此您可以考虑任何产品。我刚刚使用EMC作为参考。