你会推荐使用Hadoop/HBASE吗？
我们有一个SQL server 2008和其中一个表，例如表A具有以下特征：
每天，我们从其他具有数字数据的系统中获得几个异构的提要。schema.
- Inserted
- 提要在其他地方被放置，转换成符合A's
- 格式的格式为A
- Schema，如下所示：
该表有可变的行数。基本上，我们必须在周末清除它，否则大小会影响性能。所以这一周的大小从300万到1500万排不等。由于一些新的要求，我们预计到2012年底，这一数字将增加1000万。所以我们要讨论的是10m到2500万行。
现在再加上
- 数据在A中从不更改。中间层可能使用A的数据，但它将是只读操作。但通常，中间层甚至不关心内容。它通常(不总是这样，但80%的情况)运行存储的过程来生成报告，并在这些表的其他systems.
- Clients中传递报告，通常需要对一个业务日期和类型执行长时间的顺序读取。也就是说，“获取today"
- Clients的所有类型1值将希望将该表与3-5多个表连接起来，然后将报告传递给其他系统。
- 上述假设不一定适用于与A连接的所有表。”例如，我们通常将A与表B连接起来，并进行类似于B.value*A.value的计算。B.value是易失性列。
问题
- A的特性听起来非常类似于HBase和其他面向列的模式能够实现的特性，其中一些联接使用的是易失性数据。
您建议将A迁移到HBase模式吗？
此外，如果我们移动A，我将假设我们还必须迁移B和其他相依的表，这些表(与A相反)正被其他几个地方从中间层使用。这不会让事情变得很复杂吗？
回答 1
Stack Overflow用户
发布于 2011-12-02 21:30:10
2500万行听起来不足以证明使用HBase是合理的，尽管使用模式适合。您需要一个名称节点、一个作业跟踪器、一个主服务器，然后是您的区域服务器，因此您至少需要5个节点才能以任何合理的方式运行HBase。您的行太小了，我猜它可能是10‘m的数据，所以在5台服务器上存储这些数据似乎太过了。
如果您确实这样做了(也许您希望一次存储超过一个星期的数据)，那么有一些方法可以将HBase与关系DB集成起来。例如，Hive提供ODBC/JDBC连接，并可以查询HBase。Oracle和Teradata都提供了它们的关系数据库软件和非关系存储之间的集成。我知道微软最近宣布放弃Dryad，转而支持与Hadoop的集成，但我不确定wrt SQL Server在这个过程中走了多远。如果您所需要的只是“获取要在我的SQL查询中使用的is列表”，那么您当然可以自己轻松地编写一些东西。
我认为HBase是非常令人兴奋的，而且可能有一些您没有提到的东西会驱使您走向它(例如，高可用性)。但是我的直觉告诉我，你可能比转换到HBase更便宜地扩展你的关系数据库。
https://stackoverflow.com/questions/8340012
复制相似问题
腾讯云开发者
