评注：这当中考虑有三：
1. 这是一个实现项目，也就是说算法，架构，一切都在实验中，需要验证，更需要时间，所以不可能是投资型的硬件，必然是些低成本的实验品。
2. 运用linux和配合自己的完全掌控硬件的算法，使得基本能运行linux最低版本的硬件可以起死回生。如果单一从功能上说，spider部分没有计算部分要求的硬件苛刻，而抓取部分需要很多CPU和存储体，需要漫长的等待时间，抓取时间比较长，所以在spider方面，数量更要胜过质量和速度，这个判断是对的。再者是功耗，低挡次的机器耗电总是比较小的。
3. 财力不足以将资金先放在硬件部分，而且因为数量众多，不能依靠天使资金投资硬件，而且实验还要进行很长时间，要聘请人员，需要很多开发的费用。而且当时来说，只是一个思路，面临的问题太多，结果是未知的。
4. 负载和平衡问题，机器多，分布，就意味着单体的运行状态不太影响到整体的进度。在那个年代，这样的电脑其实已经算不错了。当时在国内来讲，硬件是非常昂贵的。价格问题也是采取自己拼装的必然决定因素。
5. 处理逻辑上需要太多步骤的计算，天然决定不可能使用少数性能良好的机器来完成，因为一些机器一直在抓取，一些机器一直在抽取，一些机器一直在索引，一些机器一直在计算相关度。这是个逻辑意义上的并行，瓶颈是单体CPU数量的问题。而且就算一台机器处理能力再强，在面对这样特殊的处理方式情况下，采用数量少的高性能机器方案也是不行的，多线程和工作时间片切换是不可行的。我们知道在繁重的计算下，整个机器，几乎无法频繁切换，就算能，效果也不行。
6. 结论是：需要数量多，分布式，每台电脑不需要很高性能。所以，这样的特性决定这样的方案实现并证明可行，并延用至今。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Google 刚满七周岁，但俨然已经是一个巨人了，当 Sergey Brin 和 Larry Page 七年前在后院车库里创建Google的时候肯定没想到他们正在创造 IT 界的又一个神话。
来看看Google当年起家时的家当：
这是当年Google的后台服务器，300MHz Pentium II，512M内存，99G硬盘，呵呵，还不如偶的烂机子呢 ;-)
IBM 捐赠的 F50 IBM RS6000，4个处理器，512M内存，89G的硬盘。
左侧39G，右侧是64G硬盘，连接在sun Ultra II 上
也是 IBM 捐赠的89G 存储器
双 200MHz处理器，256M内存的sun Ultra II，Backrub（Google当时的名字）就是从这里向世界伸出它的触角的
自制的 SCSI 磁盘阵列，100G
看这乱劲，想象不出一根线里传输着多少信息...
这就是 Google巨人诞生的产房。
