Google BigTable 和 Amazon SimpleDB 等新的学校数据存储范例是专门为可扩展性而设计的。基本上，不允许连接和非规范化是实现此目的的方式。
然而，在这个主题中，共识似乎是大表上的连接不一定必须太昂贵，并且非规范化在某种程度上被“高估”了为什么这些上述系统不允许连接并强制将所有内容放在一起单表实现可扩展性？是需要存储在这些系统中的大量数据（数 TB）吗？
数据库的一般规则是否根本不适用于这些规模？是因为这些数据库类型是专门为存储许多相似的对象而定制的吗？
还是我错过了更大的图景？
分布式数据库并不像 Orion 所暗示的那样天真。在优化分布式数据集上的完全关系查询方面已经做了很多工作。您可能想看看 Teradata、Netezza、Greenplum、Vertica、AsterData 等公司在做什么。（甲骨文最终也加入了这场游戏，他们最近宣布了这一消息；微软以曾经被称为 DataAllegro 的公司的名义购买了他们的 solition）。
话虽如此，当数据扩展到 TB 时，这些问题变得非常重要。如果您不需要可以从 RDBM 获得的严格事务性和一致性保证，那么反规范化和不进行连接通常要容易得多。特别是如果您不需要太多交叉引用。特别是如果您不进行临时分析，但需要通过任意转换进行编程访问。
非规范化被高估了。仅仅因为在处理 100 Tera 时会发生这种情况，并不意味着每个从不费心学习数据库并且由于架构规划和查询优化不佳而无法查询一百万或两行的开发人员都应该使用这个事实.
但是，如果您在 100 Tera 范围内，无论如何...
哦，这些技术引起轰动的另一个原因——人们发现有些东西一开始就不属于数据库，并意识到他们不是在处理特定领域的关系，而是用基本的键——值对。对于不应该在数据库中的东西，完全有可能 Map-Reduce 框架或一些持久的、最终一致的存储系统就是这样。
在全球范围内，我强烈推荐 BerkeleyDB 来解决这类问题。
我对它们不太熟悉（我只阅读了与其他人相同的博客/新闻/示例），但我的看法是，他们选择以可扩展性的名义牺牲许多正常的关系数据库功能 -我会试着解释一下。
假设您的数据表中有 200 行。
在 google 的数据中心中，其中 50 行存储在服务器 A 上，50 行存储在 B 上，100 行存储在服务器 C 上。此外，服务器 D 包含来自服务器 A 和 B 的数据的冗余副本，服务器 E 包含服务器 C 上的数据的冗余副本。
（在现实生活中，我不知道将使用多少台服务器，但它设置为处理数百万行，所以我想象不少）。
要“选择 * where name = 'orion'”，基础设施可以将该查询发送到所有服务器，并汇总返回的结果。这使他们可以在任意数量的服务器上进行线性扩展（仅供参考，这几乎就是 mapreduce）
然而，这意味着您需要一些权衡。
如果您需要对一些数据进行关系连接，这些数据分布在 5 台服务器上，那么这些服务器中的每台都需要从彼此的每一行中提取数据。当您有 200 万行分布在 10 台服务器上时，请尝试这样做。
这导致权衡#1 - 没有连接。
此外，根据网络延迟、服务器负载等，您的一些数据可能会立即保存，但有些可能需要一两秒钟。同样，当您有数十台服务器时，这会变得越来越长，而通常的方法是“每个人都等到最慢的人完成”不再是可以接受的。
这导致了权衡 #2 - 您的数据在写入后可能并不总是立即可见。
我不确定还有什么其他的权衡，但在我的脑海中，这些是主要的 2。
所以我得到的是整个“非规范化，无连接”的哲学存在，不是因为连接本身不能在大型系统中扩展，而是因为它们实际上不可能在分布式数据库中实现。
当您存储单一类型的大部分不变数据时，这似乎很合理（就像 Google 所做的那样）。我在正确的轨道上吗？
如果您谈论的是几乎只读的数据，则规则会发生变化。在数据更改的情况下，非规范化是最难的，因为所需的工作增加并且锁定问题更多。如果数据几乎没有变化，那么非规范化就不是什么大问题。
Novaday 你需要为数据库寻找更多的互操作环境。更频繁地，您不仅需要 MySQL 或 MS SQL 等关系数据库，还需要 Hadoop 等大数据场或 MongoDB 等非关系数据库。在某些情况下，所有这些数据库都将在一个解决方案中使用，因此它们的性能在宏观范围内必须尽可能相同。这意味着，您将无法使用 Azure SQL 作为关系数据库和一个具有 2 个内核和 3GB RAM 的 MongoDB 虚拟机。您必须扩大您的解决方案并在可能的情况下使用数据库即服务（如果不可能，则在云中构建您自己的集群）。