Javascript_tsj的博客

高并发帐户查询的应用场景有很多，例如：手机银行查流水、电商系统查购物订单、手游帐户查充值记录等等。这些场景一般会涉及众多帐户，数据总量非常大，需要外存。每个帐户的数据量通常不大（几条到几千条），而且就是简单查询，几乎没有什么运算。不过，众多的帐户自然也会有大量、高频率的查询，并发访问量会很大，要达到秒级甚至更高的响应速度也是一个不小的挑战。在SQL数据库或数据仓库中，用索引查找单个帐户数据的速度很快，几乎感觉不到耗时，但并发很多时就会有明显延迟了。

多维分析（OLAP）通常要求极高的响应效率，当涉及的数据量很大时，每次都基于明细数据汇总效率就会很低，人们会考虑采用预汇总的方式加快查询速度，即事先将要查询的结果计算好，使用时直接读取预汇总结果就可以获得实时响应，从而满足交互分析的需要。不过，将可能的维度组合全部预汇总不太现实，按中间CUBE大小仅1KB计算50个维度的全量预汇总需要的存储空间高达1MT，需要100百万块1T的硬盘，即使只汇总其中20个维度也要占用470000T的空间（），显然都不能接受。

HTAP（Hybrid Transaction and Analytical Process，混合事务和分析处理）自2014年明确提出以后成为了很多数据库厂商努力的方向。其实HATP并不新鲜，早年RDB刚兴起时本来就是用一个数据库同时做事务和分析，但随着数据规模不断变大再直接基于业务库做分析就会影响业务，这时数据仓库出现了，将业务数据导入数据仓库来专门应对分析需求，同时与业务库隔离，这样不仅可以更好地服务分析场景，又不会对业务系统产生影响，这是“合久必分”的阶段。

应用中怎么实现自助报表功能，最难的地方其实是:怎么找一个功能全面且能集成的工具，这个难题解决后，剩下的具体集成对于工程师来说就不算什么难事了，现在难题也被解决了，站在别人的肩膀上不说看的更高走的更远吧，起码能省很多事了，接下来要做的，就是实际集成一次，亲自验证一下看看到底能不能满足自己的需求了。

SQL可以说是在数据处理和分析领域最常用的程序语言了，有很多想从事这个数据业务但还没入门的同学都在问这个问题。但是，这个问题大概率是个无意义的问题。且听我道来。问这个问题的同学，要先问一下自己，学SQL打算做什么？嗯，希望学会后能写SQL语句做数据分析！这是个很常见的目标，但事情却不是那么简单，因为现实中几乎不存在只要学会SQL语法就能做数据分析的场景。SQL要在数据库里跑，那谁给你安装这个数据库？谁又负责把这些数据给放进去让你查询分析？你查询出来的数据只是看看就完了么？。......

观察一些大型用户的BI系统，经常会发现数据仓库中有很多快照表。如某交易业务的BI系统，交易明细表很大，被按月存储成多个分段表。还有一些相对不太大的表，计算时要和交易明细表关联，比如客户表、雇员表、商品表等等。每个月底，这些表的完整数据都会被存储成快照表，用于匹配当月的交易明细分段表。为什么会有这么多看似很冗余的快照表存在呢？这个交易明细表就是常说的事实表，是用来存储发生事件的数据表，数据量会随着时间不断增长。除了交易明细表之外，订单表、保险单表、银行帐户存取记录表等也都是事实表。......

JOIN 一直是数据库性能优化的老大难问题，本来挺快的查询，一旦涉及了几个 JOIN，性能就会陡降。而且，参与 JOIN 的表越大越多，性能就越难提上来。其实，让 JOIN 跑得快的关键是要对 JOIN 分类，分类之后，就能利用各种类型 JOIN 的特征来做性能优化了。有 SQL 开发经验的同学都知道，绝大多数 JOIN 都是等值 JOIN，也就是关联条件为等式的 JOIN。非等值 JOIN 要少见得多，而且多数情况也可以转换成等值 JOIN 来处理，所以我们可以只讨论等值 JOIN。等值 JOIN 主要又