乱谈高并发、大吞吐量、海量数据处理的性能问题的背后

事实上我并没有做过任何大型的项目，但是高并发、大数据（此处指大量的数据，而不是在大量数据的基础上进行分析）、性能、缓存等字眼现在更频繁的被提出，甚至有的网友在面试普通程序员的时候也会被询问有关的问题，而且他们还郑重其事的咨询我的意见，还好这只是通过网络的问答，还是比较容易混过去的，不过我还是不得不认真思考一下，下次再有人问我我就可以直接发链接了。

防误导声明：本文内容纯属臆测，作者没有相关的实际经验。文章仅代表笔者对此类问题的思考角度而不是经验之谈。

我对数据本身的看法

既然要处理数据，那么对于数据应该首先有一个认识，同样，这只代表我自己的观点。

核心数据与衍生数据

有经验的程序员应该都知道，开发初期的一个小问题在后期可能演化为灾难，而我认为核心数据与衍生数据的识别就属于这种小问题。
什么是核心数据呢？该数据是基于外部输入的，除此之外我们没有其他手段获取。预定义常量也属于核心数据的一种。
那么相应的，衍生数据则是可以被推导出来的，是在核心数据的基础上通过一定的规则计算而来。
例如在订单信息中，用户id、各种时间戳、商品id、数量、税率（预定义的）就是核心数据，而小计、税金、订单总额之类的数据就属于衍生数据。

有效数据与垃圾数据

如果核心数据与衍生数据是对数据的绝对分类，那么有效数据与垃圾数据则是对数据的相对分类。比如对于会计来说，只有成交的订单才是有效数据，而相对的，对于销售人员未成交的订单可能对他们来说更有用。

数据的敏捷

“敏捷”也是被经常提到的，简单的说就是尽快的解决目前遇到的问题。由此，我认为数据也需要敏捷，一方面避免收集无用的核心数据，但是更重要的一方面是不要产生衍生的垃圾数据。

更好的写入

根据前述，我认为最佳的写入方式应该是优先写入核心数据，然后在恰当的时间计算并写入衍生数据，甚至于会多次迭代“计算并写入衍生数据”这一步，比如衍生数据的衍生数据。

更快的读出

单纯的读出只受限于计算机的性能，所以实际上此处我们更关注的是如何找到需要的东西。没有索引肯定是最慢的，就像去垃圾堆里面找回丢失的铅笔；而大型超市就要好很多，但是你要先找到文教用品区；在档案室找档案也没有预想的复杂，先找到档案室，再找到其中一个柜子，具体到一个格，通常里面不会超过100份备选档案。
由此可见，想更快的查找就需要管理更多的索引，而更多的索引必然消耗更多的存储空间（当然写入索引这种衍生数据同样也需要时间）。
最终，我很无奈的发现，查询速度已经在写入数据的时候规定好了，好吧，问题得到简化，我们只要考虑如何写数据就足够了。

我觉得我们早就Out了

写到这里我突然发现我们是在研究一种很古老的东西，而不是什么潮流，毕竟Google、Yahoo、百度已经运行这么多年了，我们在讨论的这些问题就是搜索引擎的核心部分。

科技在进步，但逻辑永存

以上都是逻辑上的东西，即便我猜错了某些细节也不重要，因为必然有一种正确的逻辑在支持着这一切。对速度的追求驱动了科技的进步，科技的进步造就了更快的介质，磁带、磁盘、硬盘、内存、高速缓存，逻辑没有变，但是当我们使用了更快的介质，速度瓶颈就被打破一次。

结论

标题提到的种种无非是把存储介质由硬盘迁移到内存或其它设备，区别就是硬盘是由操作系统控制的，而直接操作内存或其它设备时我们需要使用特定的程序，但是最终数据库软件本身会固化此类程序。一方面我们会见证这个过程，另一方面我们也在黎明前的黑暗中挣扎。

作者猜想——MD5的价值

一提到MD5很多人的印象就是32位的16进制编码，然而事实上这个用的最普遍，MD5算法也可以生成更多位的哈希码，比如128位。
在上文中提到档案管理的时候我突然想到这个问题，一个格子里面放多少档案更合适呢？基于迭代算法，按照十进制的方式，一个格子里面放10份，100份，1000份？模拟一下。
1374388：1号档案楼3楼7室4号3行8列里面的第8份档案，也就是有10个楼，每楼10层，每层10室，每室10柜，每柜有10x10个档案格，最多存放1亿份档案。
18327442309981：18号档案楼32楼74室42柜30行99列的第81份档案。
1000份的就省略了吧。不过感觉上一个格10份略少了一点，100份明显太多了。
如果是2进制呢？一个档案格里面只有两份档案，档案编号10100010001，感觉上这样分类比不分类好像也快不了多少。
那么16进制呢？感觉上比较合适。那么MD5呢？
作者猜想：将数据进行MD5编码，并以此作为数据唯一编号，基于16进制算法创建16叉树模型，对于32位的MD5码其寻址时间区间为32~512(即32*16)
注：作者野路子出身，随便乱想，虽然兴高采烈的写出来但事实上完全可能是孤陋寡闻和坐井观天的原因，欢迎您的任何意见，只要语言文明就好。