数据库 寻求一个大数据量解决方案

songlipeng2003 · 2012年04月27日 · 最后由 sharp 回复于 2012年04月27日 · 8416 次阅读

用户数量有几十万,每人每天有 20 多个参数要计算保存。这 20 个有一个是基本参数,其他的都是由这一个计算出来。

插入需求:

每天固定开始插入,希望在一个小时之内插入完成

查询需求:

  • 按照每个用户的某个参数查询某段时间的值来绘制曲线
  • 查询这个用户某天的所有参数用来在页面上显示。
  • 查询某天的某个参数的排行

扩展需求:

能满足到百万用户的需求

硬件需求: 8Core 的 CPU 8G 内存,普通 500G 硬盘的服务器做 DB。查询和计算有两台 4Core 8G 的可以使用

软件需求: 基本没有,只要稳定就行,mysql,nosql,MongoDB 都可以。

目前方案:

现在已经积累了几十亿 几十 G 的数据,在 mysql 中存储,仅按照每个参数来分的,每个表的规模都很了,上亿了。插入效率很低,查询也很慢,问题很多

为啥不上 SSD?

@nouse 硬件这部分现在不好改动。会提的,现在最重要的是改架构

表示关注。。不知道能不能得到牛人的答案分析。期待。。

这个问题的瓶颈应该是数据库写入和查询了 个人认为可以这么处理: 1 分表,分级别,需要及时插入的,如你说的 1 小时要插入完成的记录,放一个表,只记录一定时间的数据,这样插入查询都快. 超过时间后移到另一张表,迁移过程可以在业务少的时候进行. 如果数据量更大,就可以分不同访问级别放表, 就可以区分进行优化,比如第一张插入多,那就 index 少点,第二张查询多,那就 index 多点,第三张基本上都不用,放历史数据, 这样三级迁移,基本上能满足不同的需求

  1. 使用分布式数据库
  2. 我不太明白 500G 普通硬盘是什么概念,但是使用硬盘阵列应该是很有必要的

#4 楼 @azhao 分级别,还没有做,应该是可以做的。以前都是绘制所有天的数据的曲线,可以修改成为只绘制 30 的数据的曲线。数据库分 7 天内的,30 天内的,一年内的,所有的。谢谢你的建议 你这里说分布式数据库,是指分开存储吗?存储在多台服务器上? 普通服务器硬盘就是不是 SSD,不是硬盘阵列

分布式数据库,现在很多数据库都支付,像 ruby-china 的 redis,Cassandra 什么的,都是支付分布式的 mysql postgresql 之类的现在也开始支持,差不多,就是数据分放,但由数据库本身支持,你不用多做什么 其实最容易解决 这种问题的办法,是增加设备 我以前做集成 的,我们解决 这类问题基本上都先从硬件开始,不到不得已,不动软件.因为买硬件钱算客户的,开发软件,工作量算自己的,但你给你们自己做,可能思考的立场不太一样.

但增加硬件确实是行之有效的办法

匿名 #7 2012年04月27日

几十亿的数据量都舍不得加台 DB 服务器

#6 楼 @azhao 这倒是啊,我们是自己的东西,所以硬件还是要考虑成本的。考虑过 mongodb,但是也是遗留问题,尽量少改动。

#7 楼 @sharp 几十亿数据要是都是业务数据那肯定很强啊,但是都是些历史数据。很多数据虽然都没有用过,但是还是有必要保存

#7 楼 @sharp 加台 DB 可以,做啥呢?

匿名 #11 2012年04月27日

#10 楼 @songlipeng2003 容灾、集群 , 几十亿的数据量这些基本功课都没有做, 说不过去

匿名 #12 2012年04月27日

#9 楼 @songlipeng2003 如果这么说, 那你们的架构需要调整, 这个属于数据备份的概念, 定时把历史数据 mv 到 mongodb/couchdb 中去

#12 楼 @sharp 还不完全是数据备份,那样就好做了。最好还是修改业务逻辑,让他们成为历史数据,那样会更好一些。

匿名 #14 2012年04月27日

表设计不合理, 第一条军规: 经常访问的数据和不经常访问的数据需要分表甚至分库存储, 第二条: 读写分离, 历史数据不应该和业务数据混在一起。 你说的这点事在电信产品中很常见

#14 楼 @sharp 是的,但是开始时就思考不够,就直接开干了。现在又缺人,我还有其他事情。悲催啊

匿名 #16 2012年04月27日

你们的瓶颈在 DB 上, 优化业务层代码没啥用, 买硬件做集群可以说能好个 30%-50%, 但重构数据库还是最必要的

需要 登录 后方可回复, 如果你还没有账号请 注册新账号