OLTP和OLAP由于侧重点不同，对数据库和软硬件系统的要求也不同。

当投资有限，无法兼顾时，会有适当的取舍，比如OLTP系统。容量不是第一需求。如果条件允许，磁盘最快，容量小一点也没关系。绝大多数OLTP系统的数据都在100TP以下，甚至有些企业的核心系统为了高性能都控制在10TB以下。

但是OLAP系统会有巨大的体量，100TB只是个开始，PB级的系统随处可见。这个时候，追求盘速就有点太难了。

有了这样的需求，相应的产品自然就诞生了。OLTP领域，由于一般是企业的核心数据，数据库会进一步向高稳定、高并发、高可靠的方向推进，企业的投入会更大。Oracle和Mysql在这个领域基本占优。

相对来说，OLAP领域的空间更大，选择因素也会更多样。有些是通过海量数据预处理快速生成报表，有些是使用大量硬件进行并发处理的MPP数据库。当然，Hadoop也是一种OLAP应用，使用大量集群处理海量数据。

然而，没有什么是绝对的。

我们可能会发现一个100%的OLAP系统，它只处理OLAP的要求，但我们很难说OLTP系统是100%的OLTP。因为，任何一个业务系统，到了一定阶段，都会有一个简单的子系统来处理即时报表。

更有甚者，一些商家带来了大量的统计查询。比如为了索要手机号实名登记制度，甚至控制一人多个号的发生。

一个人新开一个手机号，首先需要统计身份证下全国的电话号码数量，还需要查看之前的号码是否欠费，等等。在我的印象中，曾经有一个用户认证过程，包括多达40+次的验证。

更不用说，还有大量新兴企业，还在快速积累和拓展市场，没有时间和精力去构建企业级的数据仓库系统。

就像我们每次去吃西餐，都会发现面前摆着几把叉子和勺子。大多数人分不清沙拉用哪把叉子。哪个叉子切牛排？西式礼仪固然重要，但很多时候，我们吃西式简餐，还是用刀叉吃全过程。

因为刚才提到的场景并不少见，这就在OLAP和OLTP之间产生了一个灰色区域，以及如何处理它。架构师一般倾向于寻找一个平衡点，将OLTP和OLAP拆分，这将有利于未来整个企业架构，使其更加清晰和可持续。

但是从业务的角度，我希望用最简单的方式直接解决这些即时的分析需求。因此，HTAP应运而生。

在这个过程中，有一个小插曲，因为我们一直说某个数据库适合OLTP，某个数据库适合OLAP。自然会有OLTP数据库和OLAP数据库。这个时候有些数据库也会说我的数据库可以同时支持OLTP和OLAP，所以我们的数据库是HTAP。

当然这个题目是可以理解的，在投入充足的前提下是完全可行的。这个我们后面还会描述，但是目前业界已经确立的HTAP概念仍然是在同一个应用中使用内存技术实现OLTP和OLAP并行的技术。