优化时机

一般单表超过500万左右,或明显感觉到性能下降时,需要优化

优化方案

  1. 读写分离
  2. 使用缓存,如memcached或Redis
  3. 使用搜索引擎,如ElasticSearch或solr
  4. 分库分表

详细说明

  1. 读写分离很容易实现,建议在一开始做,不必等到性能下降时
  2. 发现性能下降时可做。比如有一张500万大表,不可能缓存全表,只能缓存热点数据,所以需要有一个监控热点数据的功能
  3. 像缓存整个大表或者数据量很大可以用搜索引擎,搜索引擎是文件存储,适合高效查找,但不对插入修改、事务等支持。使用搜索引擎的话需要定时把mysql的数据同步给它,同样的数据需要预留2倍磁盘,虽然搜索引擎可能可以压缩
  4. 分库分表其实可以在第二步做,但实现较复杂;分表后必然涉及要读取多个表的问题,但对开发是透明的,在应用开发与数据库中间需要研发一个平台,自动hash索引到分表后的表。举个例子,假设有一张600万的表,可以分为两张表,按时间分,时间点A以前的分一张,500万;另一张表100万,后续的都插入到该表

现状:数据库现在用5.5版本,免费的,不购买服务,使用了上面的2和3,暂时没遇到什么难题。不需要dba,一般难题研发可以搞定。

以上方案针对的是最大表是1000万数据量的表。超过1000万未经实践。(感谢老郭提供技术支持)

ouyida3的blog
2015.4.8

苏生不惑 · 2015年04月18日

搜索引擎的话推荐ElasticSearch还是solr

+1 回复

ouyida3 作者 · 2015年04月20日

我们现在用的是es,感觉挺好的,暂时没遇到什么障碍和不妥。solr是别的部门在用,听说也挺好的,由于我没有使用过,所以不便发表比对的意见:)

+1 回复

formemory · 2016年03月18日

第三部,使用es,不会造成数据同步延迟吗?具体如何做

回复

载入中...
ouyida3 ouyida3

74 声望

发布于专栏

ouyida3

技术爱好者,敏捷粉丝,关注前端、java、数据库和云计算。

1 人关注