精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-08-23
请问接下来该怎么办呢?除了拆分这张表,或者做分区表,还有其他办法提高这张表的查询和更新速度吗?目前我的倾向是分区表,但是没做过,也不知道效果如何,请指点!!!谢谢!!! 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-08-23
key/value 的数据更适合于 nosql 的数据库
|
|
返回顶楼 | |
发表时间:2012-08-23
这个只是数据监测,可以根据时间或其他维度进行切分表,用怎么分区表啊……
|
|
返回顶楼 | |
发表时间:2012-08-23
wu_quanyin 写道 这个只是数据监测,可以根据时间或其他维度进行切分表,用怎么分区表啊……
同意 |
|
返回顶楼 | |
发表时间:2012-08-23
这些数据的历史数据是否经常使用,如果不是,建议按月份来建表就可以了。
|
|
返回顶楼 | |
发表时间:2012-08-23
最后修改:2012-08-23
引用 这张表主要用在后台的数据监测
看样子是日志类的数据时吧? 按日期分区吧, 根据实现情况按年或者月来。 引用 已经膨胀到8G了,索引优化已经没办法提高查询速度了
这句不对,如果你只是key-value, 并且你是去定位具体的数据的话。 你了解一下btree索引的原理的话,其实数据量再大也只是多1或者几次io而以. 嗯。 还有就是索引有没有问题呢? 有没有索引倾斜的问题? 或者再看看你的查询语句。用到索引没有。 还有就是你的数据情况是什么样的。 你的索引列会不会有很多重复值? 或者更严重的null值? 条件比较少,不好分析,不过你这种情况做分区是很合适的。 很久以前倒是听说mysql在单表数据超过一定量的时候,性能会直线下降,但是听说某个版本修复了,不是很清楚,我主要用oracle. |
|
返回顶楼 | |
发表时间:2012-08-23
最后修改:2012-08-26
给你推荐一个办法:1 优化mysql:分库 分表等操作
2. 使用nosql,将记录格式化成文件放到hadoop中,然后使用mapreduce job或者hive job进行预处理,将所需要呈现的记录插入到mysql当中,这样取会比较快, 这个问题我以前工作也遇到过,当时是20多亿条纪录中取数据,太恐怖了。你可以参考一下下面的博文: 关于mysql数据库的一些优化方案 http://lengyueblog.eicp.net/?p=18 一种移动APP统计平台的架构方案(适用于千万级用户的应用) http://lengyueblog.eicp.net/?p=33 |
|
返回顶楼 | |
发表时间:2012-08-24
qaddzzq 写道 给你推荐一个办法:1 优化mysql:分库 分表等操作
2. 使用nosql,将记录格式化成文件放到hadoop中,然后使用mapreduce job或者hive job进行预处理,将所需要呈现的记录插入到mysql当中,这样取会比较快, 这个问题我以前工作也遇到过,当时是20多亿条纪录中取数据,太恐怖了。你可以参考一下下面的博文: 关于mysql数据库的一些优化方案 http://qaddzzq.gicp.net/wordpress/?p=18 一种移动APP统计平台的架构方案(适用于千万级用户的应用) http://qaddzzq.gicp.net/wordpress/?p=33 没有一个网站能够打开..... |
|
返回顶楼 | |
发表时间:2012-08-24
定时转存,导出、压缩,备查
|
|
返回顶楼 | |
发表时间:2012-08-24
最后修改:2012-08-26
qaddzzq 写道 给你推荐一个办法:1 优化mysql:分库 分表等操作
2. 使用nosql,将记录格式化成文件放到hadoop中,然后使用mapreduce job或者hive job进行预处理,将所需要呈现的记录插入到mysql当中,这样取会比较快, 这个问题我以前工作也遇到过,当时是20多亿条纪录中取数据,太恐怖了。你可以参考一下下面的博文: 关于mysql数据库的一些优化方案 http://lengyueblog.eicp.net/?p=18 一种移动APP统计平台的架构方案(适用于千万级用户的应用) http://lengyueblog.eicp.net/?p=33 没有一个网站能够打开..... 额, 我这都可以打开啊。。。 |
|
返回顶楼 | |