【简记】大规模Web开发技术（第四章）

第四章主题：数据库的横向扩展策略——以分布式为基础的MySQL应用

最近也出现了很多NoSQL 等其他实现，但几年之内， LA如1p (Linux + Apache +MySQL + Perl )的Web 服务的标准数据存储仍会是MySQL 。（2010年说的话）

第11课：正确使用索引——分布式MySQL应用的大前提

从页面缓存的角度：之前有提到一个页面缓存在4kb左右，b树每个节点中孩子的数目和树的属性值（度数）密切相关，所以可以做到将一个节点的数据都放在一个页面缓存内，减少从磁盘中I/O的次数。而普通的二叉树做不到这点。

MySQL中使用索引有部分限制（后期专题补充吧）

第12课：MySQL的分布式——以扩展为前提的系统设计

MySQL的 replication功能

这样slave 就是master 的replica (复制品〉。这样就可以准备多台内容相同的服务器。

此时，应用程序实现上应当只把select 等读取类的查询发送给负载均衡器，而更新查询应当直接发给master。要是在slave上执行更新查询， slave 和master 的内容就无法同步。MySQL会检测到master 和slave 之间的内容差异，并停止replication 。很容易想象，这会导致系统故障。

此架构的特征：master无法实现分布式；由于该公司web应用程序（博客）的性质，读取的操作比写入的操作大很多，所以master的压力相对较小。

如果更新操作比较频繁，解决办法：

1.使用表分割技术

2.不使用关系型数据库，采用如key-value这种存储结构（显示视频播放次数的地方，更新操作太频繁，不适宜使用关系型数据库）

第13课：MySQL的横向扩展和Partitioning

MySQL 的横向扩展策略
Q：数据能放进内存吗?
A：YES
-放进内存
B： NO
·增加内存
·若无法增加内存就用Partitioning

MySQL 并没有将位于不同服务器上的表JOIN 起来的功能。

注意：想要多表查询使用JOIN操作，则表不可被分配到不同的数据库服务器中。

下图中，想对tag和entry表进行联合查询，只能分多步进行。所以，如果查询操作中使用了太多的JOIN操作，会影响后期的分库。

分两步查询：

Partitioning的代价：

Partition的好处：降低负载，增加局部性，以提高缓存的效果。

代价：运维变复杂；故障率上升；

实现冗余化至少需要几台服务器？（一般为4台）

像3台一组， master 1 台+slave 2 台的话，假设某台slave发生故障。但另一台slave 仍在正常运行，就会想到"不错，太好了。赶快恢复吧"，而准备好新的数据库服务器。接下来就得复制数据了。但要复制数据，就必须把剩下的那台slave停机。这样服务就停止了。停止master就没法写入，停止slave就没法读取，所以不停止服务就无法恢复。