对大数据处理的存储,排序和计算的一点思考
大数据处理现在比较火热,在信息爆炸的信息社会,这其实也是必然的.特别是云计算时代,对于云应用,这是一个无法绕开的课题.相对处理能力来讲,"大数据"处理其实从有计算机开始就已经存在.我做ERP系统的时候(2001),为了性能,就用了数据的分开存储,以下是我的一些看法:
1)大数据的最基本难题
在数据量海量的情况下，需求的不确定性、计算能力和内存空间的瓶颈、外围存储的非随机访问是大数据处理非常困难的基本原因。由于计算能力和内存空间的限制，海量数据不可能全驻内存处理，而外围的IO能力又使得数据移动的代价非常大,一种确定的存储方案能满足的外部需求非常有限，存储方案一旦确定，有利的业务范围和能提高的计算效率的也基本确定，要满足额外的业务或需求就变得非常困难，比如数据如果按时间分布存储，但业务需求如果要按地点进行检索，要得到准确的结果，你就不得不遍历所有的存储点，而如果要进一步按类别（类别属性在各存储点无规律）排序，这就是一个噩梦。所以：
2)大数据处理的基本矛盾
用户的需求多样性和大数据应对方案的单一性,比较典型的例子就是大数据排序,假设一类数据有26个属性A-Z,存储可以分布,查询也可以分布,但你存储方案一旦确定,比如按,A,K,X三个属性分布存储,那么对A K X属性检索和排序都会比较快，但如果用户要对O、P、Q属性进行检索，按K排序就非常麻烦了，你得先从各个点获取检索结果，然后集中进行排序。理论上来讲，我们可以针对用户的每一种可能需求各自建立自己的存储方案，但实际上很难行得通（对于一些不需要修改和同步的数据，应对难度就低很多，比如网页搜索，可以采用索引索引的技术），特别是对于企业级应用。所以：
3）大数据处理的基本方法
分治，针对业务设计，索引技术。大数据处理首先要根据业务的特点选定存储方案，因为存储方案确定后，数据处理的性能空间就大致确定了。这也是数据挖掘需要建立主体仓库的根本原因，一个万能的解决方案是不存在的。
PS：题外话，在数据库检索中，用Like并不代表低效率，对于现在的Oracle来说，在索引字段上用like（前缀匹配）数据其实很快的，我估计Oralce的索引采用的是类似B+结构，索引叶子节点上是连续有序的，用一点小技巧，就可以很快获得检索结果，比如 like AB%,先可以直接定位到AB,然后定位到AC（不含AC),中间一段就是索引结果。
--思考随笔，有点简单，为记。
