20120909分库

分库的实战及技巧。

分了以后，大部分的数据库特性都不能用了，代价过大，可能需要考虑其它替代方案。

 

分库shading

http://www.infoq.com/cn/articles/yupoo-partition-database/
http://www.infoq.com/cn/presentations/xzh-58-distributed-storage-architecture-practice
http://www.infoq.com/cn/news/2012/04/baidu-salon-25th-summary
http://v.youku.com/v_show/id_XNDEzMTc4NzQ4.html

技术的价值在于产品表现，而非技术本身。
产品的价值不 完全在于技术的表现。
更关注的产品目标，而不是关注技术深度。
我不是技术高手，但是很多技术高手做出来的东西不如我。

主从解决读写问题
横向拆分解决数据容量

拆分库，特别是拆分表带来的问题，导致很多反范式的设计
数据量，负载问题
关联查询，一致性问题、外键、触发器都不能用了。
解决办法（冗余、应用程序端检测
RAS(可靠、可用、可扩展)
ACID
sql2005分区只是解决io读写问题(分表)

减少读：replaction,memcached
减少写：写入内存，写入临时表，定时调度（线程、调度程序），
延迟写、合并写:减少写io,，读时考不考虑写的临时数据

memcached暂告一段落
msmq，客户端也需安装，队列的策略没有进一定明确，如果客户端失败，则临时保持在一个队列中，网络成功时则再发送
asp.net mvc

该关注的问题都关注了，存在的陷阱都处理了
你说的这些问题，有点妖怪，一般妖怪都是属于低级的错误。
分成一定的库是应差不多了，如果更多数据，就已招过当前数据库这种方式，很多数据库这种特性都用不了，没有什么作用了。
可替代方案有：hoodop，hbase，其它解决方案，而不要再在数据库上再转了。
个别数据量太大的，还可以临时解决一下，分得太多了，确实没必要采用数据库方案了。nosql,大数据量方案

 

=============================

replication

http://wenku.baidu.com/view/da21ddd73186bceb19e8bbe3.html

http://www.cnblogs.com/xupengnannan20070617/archive/2012/09/03/2668975.html