按照学习计划，本周学习主从模式+读写分离，sharding（分片）。
这部分内容我也是第一次接触，如果说的不完整，不准确的地方，还请哪位大牛点拨一二。
摘要：核心问题还是要缓解数据库读/写压力，保障服务的可用性（Availability）；对于数据一致性敏感的应用，
如何通过合理的架构保障一致性（Consistency）。策略分成两种：商业数据库e.g.Oracle，采用scaling-up的做法，
即通过升级单点的软硬件，控制读写压力，不仅运维成本高，关键是扩展性差（poor scalability）；scaling-out则
通过Mysql的工具和数据划分的策略，分布式的存储、备份、恢复数据，它需要解决的是JOIN操作和一致性的问题。
对于后者，不管是为了解决读压力而使用master-slave & memcache，还是为了解决写压力而使用垂直/水平分区，
本质上都是一种松耦合的架构思想。
1、单表单库。估计Ver1.0的是这种LAMP架构的底子。新浪微博的基本功能开发仅用时1周！
读/写/事务锁；单点故障；容灾备份...各种对性能和服务质量的枷锁。它确实简单，任何计算机
相关专业的人，都可以设计这样的数据库，但是往往使用一段时间后就会变得很慢很慢。
加索引(INDEX)可能会暂时缓解，但是他可控的数据记录数量级也就刚到亿级，而且对写请求的开销
远高于读请求。
2、Master-Slave：这里引入了服务器角色的分工。这样Master不必处理所有的读写请求。
对读请求集中的应用，读请求（SELECT)分散到各个Slaves上，而写请求（INSERT/UPDATE/DELETE）
则由Master集中处理。这里需要集中解决由于网络延迟，死锁，掉电等等引起的主从数据同步问题。
虽然并不是所有应用对要求实时结果，但是当遇到这种需求时，你就需要到Master上读最新数据，保障数据一致性。
尤其是引入memcache后，缓存一致性的问题需要慎重考虑。原则是：在承认网络延迟、操作延迟的前提下，
保障”最终一致“即可。同时对于写集中（write-heavy）的应用，Slaves的数据同步操作会更加密集，但是很低效。
3、垂直分区：根据应用功能，将关联度小，不需要JOIN操作的数据分散到独立的服务器上。
比如：用户的图片、博客、投票等等。通过冗余的分散一些重要的tables到相关节点上，JOIN操作依然
可用。此时全局还是只有一个Master。
4、当然类似2中的系统要求，可以再细分局部的M-S关系，整体上形成一种树形的结构。
但是没进行一次M-S配置都会使系统更难管理，可能丧失一部分JOIN的功能。而且
数据记录在各个表是不均衡的，会出现某个table巨大而且增长极快。
5、水平分区（Sharding）：上面的4种架构，终究还是单表模式，受制于“写”。
水平分区的思想(分库分表)最早出现在1996，突破读写瓶颈，现在依然是memcache的核心思想。
要部署Sharding主要是确定两个问题：（1）What：也就说要根据那个属性做分区，‘sharding/partitioning key’
（2）How：分区算法，‘sharding/partitioning scheme’。
同时还有一些经典的问题需要解决：（1）跨区查询（2）数据一致性（3）分区均衡...
当然也有不少解决方案e.g. MySQL Cluster, HiveDB
References：
Database Sharding at Netlog, with MySQL and PHP
How FriendFeed uses MySQL to store schema-less data
下一次学习key/value存储，schema-less，NOSQL