在业务数据处理的早期，对数据库的写入操作通常对应于正在进行的业务交易——进行销售、向供应商下订单、支付员工工资等。作为数据库扩展到不涉及货币易手的领域，术语交易持续存在，指的是构成逻辑单元的一组读写操作。这些类型的查询称为事务处理查询(OLTP)。为这些查询设计的系统通常是面向用户的，这意味着它们很可能会收到大量请求。为了处理负载，应用程序通常每次查询只接触少量记录。应用程序使用某种键来请求记录，而存储引擎使用索引来查找所请求键的数据。磁盘寻道时间通常是这里的瓶颈。然而，数据库也开始越来越多地用于数据分析，其具有非常不同的访问模式。通常，分析查询需要扫描大量记录，只读取每条记录的几列，并计算汇总统计信息（例如计数、总和或平均值），而不是将原始数据返回给用户。例如，如果您的数据是销售交易表，则分析查询可能是：一月份，我们每家商店的总收入是多少？在最近的促销活动中，我们比平时多卖了多少部iPhone？哪个品牌？哪种牛奶最常与家乐氏玉米片一起购买？这些查询通常由业务分析师编写，并输入报告中以帮助公司管理层做出更好的决策（商业智能）。为了将这种使用数据库的模式与事务处理区分开来，它被称为联机分析处理（OLAP）。它们鲜为人知，因为它们是由业务分析师而不是最终用户处理的。它们处理的查询量比OLTP系统低得多，但每个查询通常要求很高，需要在短时间内扫描数百万条记录。磁盘带宽（不是寻道时间）通常是这里的瓶颈，面向列的存储是此类工作负载越来越流行的解决方案。OLTP和OLAP之间的区别并不总是很清楚，但下面列出了一些典型的特征。首先，使用同一个数据库进行事务处理和分析查询。事实证明，SQL在这方面非常灵活：它适用于OLTP类型的查询和OLAP类型的查询。尽管如此，在80年代末和90年代初，公司倾向于停止使用OLTP系统进行分析，而是在单独的数据库上运行分析。这个单独的数据库称为数据仓库。一个企业可能有几十个不同的交易处理系统：支持面向客户的网站的系统、实体店的销售点（结账）系统、仓库的库存跟踪、车辆路线、供应商管理、劳动力管理等等。其中一个系统很复杂，需要一个团队来维护它，因此这些系统最终会彼此独立运行。通常期望这些OLTP系统具有高可用性并以低延迟处理事务，因为它们通常对业务运营至关重要。因此，数据库管理员严密保护他们的OLTP数据库。他们通常不愿意让业务分析师在OLTP数据库上运行临时分析查询，因为这些查询通常很昂贵，扫描大部分数据集，这可能会损害并发执行事务的性能。数据仓库相比之下，数据仓库是一个独立的数据库，分析师可以在不影响OLTP操作的情况下查询他们的核心内容。数据仓库包含公司所有各种OLTP系统中数据的只读副本。数据从OLTP数据库中提取（使用定期数据转储或连续更新流），转换为易于分析的模式，清理并加载到数据仓库中。将数据放入仓库的过程称为提取-转换-加载(ETL)。现在几乎所有大型企业都有数据仓库，但在小型企业中几乎闻所未闻。这可能是因为大多数小公司没有很多不同的OLTP系统；大多数小公司的数据量都很少——小到可以在常规SQL数据库中查询，甚至可以在电子表格中进行分析。在大公司做一些在小公司很容易的事情需要很多繁重的工作。使用单独的数据仓库进行分析而不是直接查询OLTP系统的一大优势是数据仓库可以针对分析访问模式进行优化。一些数据库，例如MicrosoftSQLServer和SAPHANA，在同一产品中支持事务处理和数据仓库。然而，它们越来越成为两个独立的存储和查询引擎，恰好可以通过一个通用的SQL接口访问。Teradata、Vertica、SAPHANA和ParAccel等数据仓库供应商通常在昂贵的商业许可下销售他们的系统。AmazonRedShift是ParAccel的托管版本。最近出现了很多开源的SQL-onHadoop项目。它们还很年轻，但旨在与商业数据仓库系统竞争。其中包括Apachehive、SparkSQL、ClouderaImpala、FacebookPresto、ApacheTajo和ApacheDrill。其中一些基于GoogleDremel的创意。Analytics的存储架构根据应用程序的需要在事务处理域中使用各种不同的数据模型。另一方面，在分析中，数据模型的多样性要少得多。许多数据仓库以一种相当公式化的方式使用，称为星型模式（也称为维度建模）。通常情况下，事实被捕获为单个事件，因为这可以最大限度地提高以后的分析。但是，这意味着事实表可能会变得非常大。StarsandSnowflakes：“星型模式”这个名字来源于这样一个事实，即在可视化表关系时，事实表位于中间，被其维度表包围；这些桌子像星光一样相连。此模板的变体称为雪花模式，其中维度进一步细分为子维度。Apple、Walmart或eBay等大型企业的数据仓库中可能有数十PB的交易历史记录，其中大部分实际上是表格。列式存储：虽然事实表通常有100多列，但典型的数据仓库查询一次只能访问其中的4或5列。在大多数OLTP数据库中，存储以面向行的方式布局：表的一行中的所有值都彼此相邻存储。要处理诸如“查找商品X在12月的平均销售额”之类的分析查询，面向行的存储引擎仍需要将所有这些行（每行包含100多个属性）从磁盘加载到内存中，解析它们并过滤掉条件不符合您要求的可能需要很长时间。面向列的存储背后的思想很简单：不是将一行中的所有值存储在一起，而是将每一列中的所有值存储在一起。如果每一列都存储在一个单独的文件中，则查询只需要读取和解析该查询中使用的那些列，这样可以节省大量工作。列压缩：与行数相比，列中不同值的数量通常很少（例如，一家零售商可能有数十亿笔销售交易，但只有100,000种不同的产品）。根据列中的数据，可以使用不同的压缩技术——一种在数据仓库中特别有效的技术是位图编码。我们现在可以获取包含n个不同值的列并将其转换为n个单独的位图-每个不同值一个位图，每一行一个位。如果该行具有该值，则该位为1，否则为0。如果n很小（例如，一个国家列可能有大约200个不同的值），这些位图可以每行存储一位。
