|
|
OLTP |
OLAP |
| 概念 |
OLTP即联机事务处理，就是我们经常说的关系数据库，增删查改就是我们经常应用的东西，这是数据库的基础；TPCC(Transaction Processing Performance Council)属于此类。 强调数据库内存效率，强调内存各种指标的命令率，强调并发操作。 |
OLAP即联机分析处理，是数据仓库的核心部心，所谓数据仓库是对于大量已经由OLTP形成的数据的一种分析型的数据库，用于处理商业智能、决策支持等重要的决策信息；数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析，读取较多，更新较少，TPCH属于此类。 随着大数据时代的到来，对于OLAP，列存储模式或者说nosql模式比传统意义的行存储模式可能更具优势。 强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。 |
| 功能 |
日常操作处理 |
分析决策 |
| DB设计 |
面向应用 采用实体-联系ER模型和面向应用的数据库设计 |
面向主题 采用星型或雪花模型和面向主题的数据库设计 |
| 数据 |
当前的，最新的细节的，二维的分立的 |
历史的，聚集的，多维的集成的，统一的 |
| 存取 |
读/写数十条记录 |
读上百万条记录 |
| 工作单位 |
简单事物 |
复杂查询 |
| 用户数 |
上千个 |
上百万个 |
| DB大小 |
100MB-GB |
100GB-TB |
| 时间要求 |
实时性 |
对时间要求不严格 |
| 主要应用 |
数据库 |
数据仓库 |
| 吞吐量 |
小 |
大 |
| 并发访问量 |
非常高 |
不高 |
| 单笔事物的资源消耗 |
小 |
大 |
| SQL语句类型 |
主要是插入和修改操作（DML） |
主要是大量的查询操作或是批量DML操作 |
| 并行技术 |
使用不多 |
大量使用 |
| 物化视图 |
少量使用 |
大量使用 |
| 特点 |
1.实时性要求高。 2.数据量不是很大，生产库上的数据量一般不会太大，而且会及时做相应的数据处理与转移。 3.交易一般是确定的，比如银行存取款的金额肯定是确定的，所以OLTP是对确定性的数据进行存取。 4.高并发，并且要求满足ACID原则。比如两人同时操作一个银行卡账户，比如大型的购物网站秒杀活动时上万的QPS请求。 |
1.实时性要求不是很高，比如最常见的应用就是天级更新数据，然后出对应的数据报表。 2.数据量大，因为OLAP支持的是动态查询，所以用户也许要通过将很多数据的统计后才能得到想要知道的信息，例如时间序列分析等等，所以处理的数据量很大。 3.OLAP系统的重点是通过数据提供决策支持，所以查询一般都是动态，自定义的。所以在OLAP中，维度的概念特别重要。一般会将用户所有关心的维度数据，存入对应数据平台。 |
| 能力评估标准 |
一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。 |
在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。 |
| 瓶颈点 |
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。 |
磁盘子系统的吞吐量则往往取决于磁盘的个数，这个时候，Cache基本是没有效果的，数据库的读写类型基本上是db file scattered read与direct path read/write。应尽量采用个数比较多的磁盘以及比较大的带宽，如4Gb的光纤接口。 |
| 优化思路 |
Cache 和索引。尽量减少表关联，减少分布式事务，OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的系统。 对于数据块来说，应尽可能让数据块保存在内存当中。 在设计上要特别注意，如在高可用的OLTP环境中，不要盲目地把OLAP的技术拿过来用。 |
对于OLAP系统，在内存上可优化的余地很小，增加CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方法，当然这也意味着系统成本的增加。 |
关系
参考文献：
https://www.cnblogs.com/hhandbibi/p/7118740.html
https://www.cnblogs.com/andy6/p/6011959.html
https://blog.csdn.net/zhongguomao/article/details/53769948
https://blog.csdn.net/qq_33414271/article/details/81149966