Hadoop作为文档存储数据库

Question

我们有一个大型文档存储,目前在3TB空间运行,每六个月增加1 TB.它们目前存储在Windows文件系统中,这有时会在访问和检索方面造成问题.我们正在寻找利用基于Haddop的文档存储数据库.继续使用Haddop是一个好主意吗？任何人都有同样的曝光？实现同样的挑战和技术障碍可能是什么？

Answer 1

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 - 列族 - 可用和分区容忍(AP)

VoltDB - 一个非常好看的产品,一个分布式的关系数据库,可能适用于您的情况(可能更容易移动).它们似乎也提供了企业支持,这可能更适合于产品环境(即为企业用户提供安全感).

任何方式都是我的2c.玩弄系统真的是你找出真正适用于你的情况的唯一方法.