大数据库运维
大数据库运维
大数据库运维
信息时代的高速发展，导致数据量和交易量越来越大。
这种现象首先导致的就是存储瓶颈，因为MySQL数据库，实质上，还是一个单机版本的数据库，而只要是单机，就必然会遇到的一个问题就是存储问题，因为存储是硬需求，而CPU和内存如果不够的话，只是性能不好，并不会直接否定方案或者架构。
解决方案大概有三个方面：
增大磁盘
这种方式，应该是最直接，最简单的方案了，因为磁盘空间不足了，当然加磁盘是手到病除，比如现在是800G，可以增加到2T，这是没问题的，如果现在已经达到了2T，当然，还是可以增加到5T的盘，但实际上，这个时候可能DBA就要捏把汗了，这么大数据量的MySQL实例，如何运维？如果数据坏了，如何恢复呢？时间成本呢？5T的数据量，已经非常吓人了，估计在业内各大公司，没有DBA想要自己运维的MySQL实例达到这个量级吧？其实我个人认为，这个已经是不能接受的量了，最合适的最好保持在1T以下即可。超过这个就要想办法了。当然这个数据量不宜达到这个大小的原因，可能会有人考虑到这是性能的问题，其实不然，或者性能问题很小，因为InnoDB采用的是B+树的存储方案，小表最坏情况下没有查到数据是要找3层，也就是3个页面的IO，而大表需要的是4个页面的IO，影响不大。
数据压缩
为了减少数据对磁盘空间的占用，我们通常也会将数据做压缩处理，通过一个语句即可搞定，是InnoDB原生支持的一种方式，一般情况下，会将数据占用减少到原来的三分之一到一半不等，效果还是足够明显的，不过这样处理之后的数据，在性能上会有所下降，对于响应要求比较高的业务，可能需要谨慎考虑一下，但这种方式，可能还是治标不治本，在数据量继续增长的情况下，过段时间之后，依然面临相同的问题，这种情况下，就不能继续使用这种方式来实现了。
数据分片
数据分片的解决方案，现在业内也用得很多，这种方案已经超出了MySQL本身，包括HBase、Redis等也都在使用这种方案，应该说这种方案是最具扩展性的，并且可以称得上是无限扩展，而上面两种方案，根本谈不上扩展性。所以这种方案在业内成为主流，并且这种方案才能称得上是分布式存储。