简单说，有订单表，一天一万单左右（还在不断增加），表里存储了订单的金额，状态，商品，商家，用户等信息。现在有个需求就是按照时间区间和各种纬度来展示订单和统计信息，类似于支付宝的历史消费记录。订单在生成的几天内可能会发生状态变化（退款之类的）。
另外，团队情况是没有 DBA ，后台研发团队比较小，能专职做这个需求的只有一个工程师。
想到的方法有这么几种：
目前想到这三种方法，都有各自的问题。
有没有做过类似系统的朋友，欢迎来分享一下经验。
 |
1
jugelizi Nov 3, 2015
如果是展示统计实时性没那么高的话完全放夜里定时去做分析呀然后缓存起来 每天更新一下
|
 |
3
scys Nov 3, 2015
你时间跨度有多大。。。一天一万，一年不够 500 万，十年 5000 万，一百年才 5 亿，买台好点的服务，足够处理了。
|
 |
4
abcfyk Nov 3, 2015
三个都不是好办法。
现在你的数据明显分为固定的和易变动的数据，把这两块数据拆开不就很容易统计了嘛。 把已经完成的订单移动到历史订单表里。订单表只保存未完成订单。 统计起来就方便很多了。 这个其实就是分库分表法。 但是。。这种要对所有订单数量做统计的做法本身就很不好。还有一个办法是用 solr 。我们在用这个。 1 亿以下的数据统计速度都没有太大差别。 |
 |
5
gamexg Nov 3, 2015
最简单的玩法，可以先直接对订单数据库进行统计，性能不够的时候直接用数据库本身的主从复制弄个统计专用从库，简单可靠。性能还是不行在选用方案 2 ，逻辑设计比较好的话不会出现数据不一致的现象。除非有 DBA ，不建议触发器。 /t/232965
|
 |
6
Magic347 Nov 3, 2015
更倾向于方法 2 ，对订单业务数据表和统计数据表进行分离。
可以基于业务数据表每天的最新数据，每天同步写一份日志，统计数据表基于该日志统计并输出。 另外，针对订单状态时有变化的情况，在统计时需要维护一份历史订单的最新状态文件，每次统计时一旦发现历史订单的状态发生变化，就要同步更新统计结果数据（因为这可能牵涉到退款以及订单金额的统计）。 最后，针对楼主考虑到的两边统计数据不一致的状况，可以另外开发一个简单的异步对单任务，对业务数据表的数据和统计数据表的数据每日进行一次对帐，当然考虑到可能需要全表扫描业务数据表，因此在非业务高峰期调度对单任务较宜。 |
 |
7
raysmond Nov 3, 2015
感觉可以这样： Redis 做统计和持久化，统计信息全部异步同步到 DB
|
 |
8
wdd2007 Nov 3, 2015
直接做统计吧。。一天一万应该还好。
|
 |
9
domty Nov 3, 2015
直接创建个 view 去统计这些数据的性能不够吗？
|
 |
10
jeansfish Nov 3, 2015
不是数据仓库吗？
|
 |
11
loudis Nov 3, 2015
想的太多，人家需要的真的这么精确吗，差几个退款单子会影响大的趋势吗？ 2 就好了。
|
 |
12
shakoon Nov 3, 2015
用方案二：每天在业务低谷时段（比如凌晨四点）去对上一日的数据做统计后写入另一个表，以后各种统计都去查这个表。如果对实时性要求高，可以每天跑若干次统计。楼主这个其实是个典型的 BI 建模场景。
|
 |
13
wupher Nov 3, 2015
可以直接按维度进行统计，也就是出一张订单的时候直接立即计算出统计值。利用 MongoDB 的 json update 操作。性能消耗极小，实时结果，工作量低。缺点是维度预置。
可以参考 https://count.ly/ 的开源代码，很简单就搞定了。 |
Select Language