最近工作上经常接触MySQL，在进行数据分析处理时，如果条目数在百万以内，而且有已知的规律来划分结构，那么先用DB存储后再进行快速的梳理是最好不过的了。
在我看来的数据存放，以及DB的使用场景应该大致如下：
进程空间内存 –> 共享内存 –> DB –> 文件系统存储 –> 数据仓库（Matrix + DB/FS/SSD）
如果有经验的话，很快就可以明白，随着数据存储的左移，提取数据、运算数据所带来的开销也会逐步增大，例如：在程序内存和共享内存中的数据，可能1ms内就可以返回并开始计算，但是DB、文件存储系统中的数据可能将会需要10ms以上的时间来进行读取，数据结构拼装等操作。
对于以上的几项来说，当进行海里级数量的运算时的存储挑战，主要在于 ：
① 进程内存、共享内存：可能出现容量不足的情况，如果做成分部缓存，那么同步查询的需求也会出现。
② DB、文件系统：如何快速的索引及寻址，机械硬盘的IO效率等问题。
③ 数据仓库： 基础架构的支撑能力，例如网络上联带宽，分布式中的同步与运算命令的优化。
当然，挑战都有解决思路，云计算中有一个的CAP理论（一致性，可用性，分区容错性、三者只能取其二，详细STFG），但是对与注重实用性的程序员来说，死背这个理论是没用的，写PPT的时候可以用，嗯。
简单的说，以上几点个内容的缺陷都可以通过一定程度其他方面的牺牲来弥补，例如：对共享内存缓存的分部存储必然会带来同步查询的问题，对此需要额外维护一张较复杂的索引表来提供索引，并且增加数据传递的复杂性，来保持不同部分的缓存都能达到准确。
而DB、文件系统的瓶颈解决的思路类似，即提供更快的cache作为索引，同时将落地的数据进行分块优化，将整列模块化进行维护等。
最后关于云计算中的数据存储和运算，可以考虑优化网络架构，（增加上联带宽，万兆、四万兆端口的使用），此外的就是对更多部分的选择的限制和牺牲，来降低复杂度了。
因为最后一块云计算不是非常掌握，也就不卖水了，不过从方法上看，个人比较欣赏亚马逊的一致性哈希的思路，即从自己的业务角度考虑来进行暴力优化，达到效果即可，没必要非要抄Google或者其他有名气的项目，当然参考是OK的。
—-
早上闲着写了一篇，不知道写的如何，后续可能会开始逐步介绍《高性能MySQL》中的一些内容和自己的想法，如果不才哪里写的不好，或者大家想关注哪一方面的内容，都可以告知到我，如果我有掌握就会抽时间写一些的。