在考虑可伸缩性时，为什么联接不好？
为什么联接不好或“慢”。我知道我再听一次。我找到了这句话问题在于联接相对较慢，尤其是在非常大的数据集上，如果联接较慢，则您的网站也很慢。从磁盘上获取所有这些单独的信??息位并再次将它们重新组合在一起需要花费很长时间。
来源
我一直以为他们很快，尤其是在查找PK时。他们为什么“慢”？
解决方案:
可伸缩性是关于预计算（缓存），扩展或将重复的工作缩减为基本要件的全部目的，以最大程度地减少每个工作单元的资源使用量。为了实现良好的伸缩性，您无需做任何不需要做的事情，而实际上，您可以确保所做的事情能尽可能高效地完成。
在这种情况下，连接两个单独的数据源当然相对较慢，至少与不将它们连接起来相比，因为您需要在用户请求的位置进行实时工作。
但是请记住，替代方案是根本不再拥有两个单独的数据。您必须将两个不同的数据点放在同一记录中。您不能在没有结果的情况下将两个不同的数据合并在一起，因此请确保您了解了这些取舍。
好消息是现代关系数据库 擅长 联接。您不应该真正认为连接良好而使用良好的数据库会导致连接速度变慢。有许多的可扩展性，友好的方式吃生的加入，让他们 多
快：
加入代理键（自动编号/标识列）而不是自然键。这意味着在连接操作期间进行较小（因此更快）的比较
指标
物化/索引视图（将其视为预先计算的联接或 托管的 非规范化视图）
计算列。您可以使用它来哈希或以其他方式预先计算联接的键列，这样，联接的复杂比较现在要小得多，并且可能会被预先索引。
表分区（通过将负载分散到多个磁盘或将表扫描范围限制为分区扫描来帮助处理大型数据集）
OLAP（预先计算某些类型的查询/联接的结果。这不是很正确，但是您可以将其视为 通用的 非规范化）
复制，可用性组，日志传送或其他机制，可让多台服务器回答对同一数据库的读取查询，从而在几台服务器之间扩展您的工作负载。
使用像Redis这样的缓存层来避免重新运行需要复杂联接的查询。
我可能会说 关系数据库根本存在的主要原因是允许您有效地进行联接
*。当然不仅仅是存储结构化数据（您可以使用csv或xml之类的平面文件构造来实现此目的）。我列出的一些选项甚至可以让您预先完全建立连接，因此在发出查询之前已经完成了结果-
就像您对数据进行了非规范化一样（以降低写入操作的速度为代价）。
如果加入速度较慢，则可能是您未正确使用数据库。
仅在这些其他技术失败之后才可以进行非规范化。真正判断“失败”的唯一方法是设定有意义的性能目标并根据这些目标进行衡量。
如果您还没有衡量的话，甚至考虑去规范化还为时过早。
*即，作为实体存在于不同于表的单独集合中。真正的rdbms的另一个原因是安全的并发访问。
页:
[1]