联合MySQL Proxy 和MySQL Cluster，构建高性能数据库

偷瓜的贼

　　[原文：http://blog.iyunv.com/wengyupeng/archive/2009/08/08/4425040.aspx]
　　
　　原文：http://blogs.mysql.com/kaj/2007/12/10/combining-mysql-proxy-with-mysql-cluster/
　　       不久前，我和Stewart Smith, Vinay Joosery, Monty Taylor 以及其他的mysql使用者（他们比我更熟悉MySQL Cluster ）展开了一次讨论，探讨的主题是：在不更改应用的情况下，使用MySQL Proxy来消除MySQL Cluster 的全表扫描。
　　      讨论源自我问Stewart的一个问题：扩展MySQL Cluster使用用户数量的瓶颈是什么？他回答：瓶颈可能来自Join和其他的select可能需要扫描数据库的大部分。这里有其他更快的存储引擎，比如 MyISAM and InnoDB。
http://kaj.arno.fi/ProxyCluster1.png
　　从一个简单的图来看——如图1，应用和MySQL Cluster通过sql交互，同时得到一些服务的响应。这种观点可以图1 中带有双箭头的“sql”来表示。“sql”主要包括下面几部分：
　　UPDATE, INSERT, DELETE 语句，轻量级的，经常就影响几行——在图2中用蓝色的单向箭头表示
　　                      简单的SELECT语句，也是轻量级的，这种查询通常使用索引来返回几行——在图2中用黑色的双向箭头表示
　　                      复杂的SELECT语句，比如常见的使用" select *"  ，但这种语句不是使用索引，而且经常会返回多行数据——这     种情况在图2中用带虚线的双向箭头（注意返回段的两个箭头代表返回多数据）表示
http://kaj.arno.fi/ProxyCluster2.png
　　
　　图2并没有在应用结构上和图1产生变化，只是更加的细粒度一点。现在我们来看普通的MySQL Server （带有MyISAM 或 InnoDB引擎）能够更快的发送复杂的查询请求。在图3中，我们能看到：
　　
　　 http://kaj.arno.fi/ProxyCluster3.png
　　             引入了复制（复制 MySQL Cluster到普通的MySQL Server）
             将复杂的查询应用导向MySQL Server，而不是 MySQL Cluster
　　      这样过程就有些复杂了，我们不仅要建立数据库的复制，而且重新布局应用，使各种查询到适合处理它的数据库服务上。
http://kaj.arno.fi/ProxyCluster4.png
　　
       现在，在来看看MySQL Proxy：
　　       使用LUA（Lua 是一个小巧的脚本语言，该语言的设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。它的主页是 www.lua.org，Lua 最著名的应用是在暴雪公司的网络游戏WOW中），MySQL Proxy能减轻我们应用的复杂性，比如，根据不同的sql类型，可以将不用的应用分配到不同的数据库服务器。通过MySQL Proxy 来解析阻塞，把应用导向适合的数据库服务器。这里应用没有改动，这个结构变化的最显著的是有了一个叫“sql”的双向箭头的线。至于我们说到的不同的 sql类型留给 MySQL Proxy去辨别。
       MySQL Proxy也具有均衡各种 MySQL服务（具有mysql复制的子机）查询的任务。
http://kaj.arno.fi/ProxyCluster5.png
      图5清晰的这里描述的复杂结构，但是它也代表了数据库服务最高的伸缩度。
　　      上面提到的都是用的目前最新版本的MySQL Cluster 和 MySQL Server,MySQL Proxy。
  
MySQL Proxy: http://forge.mysql.com/wiki/MySQL_Proxy
MySQL Cluster: http://www.mysql.com/products/database/cluster/
MySQL Replication: http://dev.mysql.com/doc/refman/5.0/en/replication.html
              　　原文：
　　A while ago, I had a discussion with Stewart Smith, Vinay Joosery, Monty Taylor and a number of other MySQLers who know much more about MySQL Cluster than I do. The result is a model for using MySQL Proxy to offload MySQL Cluster from doing Table Scans, without touching the application.
http://kaj.arno.fi/ProxyCluster1.png
　　The discussion started from me asking Stewart about the largest road block for expanding the number of use cases for MySQL Cluster. “Oh, that would probably be doing JOINs and other SELECTs requiring the scanning of large parts of the database”, he replied. “There, other storage engines are faster, such as MyISAM and InnoDB.”
　　In a very simple view, the application talks SQL with MySQL Cluster, and gets responses.
http://kaj.arno.fi/ProxyCluster2.png
　　Stewart’s insight can be refined into the first simplistic diagram by adding the recognition that “SQL” can consist of

• UPDATE, INSERT, DELETE statements (very light, usually invidual rows affected) — unidirectional blue arrow in the diagram below
  
• Simple SELECT statements (also very light, defined as SELECTs that use indices and return invidual rows) — bidirectional black arrow
  
• Complex SELECT statements (could be as easy as “SELECT *”, but defined as those not easily using indices and usually returning multiple rows) — dashed arrows having two arrowheads to show that plenty of data is being returned
  

　　This second figure doesn’t depict any change in application architecture from the first figure; it just shows a more granular view.
　　Now, enter the insight that plain MySQL Server (with MyISAM or InnoDB) can deliver the complex SELECTs faster.
http://kaj.arno.fi/ProxyCluster3.png
　　In the new architecture represented by the above picture, we scale the application by

• introducing Replication (replicating MySQL Cluster to plain MySQL Server)
  
• changing the application to direct the complex SELECTs to MySQL Server instead of MySQL Cluster
  

　　This complicates life. Not only do we need to set up replication. We also need to touch the application all over the place, to direct queries to the appropriate server.
　　Now, enter MySQL Proxy.
http://kaj.arno.fi/ProxyCluster4.png
　　Using LUA scripts, MySQL Proxy can relieve us of the second complication, i.e. having to change the application to point to different MySQL Servers depending on the type of the SQL. Let MySQL Proxy parse the traffic and direct it to the appropriate server! The application is left untouched, and the topmost part of the picture again has a simple bidirectional arrow saying “SQL”. The distinction of what type of SQL we’re talking about is left to MySQL Proxy.
　　MySQL Proxy can also be assigned to load balancing the queries to a number of MySQL Replication Slaves.
http://kaj.arno.fi/ProxyCluster5.png
　　This picture clearly is the most complex architecture depicted here, but also represents the highest level of scaling.
　　All of the above can be done using current versions of MySQL Cluster and MySQL Server, and the MySQL Proxy.
　　Sources:

• MySQL Proxy: http://forge.mysql.com/wiki/MySQL_Proxy
  
• MySQL Cluster: http://www.mysql.com/products/database/cluster/
  
• MySQL Replication: http://dev.mysql.com/doc/refman/5.0/en/replication.html