目前有个简单的交易系统，自然需要存储所有交易记录，并生成流水号啥的
目前已投入使用的有mysql和redis，如果需要的话可以加上mongodb
mysql
redis
mongodb
我设想中，交易记录流水号由当天日期+redis原子自增数组合得出
但是被交易记录表的数据库设计给难住了，因为数据量可能会很大，必须要分表甚至分库。但是又要求可以通过任意自定义时间段来查询交易记录。请问如何合理设计数据结构并保证一定的性能？
先谢过各位
认证0级讲师
不好回答，也不建议过早考虑。是不是可以这样理解“数据量可能会很大”，现在刚开始搞，数据量不大，但是以后备不住就成淘宝了，数据量必然很大。其实不管是采用分表、分区、Merge引擎的方式，都是可以随时进行的，而不需要在初期就做如此长远的打算，因为你计划了也不如变化，比如典型的hash方式，你留几位？留2位，那以后数据量大了还是不够，留6位？分的表比数据都多。而且数据量太大的时候光靠分是不行的，需要的是冗余才能提升性能，一套按user切，一套按交易时间切，如果你还想根据购买的商品查询交易记录，好的，再来一套按商品信息切。
我觉得分库是不太需要考虑的，因为你可以使用分布式文件系统玩儿集群，所谓分库其实就是把数据分成常用的，几乎不用的，压箱底的这么几个类型分开。我没分过库，此段纯属臆测。
个人看法，仅供参考，抛砖引玉。
“一套按user切，一套按交易时间切” 怎么理解？
保留最近三个月的记录，其他记录移到历史记录表，够用了
楼上说的比较实用，保留三个月的交易记录，时间到，将当前记录转移至交易历史纪录库，这样当前表的性能有保障，只不过历史数据库的数据量会很大，但使用频率并不高
如题其实你并没有实际投入使用MongoDB，不建议你为了这个再多引入一项技术，毕竟生产环境维护的工作量在那里（虽然MongoDB的维护相对来说还比较简单）。再者如果真有你说的那么大量的数据，在没有相关经验积累的情况下直接使用一项新技术基本上也是搞砸的份儿。不过既然打上了MongoDB的标签，我们也从MongoDB的角度说说理论上的实现。先说说MongoDB实现你的需求有什么优势
Sharding提供天然的大数据量支持，几个分片下来千万上亿甚至更多的数据量也不在话下。需要的时候也可以很方便地通过增加结点数量来进行水平扩展。最关键的，sharding的水平扩展对于程序来说几乎是透明的，也就是你的程序可以几乎不用考虑分库分表的问题。这点能够很方便地解决你要求的数据量问题。
Tag aware sharding可以方便地解决旧数据归档问题。虽然归档对于MongoDB来说并不一定是一个必要操作，取决于片键的选取和你的查询方式。
Replica Set提供天然的高可用支持，错误恢复时间可以控制在12秒以内。既然是交易系统，假设数据量有你说的这么大，那当机1秒就会损失相当可观的交易额，所以不管选择什么技术，HA必定是一个必要特性。
WT支持数据压缩。虽然存储设备现在是最廉价的硬件，但是海量数据下能省下个哪怕30%也是相当可观的。
以上特性在官方文档中分别都有详细介绍，想要了解细节不妨Google一下，这里就不展开讲了。所以说，你提的需求MongoDB基本上天然地都已经解决了，不需要很多额外的设计。除了一项关于大跨度查询交易的问题。我的理解大跨度查询听起来像是一个OLAP需求，交易系统多数时候应该是OLTP为主。而通常情况下的OLAP都不会太在乎性能，所以你在这里要求性能似乎不太好理解。实际上也没有哪项技术能在大批量处理数据的同时还能保持“非常好”的性能，这时候只能说“足够好”或者“还凑合”。所以我感觉这个要求不太合理。更常见的一个问题应该是，如何在进行OLAP的同时不影响OLTP的性能。而这个问题也可以方便地通过配置MongoDB复制集的标签达到流量定向的目的，从而隔离OLAP和OLTP，实现互不干扰。同时复制集的不同结点可以根据OLAP和OLTP需求分别建立不同的索引，这点也为OLAP和OLTP并行提供了便利。然后说说使用MongoDB存储交易数据会遇到的问题：
交易额通常要求精确，如果有审计方面的要求更是如此。遗憾的是目前版本的MongoDB不支持实数，这使得金额计算可能出现小额偏差，特别是在聚合运算的时候。支持实数的MongoDB可能要到下一个版本才会推出。
MongoDB的群殴哲学使得MongoDB在服务器数量上远高于其他关系型数据库，成本问题不容忽视。（但在达到一定规模的情况下，也避免了使用高成本硬件如小型机，SAN存储等）
最后，如果一个新手在没有经验的情况下使用MongoDB最有可能踩的坑：
用关系范式来设计MongoDB数据库，性能灾难。
与上面相对的另一个极端，滥用schema-free。数据模型乱七八糟，极难维护。MongoDB的使用原则之一就是没有原则，程序员可以不受数据模型限制随意发挥，但一切应以使用方便，高性能为目标。有时候可能不能两全，那么要根据实际情况取舍。
选择错误的片键。这会导致出现数据量不均衡，或者写入的时候出现热分片。
好好使用索引。虽然这是一个基本功，并且对于所有数据库都适用，但是我还是经常发现程序员在写代码过程中根本不在意索引，或者不知道该建立怎样的索引。
所以如果上面的介绍勾引到你，实在想要引入MongoDB，至少先了解将会踩到的坑。
不好回答，也不建议过早考虑。
是不是可以这样理解“数据量可能会很大”，现在刚开始搞，数据量不大，但是以后备不住就成淘宝了，数据量必然很大。
其实不管是采用分表、分区、Merge引擎的方式，都是可以随时进行的，而不需要在初期就做如此长远的打算，因为你计划了也不如变化，比如典型的hash方式，你留几位？留2位，那以后数据量大了还是不够，留6位？分的表比数据都多。
而且数据量太大的时候光靠分是不行的，需要的是冗余才能提升性能，一套按user切，一套按交易时间切，如果你还想根据购买的商品查询交易记录，好的，再来一套按商品信息切。
我觉得分库是不太需要考虑的，因为你可以使用分布式文件系统玩儿集群，所谓分库其实就是把数据分成常用的，几乎不用的，压箱底的这么几个类型分开。我没分过库，此段纯属臆测。
个人看法，仅供参考，抛砖引玉。
“一套按user切，一套按交易时间切” 怎么理解？
保留最近三个月的记录，其他记录移到历史记录表，够用了
楼上说的比较实用，保留三个月的交易记录，时间到，将当前记录转移至交易历史纪录库，这样当前表的性能有保障，只不过历史数据库的数据量会很大，但使用频率并不高
如题其实你并没有实际投入使用MongoDB，不建议你为了这个再多引入一项技术，毕竟生产环境维护的工作量在那里（虽然MongoDB的维护相对来说还比较简单）。再者如果真有你说的那么大量的数据，在没有相关经验积累的情况下直接使用一项新技术基本上也是搞砸的份儿。不过既然打上了MongoDB的标签，我们也从MongoDB的角度说说理论上的实现。
先说说MongoDB实现你的需求有什么优势
Sharding提供天然的大数据量支持，几个分片下来千万上亿甚至更多的数据量也不在话下。需要的时候也可以很方便地通过增加结点数量来进行水平扩展。最关键的，sharding的水平扩展对于程序来说几乎是透明的，也就是你的程序可以几乎不用考虑分库分表的问题。这点能够很方便地解决你要求的数据量问题。
Tag aware sharding可以方便地解决旧数据归档问题。虽然归档对于MongoDB来说并不一定是一个必要操作，取决于片键的选取和你的查询方式。
Replica Set提供天然的高可用支持，错误恢复时间可以控制在12秒以内。既然是交易系统，假设数据量有你说的这么大，那当机1秒就会损失相当可观的交易额，所以不管选择什么技术，HA必定是一个必要特性。
WT支持数据压缩。虽然存储设备现在是最廉价的硬件，但是海量数据下能省下个哪怕30%也是相当可观的。
以上特性在官方文档中分别都有详细介绍，想要了解细节不妨Google一下，这里就不展开讲了。
所以说，你提的需求MongoDB基本上天然地都已经解决了，不需要很多额外的设计。除了一项关于大跨度查询交易的问题。
我的理解大跨度查询听起来像是一个OLAP需求，交易系统多数时候应该是OLTP为主。而通常情况下的OLAP都不会太在乎性能，所以你在这里要求性能似乎不太好理解。实际上也没有哪项技术能在大批量处理数据的同时还能保持“非常好”的性能，这时候只能说“足够好”或者“还凑合”。所以我感觉这个要求不太合理。更常见的一个问题应该是，如何在进行OLAP的同时不影响OLTP的性能。而这个问题也可以方便地通过配置MongoDB复制集的标签达到流量定向的目的，从而隔离OLAP和OLTP，实现互不干扰。同时复制集的不同结点可以根据OLAP和OLTP需求分别建立不同的索引，这点也为OLAP和OLTP并行提供了便利。
然后说说使用MongoDB存储交易数据会遇到的问题：
交易额通常要求精确，如果有审计方面的要求更是如此。遗憾的是目前版本的MongoDB不支持实数，这使得金额计算可能出现小额偏差，特别是在聚合运算的时候。支持实数的MongoDB可能要到下一个版本才会推出。
MongoDB的群殴哲学使得MongoDB在服务器数量上远高于其他关系型数据库，成本问题不容忽视。（但在达到一定规模的情况下，也避免了使用高成本硬件如小型机，SAN存储等）
最后，如果一个新手在没有经验的情况下使用MongoDB最有可能踩的坑：
用关系范式来设计MongoDB数据库，性能灾难。
与上面相对的另一个极端，滥用schema-free。数据模型乱七八糟，极难维护。MongoDB的使用原则之一就是没有原则，程序员可以不受数据模型限制随意发挥，但一切应以使用方便，高性能为目标。有时候可能不能两全，那么要根据实际情况取舍。
选择错误的片键。这会导致出现数据量不均衡，或者写入的时候出现热分片。
好好使用索引。虽然这是一个基本功，并且对于所有数据库都适用，但是我还是经常发现程序员在写代码过程中根本不在意索引，或者不知道该建立怎样的索引。
所以如果上面的介绍勾引到你，实在想要引入MongoDB，至少先了解将会踩到的坑。