数据处理圣杯行vs列dat

有争议的是，近几十年来，数据已经成为世界头号资源，取代石油成为最有价值的资产。 然而，只有经过适当的处理，也就是说，以一种动态和高效的方式进行提取、存储和分析，它才可能发挥出全部潜力。 因此，为了收集数据所描述的所有知识，拥有有效的数据处理管道是至关重要的。

在这篇博文中，我们将涵盖使您能够构建高效数据处理机制的基础知识，特别强调分析解决方案。 首先，让我们看看两个主要的数据处理系统。

OLTP在线交易处理是最传统的处理系统。 它能够管理面向事务的应用程序，并且能够以大量短的原子数据库操作为特征，例如 插入、更新和删除，这在您的日常应用中非常常见。 常见的例子包括网上银行和电子商务应用。

OLAP在线分析处理管理历史或档案数据。 它的特点是交易量相对较低。 OLAP系统通常用于分析目的——从大量数据中提取见解和知识，这些数据来自多个来源。 与OLTP不同，OLAP系统的目标是拥有数量有限的事务，每个事务大部分由大块组成 读写。 数据仓库是维护这些系统的典型基础设施。

希望到目前为止，您能够轻松区分两种数据处理系统。 OLTP和OLAP系统已经存在了相当长的一段时间，但是最近，随着数据挖掘和机器学习技术的繁荣，对OLAP系统的需求增加了。 选择合适的技术基础架构来托管任一系统也是确保您的系统或应用程序提供满足您需求的最佳性能的关键一步。

你可能从未听说过这些术语 排 和 圆柱的 与数据库相关联，但你肯定以前见过它们。 面向行的数据库是典型的事务型数据库，能够处理大量事务，而面向列的数据库通常事务较少，数据量较大。

到目前为止，您可能已经猜到哪种类型的数据库更适合每个处理系统。 面向行的数据库通常用于OLTP系统，而柱状数据库更适合OLAP。 一些例子包括:

两种数据存储的主要区别在于它们在磁盘上的物理存储方式。 普通硬盘以块为单位，依靠昂贵的磁头寻道操作。 因此，顺序的 读写 往往比随机访问快得多。

如果可能的话，面向行的数据库将整行存储在同一个块中。 柱状数据库将列存储在后续块中。

亚马逊红移提供了一个简单明了的解释，强调了两个数据库之间的差异。 下图由逐行数据库存储组成，每行存储在一个连续的磁盘块中。 选择理想的块大小对于获得最佳性能非常重要，因为块大小太小或太大会导致磁盘空间使用效率低下。

下图描绘了柱状数据库存储，其中每个磁盘块存储多行的单个列的值。 在本例中，与逐行数据库相比，使用列存储需要三分之一的输入/输出磁盘操作来提取列的值。

让我们看一个简单的例子来充分理解两个数据库之间的差异。

假设一个数据库总共存储100GB的数据，有1亿行和100列(每列1GB(。 为了简化起见，假设数据库管理员是新手，没有在数据库上实现任何索引、分区或任何其他优化过程。 考虑到这一点，对于分析查询:

男性的平均年龄是多少？

我们会有这些可能性:

逐行数据库->必须读取数据库中的所有数据—读取100GB。
列数据库->必须只读取年龄和性别列— 2GB才能读取。

这显然是一个极端的例子——几乎没有任何数据库会完全缺少索引或其他优化过程，但目标是让您对柱状数据库用于分析目的的真正潜力有一个总体了解。

既然您已经对面向行的数据库和列数据库以及它们之间的主要区别有了一个概述，那么强调它们的优点和缺点应该不会太难:

每个人都喜欢理论概念(好吧，至少让我们假设如此)，但是为什么不把它们付诸实践呢？ 考虑到这一点，我们设置了一个实验来比较它们在真实情况下的性能。 为此，我们使用了不同的技术，旨在比较它们在OLTP和OLAP系统上的性能。 选择的技术有:

OLTP

• MongoDB——一个NoSQL数据库，广泛用于多种应用。 擅长交付快速、动态的事务，这得益于其无模式的面向文档的机制。
• PostgreSQL——一个免费的开源数据库，具有广泛的动态性和可扩展性。 使用范围从小型应用程序到数据仓库。
• citus——一款“为横向扩展而打造的无忧Postgre”。 它是一个PostgreSQL扩展，将数据和查询分布在几个节点上。

OLAP

• 由Citus Data开发的开源Postgres扩展，它 变换 将原始的面向行的Postgres数据库转换成列数据库。
• ClickHouse——Yandex最近开发的一个开源柱状数据库。 它声称能够使用类似于SQL的语法提供实时分析数据报告。

为了进行基准测试，我们使用了一个大约有1.35亿条web事件日志记录的数据库，分布在4个不同的表中。 所有这些技术都是在本地使用的，在本地机器上，i5-9600k处理器的时钟频率为3。70千兆赫，32GB内存。

我们进行了一系列典型的查询 分析的 (I .e. 主要关注列而不是行)。 为了使这个过程尽可能均匀，对于我们运行的每个查询，我们都会刷新相应存储引擎的缓存，并在每次切换技术时重新启动机器。

此外，对于逐行数据库，我们为我们创建的查询构建了最高效的索引。 除了在填充这些数据库时默认创建的索引之外，我们没有为列存储建立索引。 结果显示在下表中:

数据库同步软件

通过查看上面的数据，柱状数据库(即e. 与其他技术相比，PostgreSQL的运行时间要短得多。 但是，cstore_fdw对于需要连接表的查询(例如。g. 左连接)并执行文本搜索，如查询Q6和Q7的运行时间所示。

另一方面，到目前为止，ClickHouse的表现超过了每一项技术，尤其是在cstore_fdw的警告方面:连接与文本搜索相结合。 虽然ClickHouse本身不支持连接表，但是使用子查询可以避免这个问题。 下图显示了所有技术及其在分析查询中的性能的比较视图(越低越好)。

您可能还记得我们的第一个比较表，与行数据库相比，列存储改进了压缩机制。 这主要是因为压缩为单个文件的每一列都有唯一的数据类型。 此外，如前一节所述，除了默认为(主键)创建的索引之外，这些数据库没有其他索引。

如下图所示，这些功能允许高效的存储空间，ClickHouse占用10GB的空间，其次是原始数据本身占用76GB的空间，最后是PostgreSQL占用78GB的存储空间。 这比ClickHouse增加了780%。

请注意，对于PostgreSQL(和其他逐行数据库)，除了数据本身占用的空间之外，索引也大大增加了存储空间。

柱状数据库的工作令人难以置信——在几秒钟甚至更短的时间内处理大量数据。 这里有很多例子——红移、大查询、雪花、莫奈数据库、Greenplum、内存SQL、ClickHouse——它们都能为您的分析需求提供最佳性能。

然而，它们的底层架构引入了一个相当大的警告:数据摄取。 它们对于需要实时高吞吐量的混合工作负载性能较差。 换句话说，它们无法与事务数据库的实时数据接收性能相匹配，后者允许将数据快速插入系统。

结合快速摄取和查询是数据处理系统的圣杯。 在这一点上，实现最佳的混合工作负载可能是不可能的，因为没有哪种全能技术在这两方面都有优势。 每个目的都有一个数据库是典型的做法，但是它很大程度上限制了整个系统的性能。

数据处理是一个复杂但非常有趣的技术设计领域。 我们坚信可扩展的实时高通量分析数据库是可能的，但它们并不存在。

然而。