OLTP:它代表在线事务处理，用于管理当前的日常数据信息。 OLAP:即OnLine Analytical Processing(在线分析处理)，用于维护数据的过去历史，主要用于数据分析，也可称为仓库。

Oltp -主要用于商业交易。用于收集业务数据。在sql中，我们使用插入、更新和删除命令来检索小的数据源。同样，他们是高度正常化的.... OLTP主要用于维护数据的完整性。

Olap -主要用于报告，数据挖掘和业务分析目的。对于大型或批量数据。故意去标准化。它存储历史数据..

区别很简单:

联机事务处理

OLTP是一类促进和管理面向事务的应用程序的信息系统。OLTP也被用来指系统立即响应用户请求的处理。在线事务处理应用程序在数据库管理中具有高吞吐量和插入或更新密集型。OLTP系统的一些例子包括订单输入、零售销售和金融交易系统。

联机分析处理

OLAP是更广泛的商业智能类别的一部分，它还包括关系数据库、报告编写和数据挖掘。OLAP的典型应用包括用于销售、营销、管理报告、业务流程管理(BPM)、预算和预测、财务报告和类似领域的业务报告。

请参阅OLTP和OLAP的详细信息

在这里您将找到OLTP与OLAP更好的解决方案

OLTP (On-line Transaction Processing) is involved in the operation of a particular system. OLTP is characterized by a large number of short on-line transactions (INSERT, UPDATE, DELETE). The main emphasis for OLTP systems is put on very fast query processing, maintaining data integrity in multi-access environments and an effectiveness measured by number of transactions per second. In OLTP database there is detailed and current data, and schema used to store transactional databases is the entity model (usually 3NF). It involves Queries accessing individual record like Update your Email in Company database. OLAP (On-line Analytical Processing) deals with Historical Data or Archival Data. OLAP is characterized by relatively low volume of transactions. Queries are often very complex and involve aggregations. For OLAP systems a response time is an effectiveness measure. OLAP applications are widely used by Data Mining techniques. In OLAP database there is aggregated, historical data, stored in multi-dimensional schemas (usually star schema). Sometime query need to access large amount of data in Management records like what was the profit of your company in last year.

OLTP:它代表在线事务处理，用于管理当前的日常数据信息。 OLAP:即OnLine Analytical Processing(在线分析处理)，用于维护数据的过去历史，主要用于数据分析，也可称为仓库。

很简单的回答:

不同的数据库有不同的用途。我不是数据库专家。 经验法则:

如果你正在做分析(例如聚合历史数据)，请使用OLAP 如果您正在进行交易(例如在电子商务购物车上添加/删除订单)则使用OLTP

简短的回答:

让我们考虑两个示例场景:

场景1:

你正在建立一个在线商店/网站，你希望能够:

存储用户数据，密码，以前的交易… 商店实际产品，其相关价格

您希望能够找到特定用户的数据，更改其名称……基本上是对用户数据进行INSERT、UPDATE、DELETE操作。产品等也一样。

您希望能够进行交易，可能涉及用户购买产品(这是一种关系)。那么OLTP可能很适合。

场景2:

你有一个在线商店/网站，你想计算一些东西，比如

“所有用户的总消费金额” “卖得最多的产品是什么”

这属于分析/商业智能领域，因此OLAP可能更适合。

如果你用“知道如何/多少/多少钱就好了”来思考……，并且涉及到一种或多种类型的所有“对象”(例如，所有用户和大多数产品要知道总花费)，那么OLAP可能更适合。

再答:

当然事情没有这么简单。这就是为什么我们必须首先使用像olttp和OLAP这样的短标记。每个数据库最后都应该独立地进行评估。

那么OLAP和OLTP之间的根本区别是什么呢?

数据库必须在某个地方存储数据。数据的存储方式很大程度上反映了上述数据的可能用途，这不足为奇。数据通常存储在硬盘上。 让我们把硬盘想象成一张非常宽的纸，我们可以在上面读写东西。有两种方法来组织我们的读写，使其高效快速。

One way is to make a book that is a bit like a phone book. On each page of the book, we store the information regarding a particular user. Now that's nice, we can find the information for a particular user very easily! Just jump to the page! We can even have a special page at the beginning to tell us on which page the users are if we want. But on the other hand, if we want to find, say, how much money all of our users spent then we would have to read every page, i.e. the whole book! That would be a row-based book/database (OLTP). The optional page at the beginning would be the index.

Another way to use our big sheet of paper is to make an accounting book. I'm no accountant, but let's imagine that we would have a page for "expenditures", "purchases"... That's nice because now we can query things like "give me the total revenue" very quickly (just read the "purchases" page). We can also ask for more involved things like "give me the top ten products sold" and still have acceptable performance. But now consider how painful it would be to find the expenditures for a particular user. You would have to go through the whole list of everyone's expenditures and filter the ones of that particular user, then sum them. Which basically amounts to "read the whole book" again. That would be a column-based database (OLAP).

由此可见:

OLTP数据库旨在用于处理许多小型事务，通常作为“单一真相来源”。 另一方面，OLAP数据库更适合分析，数据挖掘，查询更少，但它们通常更大(它们操作更多的数据)。

当然，它比这要复杂一些，这是对数据库差异的一个20000英尺的概述，但它使我不会迷失在首字母缩写的海洋中。

说到缩略语:

联机事务处理 联机分析处理

为了进一步阅读，这里有一些相关的链接，它们极大地启发了我的回答:

http://datawarehouse4u.info/OLTP-vs-OLAP.html http://www.ibmsystemsmag.com/Blogs/You-and-i/Archive/db-102-database-orientation-row-vs-column/ http://martinfowler.com/bliki/DataLake.html