在上两篇文章中,我重点说明了在分布式数据库中分片键字段的选择问题,但是仅仅限在特定的表独立操作的情况下,未考虑多表关联的问题。在分布式数据库中,经常遇到需要进行多表关联的操作问题。如存在多表关联操作,务必规避在分布式数据库中的跨库操作场景,争取降低处理时延,确保整体事务的处理效能,降低分布式数据库集群内部的网络开销。
首先,要熟悉各表的逻辑关系、字段设置以及关联条件等等;如果多表关联的条件,都是非常一致的,就是某个或者某几个特定的字段,可以将字段设定为分片键,如此所有的关联操作基本上都是都是在特定的数据库内部完成的,基本上不会产生跨库操作的。最终都是在路由管理节点汇总处理完毕后返回给请求方。
其次,在分布式数据库集群中,如存在多个字段作为关联条件的问题,如此可能无法确定多个统一的分片键。在此情况下,要确定涉及的各个表的记录数和数量规模。要把大表优先进行分片存储或者使用相同字段作为关联条件的多个分片表进行优先分片,至于其他的表确定记录数是否较小,如果都是相对比较小的,可以设定为克隆表,即每个数据节点都会保存相同的业务数据。如此条件下,进行关联查询,直接在节点内部进行操作,避免出现了跨库的操作。
然后,如果在特定的业务场景中,存在极端场景:关联的表较多,关联字段更是数不胜数的情况,在这种情况下,建议就采用集中数据库进行处理,不用分布式数据库,即使采用了分布式数据库,其体现的查询耗时以及性能未必达到预期。实事求是来讲,在相同的硬件配置和网络条件下,对于相同的业务数据模型,集中式数据库的性能和耗时比分布式集群中单个库的性能和耗时要高,但是通常会不及整个分布式集群的性能和耗时,毕竟这两种部署方式追求的目标是不同的。
最后,关于分布式数据库,可以笼统的来讲,就是通过分片键将原来集中在一起的数据库,按照分片键将数据拆分到多个不同的数据节点中,然后在进行数据处理时,SQL语句中携带着分片键字段来,将请求下沉到每个数据节点进行集中处理,然后将符合条件的数据再进行二次加工处理。
以上是自己的心得,分享给大家,如有不妥之处,大家及时沟通。