探讨大数据量处理

bloom-filter 算法


场景:我说的大数据量处理是指同时需要对数据进行检索查询,同时有高并发的增删改操作;

记得以前在XX做电力时,几百万条数据,那时一个检索查询可以让你等你分钟;



现在我是想探讨下对大数据量的处理,那时我就在想例如腾讯,盛大,动辄数以亿计的帐号,怎么能这么快呢, 于是找到了互联网现在对数据处理的发展:

对于大数据量处理,如果是互联网处理的话,一般分为下面阶段:

第一阶段,所有数据都装入一个数据库,当数据量大了肯定就会出现问题,就像刚刚说的查询,于是想办法

第二阶段,那时肯定想做缓存机制,确实可以如加上缓存Memcached,但缓存也是治标不治本,数据量太大了也是不行于是

第三阶段,master-slave模式,进行主从数据库,master提供写,slave进行读,这个适合于有写造成数据库卡的方法,XX那个还是不行,于是

第四阶段,垂直分库,这个意义还是不大,对于这种采集数据的,于是

第五阶段,进行水平分库,这个不错,记得以前从兴也是按这个分时间水平分库,其实可以分的更细点估计效果更好

 

补充一个阶段,应该还有一个阶段是内存数据库的阶段,内存数据库只是复杂的关系处理和事务等,电信计费等很多都用这个


第六阶段,用nosql做了,关于nosql怎么做可以参考google的bigtable


其实本文主要目的也是想探讨nosql对大数据量的处理:

NOSQL就是将写操作在内存中进行,定时或按某一条件将内存中的数据直接写到磁盘上,一定基础上是解决了


nosql 主要解决了:
1,高并发读写的需求
2,海量数据访问的需求
3,数据库横向扩展性的需求

CAP理论来说,nosql是牺牲了一致性,做到了AP,一致性只是保证了最终一致性

缺点也很明显:
1,当机器挂了数据将会丢失
解决:可以考虑共享内存

补充1:其实这里可以展开了讲,一种是通过共享内存来实现

集群内存:根据的是Quorum NRW理论,比如你有N台机子用来集群,每次你进行读写数据时可以至少要同步到X个节点才算成功,所以你每次读数据时只需要读大于N-X个节点就能保持你的正确率,其实就是对数据进行的冗余备份,不过我们存的是内存,相对于直接的磁盘操作,跨网络进行内存操作可以更快;

其实还一种保证数据一致性,就是记录日志,当数据每次写操作内存时都进行日志记录,然后再在内存中进行写操作,至少很多数据库就是这样做的,如redis


2,内存的限制,内存有限当写数据操作太大的时候内存也会爆
解决:Bigtable的做法是通过bloom-filter算法合并掉相同的操作,比如UPDATE A='A' ,update A='B'时可以直接合并了


---------------------------------
基本理论基础

nosql理论基础:内存是新的硬盘,硬盘是新的磁盘

NOSQL探讨

关系型数据库都要实现事务ACID特效即:原子性(Atomicity), 一致性(Consistency), 隔离性(Isolation), 持久性(Durability)



CAP理论

Consistency 一致性

Availability -可用性

Partition -容错性





-------------------------------
抛砖引玉而已,如果有什么经验欢迎分享,我将持续关注大数据量处理
 

大多数NoSQL数据库都不支持事务,不支持SQL等,所以还是得保留关系型数据库


现在有人提到用内存数据库, 总体如果是简单业务来说,NOSQL的速度比内存数据库更快,但NOSQL最大缺点,不支持事务,不支持SQL查询等

posted @ 2012-02-25 16:57  何锦彬  阅读(23671)  评论(19编辑  收藏  举报