MySQL版《一周一议》之mysql sharding方案分享（积分已转账-2012-12-19）

iask

回复 17# pandorabag

M1:
auto_increment_increment = 2
auto_increment_increment = 1

M2:
auto_increment_increment = 2
auto_increment_increment = 2
   

G8bao7

谢谢lz和同学们的分享，支持一下！

鉴于自己目前公司业务数据量比较小，虽然也进行了简单sharding(ms)，但由于数据量远不够形成压力，希望有同学能分享下实际业务sharding碰到的问题

bellszhu

不太清楚sharding的概念。。。
sharding和散表的区别？？
因为我只散过表

chinafenghao

回复 23# bellszhu


参见一楼帖子的文章链接。

huzi1986

回复 17# pandorabag


目前所有使用双主的架构中，一般都使用 HA+MM，只有一个实例 同时提供写功能。


   

frogoscar

学习了，看了网上几篇东西才知道 sharding这个概念，落后了啊。之前只是用过数据库。。。。。。。

fanzhilin515

新手，混点分用用。
mysql不是很懂，mark下

zhangshengdong

现在是越来越懒了，我把个人认为的mysql sharding写一下。

1.Master(W/R)     单实例读写master服务器的时代
2.Master (W) + Slaves (R)   下一步，慢慢地就发展到了Mater和Slave的时代，因为单实例无法承载应用的所有请求。所以，把所有的write queries(INSERT/UPDATE/DELETE)
  给予master，把所有或者近乎所有的 read queries给予slave。
3.Vertical Partitioning （垂直拆分）

*继续往后发展之后，可能不只是读请求超过负载，就连写请求也会超过负载。
*当出现write-heavy applications时候，我们该怎么办？
*使用Vertical Partitioning,把一些重业务分离出来（按库分离或者按表分离）。分别单独放在一个服务器，分担读写分离的请求。分散Top Master的写请求

基于上述的架构，会碰到的瓶颈：
（1):become harder and harder
  (2): Lose some JOIN-functionality
  (3):  if table grew so rapidly ，so
   the performance of the host  wasn’t guranteed any more。
   怎么办？
   加更多的salve？
   买更贵的服务器？
   就算你怎么加，它都会hit limit。

4.当上述又得不到解决的时候，horizontal partitioning到来了。

   *前面讨论的瓶颈，以及后时代的web数据管理。基于上述的理论解决。而这个早在1996年多人大型游戏online（MMO (Massive Multiplayer Online) Games world）就已经开始积极使用。

    基于上图描述，根据上述的算法，针对一张photos表的分割，根据"%10”的算法，连接10台服务器的哪一台进行处理。（其实是有图片的，就是一个表根据"%10"的方法，分布到不同的服务器中），这个要从程序方面调用来解决了。
   


图我就不贴了，如果有兴趣的，我可以把ppt到时候贴出来。
   

zhangshengdong

多半做sharding都是用replication来做。拆库。拆表的话，应该跟应用层相关了。我个人认为的。

visician

好话题，关注