NewSQL供应商Clustrix公司技术项目管理副总裁Scott Sullivan对MySQL的局限性进行了一番阐释，并具体探讨了NewSQL数据库如何为用户带来新的替代方案。

 

　　如何判断业务规模超出MySQL应对能力

 

　　数据总量的迅猛增长促使我们争先恐后地寻求更理想的数据管理解决方案。大多数拥有庞大用户基础的企业可能早就已经发现仅凭单一数据库服务器根本无法管理所有应用程序—因此，如今最常见的解决方式在于同时使用多套令人困惑且高度复杂的数据管理系统。

 

　　大家可能已经在利用内存缓存MySQL服务器弹性集群处理读取slave，并借助各类由云提供的Web/应用程序农场应对查询应答任务。大家可能已经部署了跨地理分布的多主副本配置方案，旨在处理指向数据库的写入操作。又或者大家只是觉得调整只是时间问题，实施工作宜早不宜迟。

 

　　无论大家尚未着手、还是已经完成了上述全部工作，终有一天业务规模仍然会超出现有方案的解决能力—在大多数情况下，这一问题会出现在历史悠久的MySQL身上—因此我们需要进行设施扩张以满足当前或者今后的预期增长。但大家如何判断拓展的时机是否已经到来?

 

　　1. 流量峰值阶段延迟增加

 

　　如果大家的服务在常规时段运转良好，但在每天的峰值时段总会响应迟缓，这就是各位需要对资源或者结构作出转变的一大显著指标。

 

　　面对这类情况，很多技术团队会自然而然地将问题归咎于负载生成机制：添加索引、重写查询能够提高效率，并保证每页视图返回的结果更少等等—这些努力通常确实能带来更出色的用户体验。不过这还仅仅是正确解决方案中的1%。如果大家发现自己需要每天一次、周而复始地进行优化，那就说明应该通过添加额外的硬件资源推进一轮显著的容量升级了。

 

　　MySQL能够对当前的技术方案以及任何系统进行向上扩展，但在向外扩展方面却存在着局限。常见的MySQL平台向外扩展方式可谓多种多样，简单些的可以部署只读slave，复杂的方案则包括划分NoSQL架构或者卸下其中的一部分查询任务。任何一种解决办法都要求对应用程序的逻辑以及数据访问方式作出变更，有时候甚至需要改变我们的数据模型以及用户体验—而且这些变更无法快速完成，因此延迟高企的问题短时间内也就得不到解决。

 

　　包括ClustrixDB在内的各类NewSQL解决方案在设计上能够毫不费力地接入附加硬件资源，而且整个容量增加过程只涉及机架与服务器堆栈添加—具体来讲，无需应用程序变更、无需调整数据模型。作为一套关系型数据库，NewSQL承诺轻松将多台可用服务器进行集群化处理，从而突破当前单一实例硬件局限。

 

　　2. 报告与分析迟缓

 

　　最令数据库管理员头痛的任务，莫过于管理层希望在生产数据库中运行报告系统。这是因为生产数据库通常全天处于全速运行状态，所以根本没有余力额外完成统计服务运行状况所必需的沉重计算任务。在生产数据库中运行报告系统不仅需要耗费远超出正常水平的时间，同时也会令用户体验大打折扣。

 

　　数据库管理员们可能已经设置了一份专门用于分析及报告任务的生产副本(读取slave)。这台专用报告服务器中的数据可能由于复制延迟的存在而略微落后于生产流量，不过至少报告统计本身的处理速度能够得到保证。这像是公司为某位员工专门配备公务用车—如果目前暂时不需要，车辆将处于闲置与等待状态。但相比之下，将报告服务器用于处理用户请求，同时在必要时让其重新快速处理报告任务岂不更好?

 

　　NewSQL系统能够以动态方式将额外服务器整合成一套单一的数据库服务，这项功能在任何MySQL架构中都是不可能实现的。通过对NewSQL系统进行细化配置，大家的过剩容量不仅能够偶尔处理报告任务，同时也能在用户流量峰值阶段贡献自己的力量。

 

　　3. 定期与/或长期停机

 

　　MySQL系统已经发展成大型工作负载处理方案，这意味着其中往往存在大量潜在故障点。

 

　　我们可以以此为核心创建多个主或读取slave，这将同时提高使用成本与复杂程度。不过每一套数据库额外副本都相当于一个需要管理并保持同步的全新链接目标。每套副本都极易受到数据不一致性、后端故障或者软件、硬件问题的影响。另外，我们拥有的系统数量越大，任意时间段内遭遇停机问题的可能性也就越高。

 

　　每次发生故障都需要我们进行手动调查与恢复—或者利用技术团队开发出的自动化处理与恢复系统。

 

　　相比之下，NewSQL系统在设计思路上作为单一单元来运行。大家拥有一套需要管理的主数据库，另外在处于远程地理区域的数据中心内还另有一套辅助灾难恢复系统。无论大家的数据库服务器是由几台还是几十台服务器构成都没关系;从数据库管理员的角度出发，系统本身都是一个整体。硬件故障可以以自动化方式解决，这是因为系统会借助路由机制绕过无法正常使用的组件。

 

　　智能化NewSQL系统能够自我修复并恢复对额外硬件故障的容错能力，而且整个过程无需人为介入。有了这些主可用性功能与自我修复方案保驾护航，大家的向外扩展数据库能够顺利将停机时间从原本的数小时降低至数秒钟。

 

　　4. 高昂的部署成本

 

　　当大家的MySQL架构架构逐渐逼近单一实例服务器的局限，这时开发人员用于处理向外扩展问题所耗费的时间甚至会多于构建业务功能的时间。

 

　　最重要的是，我们针对请求所开发出的每一项新功能都需要考虑愈发复杂的MySQL构架，而无法仅仅面向最基本的SQL原则。原本简单的请求变得极为复杂。当开发人员需要把大量时间耗费在向外扩展数据库系统身上时，大家必须在两种处理方式之间作出选择：如果这种扩展方法能够帮助业务实现差异性，那么现有机制尚有存在价值;如若不然，我们应该考虑把这部分时间用在更能发挥价值的地方。

 

　　5. 购买各种不同类型的硬件

 

　　对单一实例MySQL数据库进行向上扩展只允许大家在现有商用硬件中进行挑选。我们当然可以在自己的系统中使用最为强大的CPU产品，或者采购一大堆扩展内存，但请记住—我们的主板接入能力是有限的，这才是最大的问题。

 

　　选择商用硬件之外的方案可算是缩小性能差距努力中的最后一种可行尝试。配备全闪存驱动器、512GB内存以及最高速处理器的顶级系统所带来的开支，足以帮助大家买下一整套商用系统集群—甚至还不止。

 

　　真正的向外扩展NewSQL解决方案在设计思路上优先考虑运行在价格低廉的商用硬件之上，而这类设备正是当前高性价比方案的典型代表。这样一来，大家的运营费用将始终保持可预测性，从而保证设施规模始终符合业务营收而非超出营收水平。