我们有一个 SQL server 2008 和其中一个表，假设表 A 具有以下特征:
- 每天，我们都会从其他系统获得多个包含数字数据的异构提要。
- 提要在别处暂存，转换为符合 A 架构的格式。
- 插入到 A.
架构如下:
表格的行数可变。基本上我们必须在周末清除它，否则大小会影响性能。因此，一周内的尺寸范围为 3m-15m 行。 由于一些新要求，我们预计到 2012 年底这个数字将增加 1000 万。所以我们会谈论 10m-25m 行。
现在另外
- A 中的数据永远不会改变。中间层可能使用 A 的数据，但它将是只读操作。但通常中间层甚至不关心内容。它通常(并非总是如此，但在 80% 的情况下)运行存储过程以生成报告并在其他系统中交付报告。
- 这些表的客户通常希望对一个业务日期和类型进行长时间的顺序读取。即 “给我今天的所有类型 1 值”
- 客户希望将此表与另外 3-5 个表连接起来，然后将报告传送到其他系统。
- 上述假设不一定适用于与 A 连接的所有表。例如，我们通常将 A 与表 B 连接起来，然后进行类似 B.value*A.value 的计算。 B.value 是一个可变列。
问题
- A 的特征听起来确实很像 HBase 和其他面向列的模式可以提供的。
- 但是，一些连接的数据不稳定。
您会建议将 A 迁移到 HBase 模式吗？
而且，如果我们要移动 A，我认为我们还必须从中间层迁移 B 和其他从属表(与 A 相反)，这些表正被其他几个地方使用。这不会使事情复杂化吗？
最佳答案
虽然使用模式适合，但 2500 万行听起来不足以证明使用 HBase 是合理的。您需要一个名称节点、一个作业跟踪器、一个主服务器，然后是您的区域服务器，因此您至少需要 5 个节点才能以任何合理的方式运行 HBase。你的行太小了，我猜它可能是 10GB 的数据，所以将它存储在 5 个服务器上似乎有点过头了。
如果您确实选择了这条路线(也许您想一次存储超过一周的数据)，则可以通过多种方式将 HBase 与关系数据库集成。例如，Hive 提供 ODBC/JDBC 连接并可以查询 HBase。 Oracle 和 Teradata 都提供了它们的关系数据库软件和非关系存储之间的集成。我知道微软最近宣布他们将放弃 Dryad 以支持与 Hadoop 的集成，但我不确定这个过程与 SQL Server 相距多远。如果您只需要“获取要在我的 SQL 查询中使用的 ID 列表”，您当然可以自己轻松编写一些东西。
我认为 HBase 非常令人兴奋，并且可能有一些您没有提到的事情会促使您转向它(例如高可用性)。但我的直觉告诉你，你可以比切换到 HBase 更便宜地扩展你的关系数据库。
关于hadoop - 您会推荐使用 Hadoop/HBASE 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8340012/