本文主要是介绍分库分表之后怎么进行join操作?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
一、应用层join
二、使用数据库中间件
三、数据冗余
四、搜索引擎
在我们做了分库分表之后,数据会散落在不同的数据库中,这时候在需要进行跨库或跨表的JOIN操作时,就会比较麻烦。
如果数据被分表后,分散在不同的数据库上面,那么标准的join是要在单库内执行的,所以这就会带来复杂性。还有就是不同的库可能在不同的服务器上面,那么一次join就需要和多个数据库交互,那就会有更多的网络延迟,带来性能问题。
而且,有的时候一次join可能并不是2个库,而可能是多个库,比如订单和用户join,我们要查的用户可能散布在很多个库中,那么一次join就会横跨很多库。
那么如何解决呢?有如下几个方法。
一、应用层join
在应用代码中单独查询各个表,然后在应用层将结果合并。这意味着所有必要的数据被加载到应用服务器的内存中,然后执行类似于join的操作。如:
//先从数据库中查询出要查询的订单列表
List<OrderDO> orders = getOrders();for(OrderDO orderDO : orders){OrderDTO orderDTO= new OrderDTO(orderDO);//根据用户ID去users表查询用户名String userName = getUserNameByUserId(orderDO.getUserId());orderDTO.setUserName(userName);
}
这么做的优点是,灵活,可以跨不同的数据库和表实现。不依赖数据库特性,适用于任何数据库系统。
但是他的缺点也很明显,那就是对应用服务器的内存和处理能力要求较高,尤其是数据量大时。而且网络开销可能增加,性能可能受到影响。
二、使用数据库中间件
在分库分表后,我们也可以使用诸如MyCat、Shardingsphere等数据库中间件来支持分库分表环境下的 JOIN 操作,比如使用shardingsphere的联邦查询功能(这个功能还在完善中,并不是特别建议在生产环境中用)。这些中间件可以理解为一个数据库代理,对应用透明地处理数据分片和查询路由。
这个方案的优点是对应用透明,应用不需要关心数据如何分片。可以较为高效地执行查询优化和数据汇总。缺点就是引入额外的系统复杂性和维护成本。性能和支持的SQL特性可能受限于中间件的能力。
三、数据冗余
还有一种方案,那就是调整分库分表策略,尽量减少需要执行 JOIN 操作的场景,比如通过合理的数据冗余和预聚合来避免跨库查询。
这个方案可以显著减少复杂查询,提升系统性能。减少了跨网络的数据传输。缺点是一致性问题,也会增加存储空间。
但是,这个方案确实是公司里面用的比较多的。很多时候对于一些不常修改的字段,做一些数据冗余是非常方便的,比如用户的真实姓名。
四、搜索引擎
使用Elasticsearch等搜索引擎,也是可以解决跨库JOIN的问题的,尤其是在处理大数据和复杂搜索场景时。
我们可以基于前面宽表的思想,把orders表和users中我们关心的所有字段做成一个文档,如类似以下形式:
{
"userId": "123",
"userName": "CLAY",
"orders": [{"orderId": "a1","orderDate": "2021-01-01","amount": 100},{"orderId": "b2","orderDate": "2021-02-01","amount": 150}
]
}
然后再基于canal等工具,把orders表及users表的变更同步到ES中,这样我们就可以基于ES直接做查询了。
这篇关于分库分表之后怎么进行join操作?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!