许多“BAW”（大屁股网站）正在使用数据存储和检索技术，这些技术依赖于带索引的巨大表，并使用在查询中不会/不能使用JOIN的查询（BigTable，HQL）等）处理可伸缩性和分片数据库。当你有大量非常相关的数据时，它是如何工作的？
我只能推测这种加入的大部分必须在应用程序方面完成，但这不会开始变得昂贵吗？如果您必须对几个不同的表进行多次查询以获取要编译的信息，该怎么办？是不是多次开始变得比仅仅使用连接更昂贵的数据库？我想这取决于你有多少数据？
对于常用的ORM，它们如何处理无法使用连接的问题？今天在大量使用的ORM中是否有对此的支持？或者大多数必须接近这一级别数据的项目是否会自行推出？
所以这不适用于我正在进行的任何当前项目，但是现在已经有几个月了，我只能猜测“最佳实践”是什么。我从来没有必要在任何项目中解决这个问题，因为他们从未达到过需要的规模。希望这个问题能帮助其他人......
正如有人在下面所说的，ORM在没有连接的情况下“无法工作”。是否有其他数据访问层已经可供处理此级别数据的开发人员使用？
修改 有些澄清，Vinko Vrsalovic说：
“我相信窃笑是想谈谈 关于NO-SQL，其中有事务数据 非规范化并用于Hadoop或 BigTable或Cassandra计划。“
这正是我所说的。
获取xkcd参考资料的人的奖励积分。
答案 0 :(得分：35)
我看待它的方式，关系数据库是一种通用的工具来对冲你的赌注。现代计算机足够快，RDBMS'已经过充分优化，你可以在一个盒子上成长到相当可观的尺寸。通过选择RDBMS，您可以非常灵活地访问数据，并具有强大的正确性约束，从而可以更轻松地对数据进行编码。但是，RDBMS不能代表任何特定问题的良好优化，它只是让您可以轻松地轻松更改问题。
如果您开始快速增长并意识到您将不得不扩展到超过单个数据库服务器的规模，那么您突然有更难的选择。您需要开始识别瓶颈并将其删除。 RDBMS将成为一个令人讨厌的狡猾的共同依赖结，你必须分开。您的数据越相互联系，您将需要做的工作就越多，但也许您不必完全解开整个问题。 如果你读得很重，也许你可以通过简单的复制来实现。如果你正在使你的市场饱和并且增长趋于稳定，那么你可以将部分非规范化和分解为固定数量的数据库服务器。也许你只有一些问题表可以转移到一个更具伸缩性的数据存储。也许您的使用配置文件非常缓存，您可以将负载迁移到一个巨大的memcached集群。
当像BigTable这样的可扩展键值存储进入的时候，上述任何一个都无法工作，并且你有一个单一类型的数据，即使它被非规范化，单个表对于一个服务器来说太多了。此时，您需要能够对其进行任意分区，并且仍然可以使用干净的API来访问它。当然，当数据分布在如此多的机器上时，您就无法拥有需要这些机器相互通信的算法，这是许多标准关系算法所需要的。正如您所建议的那样，这些分布式查询算法在正确索引的关系数据库中可能需要比等效JOIN更多的总处理能力，但由于它们是并行化的，因此实时性能比任何一台机器都要好几个数量级（假设一个可以保存整个索引的机器甚至存在。）
现在，一旦您可以横向扩展海量数据集（只需插入更多服务器），就可以完成可扩展性的难点部分。好吧，我不应该说完成，因为这种规模的持续运营和开发比单服务器应用程序要困难得多，但关键是应用程序服务器通常是无关紧要的，无需通过共享只要他们能够及时获得所需的数据，就可以建立架构。
要回答关于常用ORM如何处理无法使用JOIN的问题，简短的答案是它们不。 ORM代表对象关系映射，ORM的大部分工作只是翻译谓词逻辑简单面向对象数据结构的强大关系范例。他们给你的大部分价值根本不可能来自一个键值商店。在实践中，您可能需要建立和维护适合您特定需求的数据访问层，因为这些规模的数据配置文件会发生巨大变化，我相信对于通用工具的出现会有太多的权衡因素并成为RDBMS的主导方式。简而言之，你将不得不在这种规模上做更多的工作。
也就是说，看看在键值存储原语之上构建什么样的关系或其他聚合功能肯定会很有趣。我在这里没有足够的经验来具体评论，但是企业计算方面有很多关于这可以追溯到很多年的知识（例如Oracle），学术界有很多未开发的理论知识，很多实践知识在谷歌，亚马逊，Facebook等，但已经过滤到更广泛的开发社区的知识仍然相当有限。
然而，现在许多应用程序正在转向网络，并且越来越多的全球人口在线，不可避免地会有越来越多的应用程序需要扩展，最佳实践将开始明确。知识差距将由AppEngine和EC2等云服务以及像Cassandra这样的开源数据库双方削弱。在某种意义上，这与并行和异步计算密切相关，这也是处于起步阶段。绝对是成为程序员的迷人时光。
答案 1 :(得分：21)
你是从一个错误的假设开始的。
数据仓库不会像事务应用程序规范化那样规范化数据。没有“很多”的连接。相对较少。
特别是第二和第三范式违规不是“问题”，因为数据仓库很少更新。当它们被更新时，通常只有一个状态标志更改，以使维度行为“当前”与“非当前”。
由于您不必担心更新，因此您不会将事物分解为2NF级别，而更新不会导致异常关系。没有更新意味着没有异常;并且没有分解和没有连接。您可以预先加入所有内容。
通常，DW数据根据星型模式进行分解。这将指导您将数据分解为包含度量的数字“事实”表 - 包含单位的数字 - 以及对维度的外键引用。
维度（或“商业实体”）最好被认为是具有属性的真实世界。通常，这包括地理，时间，产品，客户等等。这些事情通常具有复杂的层次结构。层次结构通常是任意的，由各种业务报告需求定义，而不是作为单独的表建模，而只是用于聚合的维度中的列。
解决您的一些问题。
“这种加入必须在事物的应用方面完成”。的种类。数据在加载之前是“预先连接”的。维度数据通常是关于该维度的相关源数据的联接。它以相对平坦的结构连接和装载。
它没有更新。而不是更新，插入额外的历史记录。
“但这不会开始变得昂贵吗？”的种类。获取数据需要一些小心。但是，没有很多报告/分析连接。数据已预先加入。
由于数据是预先加入的，ORM问题在很大程度上没有实际意义。您的ORM会根据需要映射到事实或维度。除特殊情况外，尺寸往往很小，完全适合记忆。例外情况是您在财务（银行或保险）或公用事业，并拥有大量客户数据库。这些客户维度很少适合记忆。
答案 2 :(得分：14)
JOIN是一个纯粹的关系术语，并非所有数据库都是关系型的。
其他数据库模型还有其他方式来建立关系。
网络数据库使用find a key - fetch the reference - find a key的无限链，应使用通用编程语言进行编程。
代码可以在应用程序端或服务器端运行，但它不是SQL，甚至不是基于集合的。
如果设计得当，网络数据库可以比关系数据库快得多。
例如，网络数据库可以存储对另一个实体的引用，作为指向文件中偏移量的直接指针，甚至是存储有关此实体的信息的磁盘上的块。
这使得遍历网络的速度更快 - 如果您编写了一个有效的代码来执行此操作。
关系数据库只能将引用存储为基本值对，如整数（或三阶或更高阶的元组）。
要在关系数据库中查找这些值，引擎应该执行以下操作：
B-Tree中根目录的地址，其中包含第二个数字引用的数据B-Tree本身，在这种情况下，指针是我们所追踪的行的PRIMARY KEY的值）你只能在一定程度上控制它。之后，您只需发出SQL查询并等待。
关系模型是为了简化开发人员的生活，而不是始终如一地实现超高速。
这与汇编语言与高级语言相同，关系模型是更高级别的语言。
您可能需要阅读我博客中的文章
，其中我试图解释几种常用数据库模型之间的差异。
答案 3 :(得分：4)
当您以这种方式对数据进行非规范化时，您这样做是为了避免加入不同项目的成本;为了使用简单查询的性能优势，您接受某些数据可能会重复并且某些组合方式可能很困难。
如果你不得不在应用程序级别进行大量的加入，这意味着你没有对它进行非规范化。
理想情况下，您可以对所需的任何数据集进行一次查询。实际上，对于应用程序的任何方面，您不必使用两个或三个以上的查询，并且任何应用程序级别的连接都将更加简单地从单独的结果集中检索插入到视图中的内容。
这种事情只对真正庞大的数据集才真正需要，并且涉及各种权衡。举一个例子：BigTable无法进行聚合查询，例如给你一个计数。它可以用来给你一个大致准确的数字 - 从某种意义上说，如果你有12,149,173条记录，其中23,721条记录是在最后一小时内添加的，那么你能找到的最好记录是不是真的很重要你有“约12,100,000条记录”。如果你的应用程序依赖于在任何给定时刻知道精确的数字，那么你不应该使用BigTable，这是一般的态度。
答案 4 :(得分：3)
像facebook这样的应用程序几乎没有数据更改，大多数时候用户都在发布新项目。因此，当项目被更改时，乘法记录需要更新的事实是一个较小的问题。
这允许数据不存在 标准化而不击中常见的 更新问题。
像亚马逊这样的应用程序可以将单个用户的所有数据加载到RAM中（毕竟购物车有多大？），然后更新RAM中的数据并将其作为单个数据项写出来。
再次删除需要 大多数数据标准化。
您正在进行扩展以简化应用程序开发，因此如果您不需要扩展到很高的高度，您可能希望保持RDBMS提供的应用程序开发的简易性。
答案 5 :(得分：0)
我认为在这些情况下，你将会独自完成自己并且必须自己动手。我没有去过那里，但已经考虑过我们的一些项目了。你可以通过关系数据库获得相当大的数据（如SO所示），所以我现在将继续享受关系的优点。
答案 6 :(得分：0)
通常，数据仓库是围绕使用连接和数据分割成维度和事实表（使用所谓的“星型模式”等）构建的。
通常会预先计算联接并将其存储为非规范化表格。
我不知道有任何ORM工具可以使用不允许连接的数据库系统，因为这些工具通常不被视为传统的关系数据库。