在我看来，关系数据库是一种通用工具来对冲你的赌注。现代计算机足够快，并且 RDBMS 已经足够优化，您可以在单个机器上增长到相当可观的大小。通过选择 RDBMS，您可以非常灵活地访问数据，并且能够拥有强大的正确性约束，从而更容易针对数据进行编码。然而，RDBMS 并不代表任何特定问题的良好优化，它只是为您提供轻松更改问题的灵活性。
如果您开始快速增长并意识到您将不得不扩展超出单个数据库服务器的大小，那么您会突然做出更难的选择。您将需要开始识别瓶颈并消除它们。RDBMS 将是一个令人讨厌的相互依赖的结，您必须将其分开。您的数据相互关联越多，您要做的工作就越多，但也许您不必完全解开整个事情。如果您阅读量很大，也许您可以通过简单的复制来解决问题。如果您的市场已经饱和并且增长趋于平稳，那么您可以部分非规范化并分片到固定数量的数据库服务器。也许您只有少数可以移动到更具可扩展性的数据存储的问题表。
像 BigTable 这样的可扩展键值存储出现的地方是当上述任何一种方法都不起作用时，并且您拥有如此多的单一类型的数据，即使它被非规范化，单个表对于一台服务器来说也太多了。此时您需要能够任意对其进行分区，并且仍然有一个干净的 API 可以访问它。自然地，当数据分布在这么多机器上时，您就无法拥有需要这些机器相互进行大量通信的算法，而这是许多标准关系算法所需要的。正如您所建议的，这些分布式查询算法有可能比正确索引的关系数据库中的等效 JOIN 需要更多的总处理能力，
现在，一旦您可以水平扩展海量数据集（只需插入更多服务器），可扩展性的难点就完成了。好吧，我不应该说完成，因为这种规模的持续运营和开发比单服务器应用程序要困难得多，但关键是应用程序服务器通常可以通过无共享架构进行扩展，只要它们可以得到他们需要及时的数据。
要回答您关于常用 ORM 如何处理无法使用 JOIN 的问题，简短的回答是它们不会。ORM 代表对象关系映射，ORM 的大部分工作只是翻译谓词逻辑简单的面向对象数据结构的强大关系范式。他们为您提供的大部分价值根本不可能从键值存储中获得。在实践中，您可能需要构建和维护适合您特定需求的自己的数据访问层，因为这些规模的数据配置文件会发生巨大变化，而且我相信对于通用工具的出现有太多的权衡并以 RDBMS 的方式占据主导地位。简而言之，在这种规模下，你总是需要做更多的跑腿工作。
也就是说，看看可以在键值存储原语之上构建什么样的关系或其他聚合功能肯定会很有趣。我真的没有足够的经验来具体评论，但是在企业计算方面有很多关于这可以追溯到很多年前的知识（例如 Oracle），在学术界有很多未开发的理论知识，在谷歌、亚马逊、Facebook 等，但过滤到更广泛的开发社区的知识仍然相当有限。
然而，现在大量应用程序正在迁移到网络，并且世界上越来越多的人在线，不可避免地，越来越多的应用程序必须扩展，最佳实践将开始具体化。AppEngine 和 EC2 等云服务以及 Cassandra 等开源数据库将缩小双方的知识差距。在某种意义上，这与同样处于起步阶段的并行和异步计算密切相关。绝对是成为程序员的迷人时刻。