闲话MySQL (一)

    最近工作上经常接触MySQL,在进行数据分析处理时,如果条目数在百万以内,而且有已知的规律来划分结构,那么先用DB存储后再进行快速的梳理是最好不过的了。

    在我看来的数据存放,以及DB的使用场景应该大致如下:

          进程空间内存 –> 共享内存 –> DB –> 文件系统存储 –> 数据仓库(Matrix + DB/FS/SSD)

 

    如果有经验的话,很快就可以明白,随着数据存储的左移,提取数据、运算数据所带来的开销也会逐步增大,例如:在程序内存和共享内存中的数据,可能1ms内就可以返回并开始计算,但是DB、文件存储系统中的数据可能将会需要10ms以上的时间来进行读取,数据结构拼装等操作。

 

     对于以上的几项来说,当进行海里级数量的运算时的存储挑战,主要在于 :

        ① 进程内存、共享内存:可能出现容量不足的情况,如果做成分部缓存,那么同步查询的需求也会出现。

        ② DB、文件系统:如何快速的索引及寻址,机械硬盘的IO效率等问题。

        ③ 数据仓库: 基础架构的支撑能力,例如网络上联带宽,分布式中的同步与运算命令的优化。

 

    当然,挑战都有解决思路,云计算中有一个的CAP理论(一致性,可用性,分区容错性、三者只能取其二,详细STFG),但是对与注重实用性的程序员来说,死背这个理论是没用的,写PPT的时候可以用,嗯。

    简单的说,以上几点个内容的缺陷都可以通过一定程度其他方面的牺牲来弥补,例如:对共享内存缓存的分部存储必然会带来同步查询的问题,对此需要额外维护一张较复杂的索引表来提供索引,并且增加数据传递的复杂性,来保持不同部分的缓存都能达到准确。

    而DB、文件系统的瓶颈解决的思路类似,即提供更快的cache作为索引,同时将落地的数据进行分块优化,将整列模块化进行维护等。

    最后关于云计算中的数据存储和运算,可以考虑优化网络架构,(增加上联带宽,万兆、四万兆端口的使用),此外的就是对更多部分的选择的限制和牺牲,来降低复杂度了。

    因为最后一块云计算不是非常掌握,也就不卖水了,不过从方法上看,个人比较欣赏亚马逊的一致性哈希的思路,即从自己的业务角度考虑来进行暴力优化,达到效果即可,没必要非要抄Google或者其他有名气的项目,当然参考是OK的。

—-

    早上闲着写了一篇,不知道写的如何,后续可能会开始逐步介绍《高性能MySQL》中的一些内容和自己的想法,如果不才哪里写的不好,或者大家想关注哪一方面的内容,都可以告知到我,如果我有掌握就会抽时间写一些的。

此条目发表在网络分类目录,贴了, 标签。将固定链接加入收藏夹。

发表评论

邮箱地址不会被公开。 必填项已用*标注