Pro的数据库,如BigTable,SimpleDB

像Google BigTable和Amazon SimpleDB这样的新学校数据存储范例是专门为可扩展性而设计的.基本上,禁止连接和非规范化是实现这一目标的方法.

然而,在这个主题中,共识似乎是大型表上的连接不一定必须太昂贵,并且非规范化在某种程度上被"高估"为什么然后,这些上述系统不允许连接并强制所有连接在一起单表实现可扩展性？是否需要存储在这些系统中的大量数据(许多兆兆字节)？
数据库的一般规则是否根本不适用于这些尺度？是因为这些数据库类型专门用于存储许多类似的对象吗？
或者我错过了一些更大的图片？

分布式数据库并不像Orion暗示的那样天真; 在分布式数据集上优化完全关系查询方面已经做了大量工作.您可能想看看像Teradata,Netezza,Greenplum,Vertica,AsterData等公司正在做什么.(最后甲骨文最近公布了这个游戏;微软以这家曾经被称为DataAllegro的公司的名义购买了他们的解决方案).

话虽如此,当数据扩展到太字节时,这些问题变得非常重要.如果您不需要严格的事务性和一致性保证可以从RDBM获取,则通常更容易进行非规范化而不进行连接.特别是如果你不需要交叉引用太多.特别是如果您不进行临时分析,但需要使用任意转换进行编程访问.

非规范化被高估了.仅仅因为当你处理100 Tera时会发生这种情况,并不意味着每个开发人员都应该使用这个事实,他们从不费心去了解数据库,并且由于糟糕的模式规划和查询优化而无法查询一百或两行.

但如果你处于100 Tera范围内,那么......

哦,这些技术引起轰动的另一个原因 - 人们首先发现有些东西从未属于数据库,并且意识到他们并没有处理特定领域的关系,而是基本的关键 - 价值对.对于不应该存在于数据库中的东西,完全有可能Map-Reduce框架或一些持久的,最终一致的存储系统就是这样.

在全球范围内,我强烈推荐BerkeleyDB解决这些问题.

我对它们并不太熟悉(我只阅读与其他人一样的博客/新闻/示例),但我对它的看法是,他们选择以可扩展性的名义牺牲了许多正常的关系数据库功能 - 我会试着解释一下.

想象一下,数据表中有200行.

在谷歌的数据中心,这些行中的50行存储在服务器A上,50位在B上,100位在服务器C上.此外,服务器D包含来自服务器A和B的冗余数据副本,服务器E包含服务器C上的冗余数据副本.

(在现实生活中,我不知道将使用多少台服务器,但它的设置是为了处理数百万行,所以我想象不少).

要"选择*where name ='orion'",基础结构可以将该查询发送到所有服务器,并聚合返回的结果.这允许他们在他们喜欢的服务器上进行几乎线性扩展(仅供参考,这几乎是mapreduce)

然而,这意味着您需要一些权衡.

如果您需要对某些数据进行关系连接,而这些数据分布在5个服务器上,则每个服务器都需要为每一行提取数据.当您在10台服务器上分布有200万行时,请尝试这样做.

这导致了权衡#1 - 没有连接.

此外,根据网络延迟,服务器负载等,您的一些数据可能会立即保存,但有些可能需要一秒钟或2.再次,当您有几十台服务器时,这会越来越长,而且正常的方法是'每个人都等到最慢的人完成'不再可以接受.

这导致权衡#2 - 您的数据在写完后可能并不总是立即可见.

我不确定那里有什么其他的权衡,但在我的头脑中那些是主要的2.