求问交易记录这种数据量大且查询跨度大的数据库如何设计？
目前有个简单的交易系统，自然需要存储所有交易记录，并生成流水号啥的
目前已投入使用的有mysql和redis，如果需要的话可以加上mongodb
我设想中，交易记录流水号由当天日期+redis原子自增数组合得出
但是被交易记录表的数据库设计给难住了，因为数据量可能会很大，必须要分表甚至分库。但是又要求可以通过任意自定义时间段来查询交易记录。请问如何合理设计数据结构并保证一定的性能？
先谢过各位
展开
收起
1
条回答
写回答
写回答
-
不好回答，也不建议过早考虑。
是不是可以这样理解“数据量可能会很大”，现在刚开始搞，数据量不大，但是以后备不住就成淘宝了，数据量必然很大。
其实不管是采用分表、分区、Merge引擎的方式，都是可以随时进行的，而不需要在初期就做如此长远的打算，因为你计划了也不如变化，比如典型的hash方式，你留几位？留2位，那以后数据量大了还是不够，留6位？分的表比数据都多。
而且数据量太大的时候光靠分是不行的，需要的是冗余才能提升性能，一套按user切，一套按交易时间切，如果你还想根据购买的商品查询交易记录，好的，再来一套按商品信息切。我觉得分库是不太需要考虑的，因为你可以使用分布式文件系统玩儿集群，所谓分库其实就是把数据分成常用的，几乎不用的，压箱底的这么几个类型分开。我没分过库，此段纯属臆测。
2019-07-17 19:48:12赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
相关问答
