所谓设计模式和架构

  大致看了下关于bigtable和mapreduce的东西.
  
  想想,其实是google对于搜索引擎数据结构的一个解决方案吧.
  广泛一点说,是对于面向内容的分类的解决方案的.

  对于搜索引擎来说,主要有两个基础的数据:
  一是原始的抓取对象,表现为网页内容.
  二是对原始材料的分类信息,表现为关键字.

  bigtable对于这样的数据的处理,引入的是column family的概念.以传统的RDBMS理解的话,就是在url 和content列之后,有了一个不定数目的列数.

  仔细想想,换个方式理解,其实更简单.
  对于column family,更喜欢将其理解为tagging.

  因为搜索引擎本身承担着两种功能.
  抓取和分析.
  
  得到content之后,只要对其打上相应的tag便行了.

  如果要以RDBMS实现的话,便是简单地对每个关键字建立个表,然后指向相应的content内容便可以.
  而要依据诸多关键字定位page的话,也就是所谓的map reduce.

  先分类,在处理.
  也就是所谓的先map,然后再reduce.

  这其实就是分类处理的思想.

  而map很大程度上,跟集合有着天然的血缘关系.
  而搜索的目的就是在集合里找到特定的子集.
  于是,map > reduce > map > reduce...

  于是,纯粹从思想的角度考虑,bigtable和mapreduce不过是google对于搜索引擎需求的一个建模描述,或者说是基于内容个tagging技术.
  
  话说回来,有时候,所谓的架构或者模型确实是建立在需求之上的.

  软件产品脱胎于需求.
  而产品的架构,虽然某种程度上说跟需求无关.

  因为有着这么一个说法,就是说好的架构必然具有良好的扩展性.
 
  一种很理想主义的想法就是在设计出一个好的架构之后,无论需求如何变更,都能够适应.
  现在想想,这其实是本末倒置的误区.

  所谓的架构扩展性在于面对需求变更的时候,有良好的适应能力.
  其实质是,对于需求的变更,都能保证其跟原有架构设计的一些假设不会冲突.

  意思就是说,你的架构没有做过多的假设.
  比如对于一个这样的需求,偷菜写个函数.
  于是可能有这么些个实现:
   steal(vegetable)
   or
   steal(stealable)
   or
   operate(someting)
   or
   operate(onething,anotherthing)
   or
   operate( list onething , list anotherthing )
   or
   operate( list paticipate_1 , list paticipate_2 , ... )
   or
   getHandle(steal_vagetable).process()
   
   实际哪个实现取决于你做了多少假设.
   也就是说粒度细分到什么程度.
   
   而此时所谓架构是否有良好的扩展性,就在于,新需求会将粒度缩放到哪个程度.
   一旦细化的粒度小于当前架构的粒度,也就是架构不适应需求了.

   所以,最好的架构其实是没有架构.
   即不做任何假设.
   getHandle(steal_vagetable).process()

   这其实又是一个螺旋式的回归.