数据库瓶颈阻碍业务的持续发展
单一服务中心的数据访问压力也必然很快会达到单机数据库的承载上限
- 首先实施的是数据库的读写分离
- 采用水平分区的方式对数据进行拆分
在很多实际的业务场景中，不可避免会出现跨库的表join、事务操作，以及数据的统计、排序等情况，而且数据进行了拆分后，对于数据库的运维管控也提出了更高的要求。
数据库分库分表的实践
分布式数据层框架TDDL，针对分库分表场景，提供了对各种业务场景的支持更加完善
三层数据源每层都按JDBC规范实现，使得对前端应用没有任何代码侵入。
·Matrix层（TDataSource）实现分库分表逻辑，底下持有多个GroupDs实例。
·Group层（TGroupDataSource）实现数据库的主备/读写分离逻辑，底下持有多个AtomDs实例。
·Atom层（TAtomDataSource）实现数据库连接（ip、port、password、connec-tionProperties）等信息的动态推送，持有原子的数据源。
实现思路是多数据库执行之后数据进行汇集处理，返回调用者。数据尽可能平均拆分
尽量减少事务边界
事务边界即是指单个SQL语句在后端数据库上同时执行的数量，事务边界的数量越大，会给系统带来以下弊端：
系统的锁冲突概率越高
系统越难以扩展
整体性能越低
- 异构索引表尽量降低全表扫描频率
- 应用可能会按照多个维度创建多个异构索引表，如果数据在异构索引表中全复制的，会带来大量的数据冗余，从而增加不少数据库存储成本。
- 我们还是建议采用仅仅做异构索引表，而不是数据全复制，同时采用两次SQL请求的方式解决出现全表扫描的问题。
异步索引创建
- 一种是从数据库层采用数据复制的方式实现；
- 另一种是在应用层实现，在这一层实现异构索引数据的创建，就必然会带来分布式事务的问题。
- 阿里巴巴内部目前采用的是在数据库层实现异构索引的方式.本质上是一个基于MySQL的实时数据复制框架
- 将多条件频繁查询引入搜索引擎平台
- 简单就是美
如果在“尽量减小事务边界”与“数据尽可能平均拆分”两个原则间发生了冲突，那么请选择“数据尽可能平均拆分”作为优先考虑原则,因为事务边界的问题相对来说更好解决
