数据处理大致可以分成两大类：
- 联机事务处理OLTP（on-line transaction processing）
OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易，资金从A帐户转帐到B帐户，这整个过程就是一次交易事务。如果过程中有任何系统错误，交易会回滚A帐户中的金额都回恢到操作前的状态，这就是OLTP的操作。在OLTP场景中用户并发操作量会很大，要求系统实时进行数据操作的响应，在查询时往往也是只会检索一条或几条明确的目标数据，以实现用户的业务交互。数据量少，DML频繁。
- 联机分析处理OLAP（On-Line Analytical Processing）
OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。如我们的业务系统中每天都需要出销售日报，这个操作需要对当天所有数据进行汇总，并需要进行计算，以得到全天收入、产品销售排名、分时段的销售量，甚至与过去30天及去年当天进行对比，这样的操作都属于OLAP。数据量大，DML少。
已有的两个主流开源数据库，MySQL和PostgreSQL在OLAP应用方面，在线分析的性能明显不足。特别是MySQL在大规模分析操作时多表Join的性能是当前互联网用户的一大痛点。在OLAP发展的早期，其操作并没有专门的数据库支撑，直接就与OLTP业务放在同一个数据库中完成。但随着业务量的增加，OLAP每次要分析的数据量越来越大，这样的分析操作执行时就会导致数据库的业务交易下降。因此业界开始将OLTP、OLAP拆分成两套不同的数据库进行处理，OLTP数据库中的数据通过ETL软件持续或定期抽取到OLAP数据库，让业务交易与报表分析进行分离。Hive是OLAP应用的不错选择。
OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
OLAP 系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区等。
OLAP有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行的语句数量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。
OLTP与OLAP之间的比较：
