sharding-sphere之分库分表算法及策略解释

背景
        为解决关系型数据库面对海量数据由于数据量过大而导致的性能问题时，将数据进行分片是行之有效的解决方案，而将集中于单一节点的数据拆分并分别存储到多个数据库或表，称为分库分表。 分库可以有效分散高并发量，分表虽然无法缓解并发量，但仅跨表仍然可以使用数据库原生的ACID事务。而一旦跨库，涉及到事务的问题就会变得无比复杂。
        分库分表一般有两种拆分方式。按照业务拆分的方式称为垂直拆分。
        例如，根据业务的不同将订单库拆成两个相同的数据库，称之为垂直拆分。垂直拆分可以缓解数据量和访问量带来的问题，但无法根治，如果垂直拆分之后的订单数量依然超过单节点所能承载的阈值，则需要水平拆分来进一步处理。 将一个表中的数据按照一定的业务规则拆分至不同表和数据库中，称之为水平拆分。例如，原来的订单数据在order_ds.t_order表中，如果按照订单的user_id将订单拆分为2个库，再按照订单的order_id在每个库中分成4个表，那么拆分的结果则是order_ds_0.t_order_0，order_ds_0.t_order_1，order_ds_0.t_order_2，order_ds_0.t_order_3，order_ds_1.t_order_0，order_ds_1.t_order_1，order_ds_1.t_order_2，order_ds_1.t_order_3。 这只是简单的水平拆分案例，在实际使用中，将库和表拆分的更加分散也是十分常见的。
        虽然数据分片解决了性能问题，但也额外的引入了其他问题。面对如此散乱的分库分表之后的数据，应用开发和运维人员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要知道什么样的数据需要从哪个具体的数据库的分表中去