为啥不上 SSD？

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

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

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

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

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

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

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

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

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

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

#7 楼 @sharp 加台 DB 可以，做啥呢？

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

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

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

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

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

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