数据库事务复制(读写分离)设计的一点经验

主要是网站读写容易死锁, 为了快而建立索引,索引多了更新又慢,而且容易死锁, 两难题, 在这个背景下, 准备使用sql server的事务复制(我试了推送和请求2种订阅方式)对数据库进行读写分离, 但是数据库结构和表结构设计不理想情况下, 读写分离基本不可能实现. 在我的实验中, 要实现读写分离, 保证稳定性, 最好能满足以下一些特性, 否则容易失败

1.数据库结构不能经常变动; 否则发布源过多,或者初始化过于频繁;

2.单表数据量不能过多(我有几张几百万记录的表,还有2张千万级别的表,不过没有参与发布复制, 但是备份初始化还需要将数据备份过去),插入和更新性能不能太差(索引,磁盘IO等情况)

3.不能有大量数据更新的操作高峰期,最好是数据平稳操作, 容易更新事务(我用的是事务复制瓶颈)性能瓶颈,我最多积累的更新事务几十万个,最后频繁报性能警告提示,导致数据不同步; 因为每天定时任务要进行数据统计更新, 可能会在某时刻Update几十万甚至百万记录, 这个时候性能瓶颈很容易产生.

4.数据库和表设计上还是需要开始就考虑各种性能(横向扩展方式), 如果先天设计不足不要进行读写分离;

5.大数据表和数据量在初始化时候就是一个恶梦;每次不同步时候进行备份初始化,备份/拷贝/还原,就得几个小时; 其它方式更不用说了.

设计上先天性不足是重中之重. 希望高手指教.