类似BigTable、SimpleDB等数据库的Pro

分布式数据库并不像猎户座暗示的那样幼稚;在优化分布式数据集上的完全关系查询方面已经做了很多工作。您可能想看看Teradata、Netezza、Greenplum、Vertica、AsterData等公司正在做什么。(甲骨文最终也加入了这场游戏,因为他们最近发布了一项声明;微软以曾经被称为DataAllegro的公司的名义收购了他们的solition)。

也就是说,当数据扩展到TB时,这些问题变得非常重要。如果您不需要从RDBMs获得严格的事务性和一致性保证,那么反规范化和不进行连接通常要容易得多。尤其是当你不需要交叉引用的时候。特别是如果您不进行特殊分析,但需要通过任意转换进行编程访问。

非规范化被高估了。仅仅因为这是处理100Tera时发生的情况,并不意味着每个开发人员都应该使用这一事实,因为他们从来没有费心学习数据库,并且由于糟糕的模式规划和查询优化而在查询一百万或两行时遇到困难。

哦,这些技术引起热议的另一个原因是人们发现有些东西从一开始就不属于数据库,并且意识到它们处理的不是特定领域中的关系,而是基本的键值对。对于不应该在DB中的东西,完全可能是Map Reduce框架,或者某种持久的、最终一致的存储系统。

在不太全球化的范围内,我强烈推荐伯克利DB解决这些问题。

我对它们不太熟悉(我只读过与其他人相同的博客/新闻/示例),但我的看法是,它们选择以可伸缩性的名义牺牲了许多正常的关系数据库功能——我将尝试解释一下。

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

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

. 当您有200万行分布在10台服务器上时,请尝试这样做。

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

所以我得到的是整个“非规范化,无连接”哲学的存在,不是因为连接本身不能在大型系统中扩展,而是因为它们实际上不可能在分布式数据库中实现。

当您存储单一类型的基本不变数据时(就像Google一样),这似乎非常合理。我走对了吗?

如果您谈论的数据实际上是只读的,那么规则就会改变。在数据更改的情况下,反规范化是最困难的,因为所需的工作量增加了,而且锁定问题更多。如果数据几乎没有变化,那么反规范化就不是什么问题。