分库的实战及技巧。
分了以后,大部分的数据库特性都不能用了,代价过大,可能需要考虑其它替代方案。
分库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