数据库大数据量处理问题讨论

一、我从事过6年的数据库高负载解决方案，处理过很多的海量数据问题。我的经验是： 
1。优化数据存储的算法，保证io的读写最小，这一点最容易被人忽视，而这一点确实整个问题的关键。 

2。确保可读数据在磁盘上连续存储，使得磁盘指针不会“空转”。

二、实现读写分离是一种方法,不足的是这样还是没有解决表数据量大，使查询运算耗时的问题.

三、

我这边的mysql也到了单表到2G快了，我这边所处理的方案是建议主从服务器，一台主二台从的，主服务器全是写入，更新，删除数据操作。二台从服务器只管使用查询操作。 
这是第一步，其次就是分表，分表方案有二种，一种是表结构完全一样，按时间来拆分。还有一种是方案是表结构打散，把多内容的进行分离，不过按照大容量的数据来讲还是第一种好一些，当然有能力不怕累，可以将两种方案结合起来做。 

四、

我目前所在的系统就是这么一个有实时插入又需要大数据的查询的一个系统。
采用了如下手段：
1，当天的记录会放在一个独立的表中.主要是针对实时的插入的记录，记录不要太多以免插入的时候维护索引的开销稳定在一个范围内。
2，历史的记录会按天分区的形式保存在历史表中。这个表一天只会批量的插入一次数据(用的是分区交换的方法)。
3，分区的索引对我的业务性能不好，因为要跨天 查询。历史查询最长时间段是一个月的时间，如果按照一个月一个分区的话，一个分区差不多是一个亿的记录，
就算是按月分区的话，再创建分区的本地索引，如果是时间段跨了月份的话估计分区的本地索引性能估计也不行。
4，后来采用一个方案，DB层上面再放了一个缓冲层，就是我最近在测试的Timesten关系型内存数据库，按照时间的老化策略缓冲一个月的数据。具体不展开说了。涉及的内容很多。

只是对于这个系统，我总结一下有以下需要注意的地方:
1,对于一个系统来说，如果查询性能反应不好的话，第一个调整的地方是思考业务的需求是否是合理的？
一个查询既要分页获取前面一页或者几页的数据，又要根据条件获取总的记录数，如果符合的记录总数是上亿条的话，感觉就是一个不合理的要求。
2，市场需求调研人员业务水平根本不合格。
3，前台开发人员写的SQL差，根本没有调优的基本概念,术业有专攻啊。
4，如果业务需求合理，SQL的调整无非是从执行计划开始，如果是ORACLE10g,开了cbo，可以用 SQL优化器 (SQL Tuning Advisor :STA)
分析你的sql。
5，最近的nosq和海量分布式的数据库概念很热。公司也在考虑HBASE了。

五、

1 数据量上亿时我都会使用分区，具体的分区方案看业务需求，如果查询数据是按时间来的且时间跨度小，那么我会按天分
2 读写分离，说实话这个对我来说只是理想方案，实现起来往往有许多困难。磁盘阵列能上则上。
3 SQL语句的优化，实话说很多程序员写出来的SQL真的不忍直视。
4 内存数据库，这个我还没有尝试过，但用过的人说还好。

六、

 如今随着互联网的发展，数据的量级也是撑指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。
  虽然关系型数据库在海量数据中逊色于NoSQL数据库，但是如果你操作正确，它的性能还是会满足你的需求的。针对数据的不同操作，其优化方向也是不尽相同。对于数据移植，查询和插入等操作，可以从不同的方向去考虑。而在优化的时候还需要考虑其他相关操作是否会产生影响。就比如你可以通过创建索引提高查询性能，但是这会导致插入数据的时候因为要建立更新索引导致插入性能降低，你是否可以接受这一降低那。所以，对数据库的优化是要考虑多个方向，寻找一个折衷的最佳方案。