关于大型网站技术演进的思考（七）一存储的瓶颈（7）本文开篇提个问题给大家,关系数据库的瓶颈有哪些？我想有些朋友看到这个问题肯定会说出自己平时开发中碰到了一个跟数据库有关的什么什么问题，然后如何解决的等等，这样的答案没问题,但是却没有代表性,如果出现了f新的存储瓶颈问题，你在那个场景的处理经验可以套用在这个新问题上吗？这个真的很难说。其实不管什么样的问题场景最后解决它都要落实到数据库的话那么这个问题场景一定是击中了数据库的某个痛点,那么我前面的六篇文章里那些手段到底是在解决数据库的那些痛点,下面我总结下，具体如下：痛点一:数据库的连接数不够用了。换句话说就是在同一个时间内,要求和数据库建立连接的请求超出了数据库所允许的最大连接数如果我们对超出的连接数没有进行有效的控制让它们直接落到了数据库上,那么就有可能会让数据库不堪重负,那么我们就得要分散这些连接,或者让请求^队。痛点二:对于数据库表的操作启E两种一种是写操作,一种是读操作,在现实场景下很难出现读写都成问题的事情，往往是其中一种表的操作出现了瓶颈问题所引起的，由于读和写都是操作同一个介质返就导致如果我们不对介质进行拆分去单独解决读的问题或者写的问题会让问题变的复杂化,最后很难从根本上解决问题。痛点三:实时计算和海量数据的矛盾。本系列讲存储瓶颈问题其实有一个范畴的,那就是本系列讲到的手段都是在使用关系数据库来完成实时计算的业务场景，而现实中，数据库里表的数据都会随着时间推移而不断增长,当表的数据超出了一定规模后，受制于计算机硬盘、内存以及CPU本身的能力，我们很难完成对这些数据的实时处理,因此我们就必须要采取新的手段解决这些问题。我今天之所以总结下这三个痛点，主要是为了告诉大家当我们面对存储瓶颈问题时候，我们要I巴问题最终落实到这个问题到底是因为触碰到了数据库的那些痛点，这样回过头来再看我前面说到的技术手段，我就会知道该用什么手段来解决问题了。好了，多余的话就说到这里，下面开始本篇的主要内容了。首先给大伙看一张有趣的漫画,如下图所示:身为程序员的我看到这个漫画感到很沮丧，因为我们被机器打败了。但是这个漫画同时提醒了做软件的程序员，软件的性能其实和硬件有着不可分割的关系，也许我们碰©I的存储问题不一定是由我们的程序产生的，而是因为好的炮弹装进了一个老旧过时的大炮里，最后当然我们会感到炮弹的威力没有达到我彳I'啲预期。除此之外了，也有可能我们的程序设计本身没有有效的利用好已有的资源所以在前文里我提到如果我彳门知道存储的瓶颈问题将会是网站首先发生问题的地方那么在数据库建模时候我们要尽量减轻数据库的计算功能只保留数据库最基本的计算功能,而复杂的计算功能交由数据访问层完成，这其实是为解决瓶颈问题打下了一个良好的基础。最后我想强调一点，作为软件工程师经常会不自觉地忽视硬件对程序性能的影响，因此在设计方案时候考察下硬件和问题场景的关系或许能开拓我们解决问题的思路。上面的问题按本篇开篇的痛点总结的思路总结下的话，那么就是如下：U0中心优化选择‘羈这饨化如太低了.还不如我伽一种新的分布式乞件磁把读砸於多台机器上，能快个几十倍.眼下这愣况.采用更好昵件所花踽.比团队6个月的工资少得多作为理序员.你会面怯2弁选择可以花6个月写个复杂程序把单陽统变成分右的.把硬盘换成SSD.寻道时间1ms以下.效率提蔑上臣倍问题早孵决了你起玛得花6个月.还得増加许多台服务器的预算1也可以休假6个月睡大觉.因为等你一觉醒来.让慟帥更题件已经出现了.•・・・・痛点四：当数据库所在服务器的硬件有很大提升时候，我们可以优先考虑是否可以通过提升硬件性能的手段来提升数据库的性能。在本系列的第一篇里，我讲到根据http无状态的特点，我们可以通过剥离web服务器的状态性主要是session的功能，那么当网站负载增大我们可以通过增加web服务器的方式扩容网站的并发能力。其实不管是读写分离方案，垂直拆分方案还是水平拆分方案细细体会下，它们也跟水平扩展web服务的方式有类似之处,这个类似之处也就是通过增加新的服务来扩展整个存储的性能,那么新的问题来了,前面的三...