大数据存储与处理

大数据存储与处理 大数据处理现在比较火热,在信息爆炸的信息社会,这其实也是必然的.特别是云计算时代,对于云应用,这是一个无法绕开的课题.相对处理能力来讲,"大数据"处理其实从有计算机开始就已经存在.我做ERP系统的时候,为了性能,就用了数据的分开存储,以下是我的一些看法: 1)大数据的最基本难题在数据量海量的情况下，需求的不确定性、计算能力和内存空间的瓶颈、外围存储的非随机访问是大数据处理非常困难的基本原因。由于计算能力和内存空间的限制，海量数据不可能全驻内存处理，而外围的IO能力又使得数据移动的代价非常大,一种确定的存储方案能满足的外部需求非常有限，存储方案一旦确定，有利的业务范围和能提高的计算效率的也基本确定，要满足额外的业务或需求就变得非常困难，比如数据如果按时间分布存储，但业务需求如果要按地点进行检索，要得到准确的结果，你就不得不遍历所有的存储点，而如果要进一步按类别（类别属性在各存储点无规律）排序，这就是一个噩梦。所以： 2)大数据处理的基本矛盾用户的需求多样性和大数据应对方案的单一性,比较典型的例子就是大数据排序,假设一类数据有26个属性A-Z,存储可以分布,查询也可以分布,但你存储方案一旦确定,比如按,A,K,X三个属性分布存储,那么对AKX属性检索和排序都会比较快，但如果用户要对O、P、Q属性进行检索，按K排序就非常麻烦了，你得先从各个点获取检索结果，然后集中进行排序。理论上来讲，我们可以针对用户的每一种可能需求各自建立自己的存储方案，但实际上很难行得通（对于一些不需要修改和同步的数据，应对难度就低很多，比如网页搜索，可以采用索引索引的技术），特别是对于企业级应用。所以： 3）大数据处理的基本方法分治，针对业务设计，索引技术。大数据处理首先要根据业务的特点选定存储方案，因为存储方案确定后，数据处理的性能空间就大致确定了。这也是数据挖掘需要建立主题仓库的根本原因，其目的就是缩小目标范围(需求),使得数据存储有利于挖掘计算(业务).而一个万能的解决方案是不存在的。从另外一个方面来说,这也是为什么我们不提倡过度设计的原因,因为一个设计能解决80%的问题就已经非常不错,如果你非得找一个解决100%问题的方案,反而会使得整体上的效率变低.分治其实就是人海战术,属于分布式计算范畴.由于分布式计算一般要求对计算节点的添加与移除要尽量简单,这其实就限制了计算节点的个性化,因此,对节点间的协同作业规则就要尽量简单,可靠和有效(一般工程化的东西要求基本如此).针对业务设计,主要目的就是让目标点减少,提高解决问题的聚焦度,从而提高方案的对业务的最大限度的效率支持,比如,在架构选型上,首选的都不是那些开源框架或者像微软提供的哪些企业应用框架,原因非常简单,就是这些框架的假定用户范围都非常大,都是想放之四海而皆准,当然这不是在说这些框架的不是,因为他们的立场必须这样.由于考虑的东西太多,其效率,特别是与公司的业务的契合度而言,往往就不会很好.在力所能及的范围内,我喜欢开发适合于自己业务的框架,不仅轻量级,更主要的是可以与公司业务紧密结合(PS:这是从GFS学来的,所谓针对业务的访问接口(大意));索引技术就很多了,大家可以看看相关资料.所以: 4)试验和模拟是学习大数据处理成功的关键犯错不怕,就怕不会犯错,做为程序员,有想法,就应该敲码实现,用代码验证想法,用想法指导敲码,虽然对国人而言,写代码很掉价,但如果喜欢,又何必在乎呢.因为只有经过试验,才敢真正的去应用.不是每个人都可以有淘宝,百度等那样真实的海量数据让你去练手的.题外话，在数据库检索中，用Like并不代表低效率，对于现在的Oracle来说，在索引字段上用like（前缀匹配）数据其实很快的，我估计Oralce的索引采用的是类似B+结构，索 引叶子节点上是连续有序的，用一点小技巧，就可以很快获得检索结果，比如likeAB%,先可以直接定位到AB,然后定位到AC（不含AC),中间一段就是索引结果。这只是推断,不过我在亿级的记录上进行测试,结果令人惊讶,性能非常不错.人往往很容易