火锅、报表与数据库的故事
本文的题目虽然有点小写意，却是纯粹的技术分析贴，借用一个火锅店的故事，探讨报表查询场景下的延迟问题和一点数据库的特性。 很久之前，有一家老字号的火锅店，顾客盈门，生意红火。涮火锅嘛，大家都知道的，首先是倒入锅底汤料，等汤烧开了，往里面放蔬菜、肉片、海鲜等各种食材，等食材熟了就可以吃了。从食材下锅到吃进嘴里，有个等待的过程，时间的长短取决于两个因素，一是火锅下面的炭是不是充足，火是不是烧得足够旺；二是食材一次不能放太多，特别是一些冷冻状态的食材，否则就会等比较长的时间。 对于BI系统来说，各种食材就是上游系统提供的数据，BI系统的工作就是加工数据并相应客户的查询请求，就是加热食材的过程。BI系统，或者说作为其核心的数据库，就是这个火锅，磁盘大小相当于锅的容量，CPU与内存相当于锅下面的炭火。 这家店比较特别的地方是为了凸显客户的尊贵，食材是由服务员负责放入锅中，食客只管吃。此外，火锅的管理模式是每桌的火锅由一个服务员负责全流程管理，包括火锅的清洗、上菜等等。 不同项目组负责集市的开发过程，运维环节也是由各自的管理员来负责，用户只是最终报表的使用者。 在正常情况下，食材被放入火锅后5分钟就可以吃了，客户很满意。不知什么时候开始，情况了发生变化，食客等待的时间越拖越长。终于有一天，客人午餐点的火锅到了晚餐时间还没吃上，客人很恼火找到老板投诉。 业务用户反映报表查询的速度很慢，而且越来越慢