高吞吐量的实时交易数据库设计

mervynhit 2012-09-19 05:04:13

最近要帮朋友改一个实时交易的系统，以前的系统做得比较差,数据库设计很简单，就是想办法将所有的数据的存起来，主要的问题是效率越来越慢。

特别是交易的表，几秒钟可能要插入几万条，同时还要在业务表检索，客户端经常卡出，我觉得这应该是数据库设计中最常见的问题，不过我自己也就做过最简单的设计，所以想问问各位大神，有没有什么好的方法。

1，是不是要把业务表水平分表，一个表储存所有记录，一个表储存实时记录，然后插入时，同时插入两条数据到各个表中

2，临时表有没有帮助，临时表怎么用，应该怎么设计呢

3，是不是还要有什么分页技术的，这个完全不懂了。

4，肯定有很多我不知道的方法，求指导

...全文

287 10 打赏收藏转发到动态举报

写回复

用AI写文章

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

haitao 2012-09-20

打赏
举报

像证券交易，是可以分表
不过前提是性能压力太大，否则分表后查询会麻烦很多

分区表则是底层分表以得到高性能，应用操作照旧：sql面对的还是一个大表

以学习为目的 2012-09-20

打赏
举报

对于在业务表检索，客户端经常卡出的问题，可以考虑创建一个存储过程+JOB实现超过3天（具体时间根据业务情况设定）的从当前表转存到附表，以减轻当前业务表的负担。

mervynhit 2012-09-19

打赏
举报

[Quote=引用 7 楼的回复:]

几秒钟插入几万条数据的交易系统，生意这么好，怎么会使用新手进行优化？

分表是最后手段，、分页技术挨不上优化技术。

加索引优化才是正道，实在大得没谱才用分表，因为看样子你们公司缺乏技术力量。

盲目搞分表，只会整乱系统业务逻辑。加索引不会影响生产系统运行。
[/Quote]

呵呵，是规模扩大之后可能这样，凡事都要提前考虑，重新做，第一版做得很烂，所以朋友叫我看看，我发现数据库实在做得不好，所以来求建议

winner2050 2012-09-19

打赏
举报

几秒钟插入几万条数据的交易系统，生意这么好，怎么会使用新手进行优化？

分表是最后手段，、分页技术挨不上优化技术。

加索引优化才是正道，实在大得没谱才用分表，因为看样子你们公司缺乏技术力量。

盲目搞分表，只会整乱系统业务逻辑。加索引不会影响生产系统运行。

mervynhit 2012-09-19

打赏
举报

[Quote=引用 5 楼的回复:]

引用 3 楼的回复:
引用 2 楼的回复:

几秒钟可能要插入几万条？
什么系统？什么硬件配置？？

插入和查询分开
插入还能按业务、时间再分就更好

可以说具体点吗，数据库怎么设计，应该用几个表实现啊？插入怎么按业务和时间分啊，不懂

具体是取决于业务是否允许这么做，时间的划分也要符合具体业务的特点
[/Quote]

感谢大神

时间划分是怎么划分，是分表吗，有没有什么资料，链接啥的

haitao 2012-09-19

打赏
举报

[Quote=引用 3 楼的回复:]
引用 2 楼的回复:

几秒钟可能要插入几万条？
什么系统？什么硬件配置？？

插入和查询分开
插入还能按业务、时间再分就更好

可以说具体点吗，数据库怎么设计，应该用几个表实现啊？插入怎么按业务和时间分啊，不懂
[/Quote]

具体是取决于业务是否允许这么做，时间的划分也要符合具体业务的特点