Hadoop作为文档存储数据库

我们有一个大型文档存储,目前在3TB空间运行,每六个月增加1 TB.它们目前存储在 Windows文件系统中,这有时会在访问和检索方面造成问题.我们希望利用基于Haddop的文档存储数据库.继续使用Haddop是一个好主意吗?任何人都有同样的曝光?实现同样的挑战和技术障碍可能是什么?
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可能适合你的原因.但是再次取决于你的数据(是文件)单词文档或文本文档与产品,发票或工具或其他东西的信息)…

同样,它要理解您的数据和访问模式,NoSQL系统也是非Rel,即非关系,并且更适合非关系数据集.如果您的数据本质上是关系型的,并且您需要一些真正需要执行诸如笛卡尔积(也称为连接)之类的SQL查询功能,那么您可能更好地坚持使用Oracle并在索引,分片和性能调整方面投入一些时间.

我的建议是实际使用几个不同的系统.看着;

MongoDB – 文档 – CP

CouchDB – 文档 – AP

Cassandra – 柱系列 – 可用&分区容忍(AP)

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

无论如何,这是我的2c.玩弄系统真的是你找出真正适用于你的情况的唯一方法.

相关文章
相关标签/搜索