大数据量处理的方法探讨

       首先声明，这篇文章是我整理所得，里边有很多地方严格的奉行了鲁迅先生的拿来主义……，之所以还厚着脸皮的放在这里，目的就是抛砖引玉，放出问题，供大家一起讨论！

 

应用场景：大数据量处理是指同时需要对数据进行检索查询，同时有高并发的增删改操作，数据量到达百万级；

 

       有过数据库经验的人都知道，有时候查询几百万条数据，一个检索查询可以让你等几分钟，这对于数据库开发人员来说，无疑是无法忍受的；

       现在我是想探讨下对大数据量的处理，主要包括怎样处理大数据量，加快增删改查得速度，提高数据库性能，试想：腾讯，新浪，百度，动辄数以亿计的帐号,数据量的该有多大呀，对于这么大的数据量，查询速度怎么这么快呢，他们在使用什么样的方法？

       于是我总结了互联网现在对数据处理的发展阶段。对于大数据量处理，如果是互联网处理的话，一般分为下面几个阶段：  

第一阶段，所有数据都装入一个数据库，当数据量大了肯定就会出现问题，就像刚刚说的查询比较慢的问题。

于是大家开始想办法，这就到了第二阶段：

 

第二阶段，那时肯定想做缓存机制，确实使用缓存可以如加上缓存Memcached，可以提高性能，减少数据库服务器的压力，但缓存也是治标不治本的，数据量太大了还会是一个很大的问题。

于是到了第三阶段：

 

第三阶段，也就是使用master-slave模式，也即主从数据库，master提供写，slave进行读，这个适合于由写造成数据库性能下降的方法，并不能解决所有的问题。

这不，人们又想到了第四个阶段：

 

第四阶段，垂直分库，这个可以解决一定的问题，把数据库的表分在不同的服务器上，但是这也并不能解决所有的问题，有时候个别表的数据量还是增加的比较快的，查询性能一样是一个问题，并且其中一个服务器Down了系统都会出问题。

所以，又到了第五阶段：

 

第五阶段，进行水平分库，这个不错，记得以前也是尝试过按这个分时间水平分库，这样的确是个不错的方法，其实可以分的更细点估计效果更好，但是多个数据库的管理也将是一个问题，但是这个问题还不大。

令人惊喜的是，现在又到了NoSQL阶段：

 

第六阶段，用NoSQL做了，关于NoSQL怎么做可以参考Google的bigtable，相关的系统的知识，网上现在也有很多，我会在下边简单的聊聊NoSQL。

至于：

第七阶段：……，还没出来，你我都可以续写！

 

下边就试着探讨NoSQL对大数据量的处理：

NoSQL就是将写操作在内存中进行，定时或按某一条件将内存中的数据直接写到磁盘上，一定程度上是解决了数据的访问速度问题，解决了高并发读写以及海量数据访问的问题，但是从数据库横向扩展性的 CAP理论来说，NoSQL是牺牲了一致性，只是做到了AP，没有保证数据的一致性C，一致性只是保证了最终一致性，这是他的一个缺点，另外，还有以下的缺点：

1，当机器挂了数据将会丢失，这个可以可以考虑共享内存解决。

2，内存的限制,内存有限当写数据操作太大的时候内存也会爆。

解决：Bigtable的做法是通过bloom-filter算法合并掉相同的操作，比如UPDATE A='A' ，update A='B'时可以直接合并了，当然这个只是尽量的减少内存爆的问题，并不能避免。

 

基本理论基础   NoSQL理论基础：把内存当成是新的硬盘，硬盘当成是新的磁盘。

这只是抛砖引玉，欢迎大家补充!

 

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

CAP理论：Consistency 一致性 ，Availability -可用性 ，Partition -容错性