由Oracle数据库迁移到分布式数据库之后，关联查询的语句怎么解决？

解决上述问题有几个思路：
1.产品层面
有些分布式数据库产品，提供“自动分布式”能力，即可以实现数据自主分片，不再需要人为干预。这样在结构设计无需做太多修改。针对语句方面，也可以免改造或低改造完成迁移。当然这种方式还是要看业务复杂度，很难做到完全规避因引入分布式带来的改造成本。且针对复杂查询情况下，目标数据库是否能很好处理且保证性能也是需关注的。
2.设计层面
在设计方面，提前做好响应的改造评估工作。如对现有结构、语句通过工具扫描方式，获得当前的工作负载，针对分布式情况下做改造评估等。这种方式不会减少改造工作量，但会提前规划避免被动。这种也是我比较推荐的方式。
3.架构层面
针对复杂的Oracle查询，有些场景可考虑下移到大数据技术栈解决。后者针对复杂关联查询，会更为适合。但两者需解决数据同步问题且业务是否接受一定延迟，也需关注。

由Oracle数据库迁移到分布式数据库之后，除了让尽量把需要关联的表按照相同的规则分布在一个节点外，现在系统的数据量都是5T以上的，不同的表已经按照不同的规则进行了分区，这些表之间的关联查询是应用必须要的而且频率很高，如果需要把所有的表按照统一规则去设置分布字段让同一用户下的资料都相同的节点上，这样的话改造就非常大，万一要回退也会非常麻烦，请问一下专家，这个问题还有没有其他好办法来解决复杂的关联查询的问题，又不会导致应用改造过大

稍微总结下要求：
　
１、关联查询是高频的
　　
２、数据容量是５TB及以上，对于分布式关系型数据库产品而言是能力范围之内的，例如：本人做过的快递物流行业是单表超过４０００亿行数据，且采用热璞数据库ＨｏｔＤＢ产品
　
３、水平分片表的数据分片字段　按业务需求来设计，不能增加数据架构设计难度、业务系统研发工作来且强迫全部表对象都按某一个字段来做数据分片。
　
建议如下：
　　
１、要求分布式关系型数据库厂商从产品的功能、性能两个维度满足　多表关联查询，数据库产品厂商应该实现CBO来优化执行计划，也即不能选择一个垃圾产品而去欺负研发人员。
　　
２、要求分布式关系型数据库厂商在数据分片维度提供功能实现数据分片类型、数据分片字段的自动推荐最佳实现，没有产品功能支撑就要求数据库产品厂商兜底服务。