数据库架构比较

20世纪90年代，使用MPP架构的Netezza和Teradata的数据库设备对Oracle，IBM和Microsoft在anlytics数据库市场的主导地位提出了挑战，并且随着“大数据”的出现以及带有分布式处理的Hadoop的严峻考验。

在本文中，我将总结架构如何随着时间的推移而发生变化。从单个机器，SMP平台，大规模并行处理（MPP）架构开始，然后是Hadoop / HDFS，以及来自亚马逊，谷歌和Snowflake的新的基于云的解决方案。

我们要解决什么问题？

在其核心，数据库只需要存储数据，以便以后检索。但是，对于大型分析平台，需要考虑许多非功能性需求：

• 性能和响应时间：通常最明显的需求：数据库必须足够快。这是一个刻意模糊的定义，因为如果你正在建立一个在线金融交易系统，50毫秒的响应时间太慢，而大多数用户只能梦想响应时间为1/20秒。适当的解决方案通常由许多因素决定，包括预期数据量，并发用户数和预期的工作负载类型。例如，向50个并发用户提供批量报告的系统将具有与支持10,000个并发用户的亚马逊式电子商务数据库不同的性能配置文件。
• 吞吐量：通常与性能混淆，这表示可以在设定的时间内完成的总工作量。例如，需要转换和查询海量数据量的系统需要以极快的速度处理非常大的数据量。这将导致一种不同的解决方案，其中优先考虑单个查询的快速响应时间。通常，最大化吞吐量的最佳方法是分解大型任务并并行执行各个组件。
• 工作负载管理：这描述了系统在同一平台上处理混合工作负载的能力。这与性能和响应时间有关，因为大多数系统需要在两者之间找到平衡。下图说明了一种典型情况，即系统必须处理吞吐量更重要的大批量批处理操作，以及在线用户的快速响应时间。

• 可伸缩性：系统必须具有增长选项。没有什么能保持不变，如果您的应用程序成功，数据量和用户数量都可能会增长。如果是这样，数据库将需要应对额外的工作量。即使在这个简单的要求中，还有许多其他细节需要决定。数据量增长是相对稳定还是高度不可预测？您是否可以接受停机时间来添加额外的计算资源或存储，还是需要24x7全天候运行？
• 并发：描述系统可以同时支持多个用户的程度。这与可扩展性和性能有关，因为系统必须足够快以快速响应，但也能够处理所需数量的并发用户，而不会显着缩短响应时间。同样，如果用户数超过预定义的限制，我们需要考虑可用于扩展系统的选项。这凸显了可扩展性的重要区别。随着用户数量的增加，处理不断增加的数据量的挑战与维持响应时间的挑战明显不同。我们稍后会看到 - 一种尺寸并不适合所有尺寸。
• 数据一致性：虽然之前的要求可能很明显，但对一致性的需求是一个更细微的要求，人们可能会认为，当然，您需要数据一致性。然而，实际上，对数据一致性的需求是灵活的，并且（例如），在线银行系统可能需要100％保证一致性，而在提供高级管理的报告系统上，一致性和引脚精确度可能不那么重要报告。数据一致性是一个重要的考虑因素，因为它可能会排除使用NoSQL数据库解决方案，因为很少保证一致性。
• 弹性和可用性：描述数据库在组件，机器甚至整个数据中心故障的情况下继续运行的能力，并且弹性水平由可用性需求决定。例如，网上银行系统可能需要99.999％的时间可用，这使得每年停机时间可能超过五分钟。这意味着高弹性（并且可能是昂贵的）解决方案，而允许在周末停机的系统有更多选择。下图说明了一种常见的解决方案，即写入主系统的事务会自动复制到内置自动故障转移的非现场备用系统。

• 可通过SQL访问：虽然不是绝对的要求，但SQL语言已存在了四十多年，并被数百万开发人员，分析师和业务用户使用。尽管如此，一些NoSQL数据库（例如HBase和MongoDB）本身并不支持使用SQL进行访问。虽然有几种可用的螺栓固定工具，但这些数据库与更常见的关系数据库根本不同，并且（例如）不支持关系连接，事务或即时数据一致性。

选项1：SMP硬件上的关系数据库

自20世纪80年代初以来，市场一直由甲骨文，微软和IBM主导，他们提供了旨在满足上述要求的通用解决方案。底层硬件和数据库系统架构最初是在20世纪70年代开发的，它基于对称多处理（SMP）硬件，其中许多物理处理器（或核心）使用共享内存和磁盘执行指令。

上面的屏幕截图显示了Windows任务管理器，它显示了八个处理器在SMP数据库服务器上执行指令。基于SMP的数据库解决方案具有以下优点和缺点：

优点

• 它的工作原理：它是一种经过战斗强化，经过验证的架构，部署成本相对较低，可以运行从大型服务器到中型商用硬件的各种设备。它在提供合理的性能和吞吐量方面拥有良好的记录。
• 它是同构的：这意味着为这个平台设计的数据库几乎可以在任何硬件上运行。由于它基于多个核心，因此可以是物理或逻辑，也可以是在云平台上的虚拟服务器上运行的选项。
• 数据一致性：下图说明了此体系结构的基本特性 - 连接到本地或网络连接磁盘的单台计算机。实际上，有一份数据副本，因此数据一致性不是挑战; 它在分布式系统上。这与许多NoSQL解决方案相比较，在这些解决方案中，数据不一致的风险以最大响应时间进行交易。

缺点

虽然这是一种流行且广泛部署的架构，但它确实存在以下缺点：

• 难以扩展：虽然可以添加CPU，内存或其他磁盘，但实际上可扩展性有限，并且很可能在几年内需要用更大的机器替换系统。
• 最大大小：由于扩展难度大，因此大多数架构师将SMP平台的大小调整为最大预测工作负载。这意味着支付比最初需要的更多的处理能力，而随着时间的推移，随着更多负载的增加，性能逐渐降低。更好的解决方案将允许随着时间的推移逐步添加计算资源。
• 低效缩放：添加额外或更快的CPU很少会提高线性规模的性能。例如，除非系统完全受CPU限制，否则添加速度提高100％的处理器的性能将提高一倍。在大多数情况下，瓶颈转移到另一个组件，并且不可能线性增加容量。
• 工作负载管理：根据数据库解决方案和硬件，基于SMP的系统可以提供合理的性能或吞吐量 - 很少同时提供。与MPP平台一样，许多解决方案都在努力平衡快速响应时间和高批量吞吐量的竞争需求。下图说明了一种常见方法，即面向客户的在线事务处理（OLTP）系统可提供快速响应时间，同时定期将数据传送到用于联机分析处理（OLAP）的单独数据仓库平台。虽然Oracle声称要解决在内存中使用Oracle12c组合OLTP和OLAP的挑战，但实际上，这是有限的中小型应用程序。

• 弹性和可用性：由于SMP系统使用单一平台，因此需要扩展该解决方案，以便在组件或整个数据中心发生故障时提供弹性。这通常会使这个选项变得昂贵，尽管（理论上）它可以部署在廉价的商用服务器上，实际上，它通常部署在具有双冗余磁盘，网络连接和电源的企业级硬件上。虽然这为组件故障提供了弹性，但该解决方案还需要一个单独的备用系统来保证高可用性。

选项2：MPP硬件上的关系数据库

1984年，Teradata使用大规模并行处理（MPP）架构交付了第一个生产数据库，两年后，福布斯杂志将Teradata命名为“年度产品”，因为它生产了第一个TB级生产数据库。此架构后来被Netezza，Microsoft并行数据仓库（PDW）和HP Vertica等采用。如今，Apple，Walmart和eBay 经常在MPP平台上存储和处理数 PB的数据。

下图提供了MPP体系结构的图示，其中协调SMP服务器接受用户SQL语句，这些语句分布在多个独立运行的数据库服务器上，这些服务器一起作为单个集群机器运行。每个节点都是一台独立的计算机，具有自己的CPU，内存和直接连接的磁盘。

使用此解决方案，在加载数据时，可以使用一致的散列算法来均匀地分布数据，这些（如果一切顺利）将导致跨集群的工作的均衡分布。MPP体系结构是数据仓库和分析平台的出色解决方案，因为查询可以分解为组件部分，并在服务器之间并行执行，从而显着提高性能。

但是，与SMP系统不同，数据放置在磁盘级别是自动进行的，因此最大限度地提高吞吐量和响应时间至关重要。下图说明了可用的三种MPP数据分配方法。

选项包括：

• 复制：通常用于相对较小的表，使用此方法，数据在群集中的每个节点上都会重复。虽然这看起来很浪费，但我自己在几个多TB的仓库上经验表明，通常会有大量的小型参考和维度表，这些表通常与一个大得多的事务或事实表相结合。此参考数据非常适合复制方法，因为它意味着它可以在群集中的每个节点上本地和并行连接，从而避免节点之间的数据混洗。
• 一致哈希：通常用于较大的事务或事实表，并涉及生成可重现的密钥以将每行分配给群集中的适当服务器。此方法可确保群集上的均匀负载，但不正确选择群集密钥可能会导致热点，这在某些情况下可能会显着限制性能。
• 循环：此方法涉及以循环方式依次编写下一个节点上的每一行，并且通常仅用于临时登台表，这些表将仅被写入和读取一次。它的优点是保证数据均匀分布，因此同样可以查询负载，但除非所有相关的参考数据表都复制到每个节点，否则这是一个很差的解决方案。

优点

与SMP解决方案相比，MPP架构具有几个明显的优势，其中包括：

• 性能：这是MPP系统真正擅长的领域。提供的数据和处理可以在群集中的节点之间并行地均匀执行，即使是最大的SMP服务器，性能也会显着增加。

“通过大规模并行处理（MPP）设计，查询通常比在对称多处理（SMP）系统上构建的传统数据仓库快50倍”。-微软公司。

• 可伸缩性和并发性：与SMP解决方案不同，基于MPP的系统可以选择逐步添加计算和存储资源，并且吞吐量大大提高了算术速率。添加额外的相同大小的节点可以提高系统处理其他查询的能力，而不会显着降低性能。
• 成本和高可用性：一些基于MPP的数据仓库解决方案旨在在廉价的商用硬件上运行，而无需可能包含成本的企业级双冗余组件。这些解决方案通常使用自动数据复制来提高系统弹性并确保高可用性。这可以非常有效地利用资源，并且避免了许多基于SMP的解决方案所使用的大量未使用的热备用的成本。
• 读写吞吐量：当数据分布在整个系统中时，该解决方案可以实现非常高的吞吐量，因为读写操作可以在集群中的独立节点上并行执行。

缺点

虽然MPP系统比传统的SMP架构具有引人注目的优势，但它们确实存在以下缺点：

• 复杂性和成本：虽然表面上的架构看起来很简单，但精心设计的MPP解决方案隐藏了大量复杂性，Teradata和Netezza最早的商用MPP数据库系统作为硬件设备以极高的成本交付。但是，随着这种架构在大型分析平台上越来越受欢迎，价格开始变得缓和。
• 数据分布至关重要：与磁盘级数据放置简单且可自动化的SMP解决方案不同，MPP平台需要仔细设计数据分布，以避免数据偏差导致处理热点。例如，如果选择了差的分发密钥，这可能导致少量节点过载而其他节点闲置，这将限制整体吞吐量和查询响应时间。同样，如果未使用关联的事务数据正确放置引用表，则可能导致过多的数据重排从而在节点之间传输数据以完成连接操作，这又可能导致性能问题。这在下图中说明，其中参考数据在两个节点之间混洗。虽然可以解决问题，但通常需要大量的数据重组工作，以及潜在的系统停机时间。

• 需要停机：虽然一些MPP解决方案具有内置的弹性和高可用性，但许多需要停机或降低性能以支持添加新节点。在某些情况下，必须使整个群集脱机以添加其他节点，即使不需要这些节点，添加节点通常也涉及跨群集重新分发数据以利用其他计算资源。对于某些客户而言，这可能不是理想的甚至是可行的选择。
• 缺乏弹性：尽管可以扩展MPP系统，但这通常涉及新硬件的调试和部署，这可能需要数天甚至数周才能完成。这些系统通常不支持弹性 - 根据需要扩展或减少计算资源以满足实时处理要求的能力。
• 仅横向扩展：为了避免系统不平衡，通常只有添加完全相同规格，计算能力和磁盘存储的节点才是明智的。这意味着，尽管添加其他节点会增加并发性（其他用户查询数据的能力），但不可能显着增加批量吞吐量。简而言之，虽然可以扩展，但很少有选项可以将解决方案扩展到功能更强大的系统。
• 潜在的容量：理论上，MPP系统是完美平衡的，因为额外的节点将存储和计算资源添加到集群。但是，由于存储需求超出了对计算容量的需求，因此存储需求超出计算容量需求，因此每TB的成本不成比例地增加，所以总拥有成本可能会很高。这在Data Lake解决方案的普及中尤其普遍，它可能存储大量不经常访问的数据。总之，使用纯MPP解决方案，您可以支付比实际需要多300倍的计算处理。

“在分析MPP平台上，数据量[可以]不成比例地增长到分析工作负载（我们的研究显示在某些情况下差异高达300：1）” - Tripp Smith，CTO Clarity Insights。

选项3：使用SQL over HDFS的Hadoop

下图说明了2010 - 15年间对大数据的兴趣不可避免的增长。这显然涉及数据库供应商，包括成为Hadoop平台供应商的IBM 和开发大数据设备的 Oracle 。

在此期间，关于数据仓库是否已经死亡以及Hadoop是否会取代 MPP平台的讨论很多，尽管普遍的共识似乎表明Hadoop充其量只是数据仓库的补充技术; 不是它的替代品。

什么是Hadoop？

与MySQL和PostgreSQL（开源数据库）不同，Hadoop不是单一产品，而是相关项目的开源生态系统。截至2018年9月，这包括150多个项目 ，其中包含12个用于SQL over Hadoop和17个数据库的独立工具。为了说明生态系统的规模，亚马逊英国出售了超过1,000种不同的Hadoop技术书籍，其中许多只涉及一个工具，包括超过750页的Hadoop The Definitive Guide。

下图说明了一些关键组件和Hadoop分发器，每个组件都需要在时间和专业知识方面进行大量投资才能充分利用。

主要用例

Hadoop是一个庞大的主题，很难在一篇简短的文章中总结，但它解决的主要问题包括：

1. 大容量数据存储和批处理： Hadoop和主数据存储系统（Hadoop分布式文件系统 - HDFS）通常被推广为廉价的数据存储解决方案和Data Lake的合适平台。鉴于它能够扩展到数千个节点，它可能非常适合使用基于SQL的Apache Hive over HDFS 进行大规模批量数据处理。
2. 实时处理：虽然HDFS最适合运行数小时的大批量流程，但其他组件（包括Kafka，Spark Streaming，Storm和Flink）专门设计用于提供微批量或实时流式传输解决方案。随着物联网（IoT）行业越来越多地提供数百万需要实时或接近实时数据分析和响应的嵌入式传感器的实时结果，预计这将变得越来越重要。
3. 文本挖掘和分析： Hadoop平台强大的另一个领域是它能够处理包括文本在内的非结构化数据。虽然传统数据库适用于行和列中的结构化数据，但Hadoop包含用于分析非结构化文本字段含义的工具，例如，在线产品评论或可以挖掘用于情绪分析的Twitter订阅源。

上述用例通常被描述为Three V's：DataVolume，Velocity和Variety。

Hadoop / HDFS架构

作为本文关于数据库体系结构的重点，我将重点介绍批处理用例。在我的文章Big Data: Velocity in Plain English中单独描述了一种潜在的实时处理架构。

在第一印象中，Hadoop / HDFS架构似乎与MPP架构类似，下图说明了相似性。

上图显示了如何使用SQL正常处理数据。的名称服务器充当目录查找服务给客户端指向时将被存储或从查询的数据的节点（S），否则，它看起来非常类似于一个MPP架构。

然而，最大的单一差异是，虽然MPP平台在群集中分配单个行，但Hadoop只是将数据分成任意块， Cloudera建议将其大小调整为128Mb，然后将其复制到至少两个其他节点以恢复弹性如果节点发生故障。

这很重要，因为它意味着小文件（任何小于128Mb）完全保存在一个节点上，甚至一个千兆字节大小的文件也只分布在8个节点（加上副本）上。这很重要，因为Hadoop旨在处理非常大的数据集和大型集群。但是，由于小表分布在较少的服务器上，因此对于小于50-100Gb的数据文件来说并不理想。

处理小数据集对Hadoop来说是一个挑战，因为在更糟糕的情况下，单个节点上的处理数据完全按顺序运行，没有任何并行运行。实际上，由于许多Hadoop集群倾向于使用大量相对较慢且廉价的商用服务器，因此小数据的性能确实很差。此外，随着小文件数量的增加，名称服务器的管理也越来越成为问题。

为了说明这一点，我的经验表明，在大多数中档数据仓库平台（大约10Tb数据）上，只有大约10％的表保存超过100Gb的数据，70％的表保持不到1Gb。即使两个最大的表超过1Tb，这些也不适合在Hadoop上部署。

“大多数希望Hadoop取代他们的企业数据仓库的人都非常失望” - 詹姆斯塞拉 - 微软

优点

Hadoop / HDFS架构作为数据存储和处理平台具有以下优势：

• 批处理性能： Hadoop是处理非常大的数据集时实现高吞吐量的绝佳选择，尽管处理使用需要并行执行多个节点的作业的强力方法。
• 可扩展性：与MPP系统类似，可以添加额外的节点来扩展Hadoop集群，集群可以达到最多。在某些情况下有5,000个节点。
• 可用性和弹性：随着数据自动复制（复制）到多个服务器，弹性和高可用性都是透明的并且内置。这意味着（例如），生产中可以使节点脱机进行维护而不会中断服务。
• 成本（硬件和许可证）：由于Hadoop倾向于部署在运行开源软件的廉价商用服务器上，因此硬件和许可证的成本可能远低于传统的企业级数据仓库设备和相关的许可证成本。

缺点

由于具有令人信服的成本和批处理性能优势，Hadoop通常被提升为数据仓库的替代品。但是，我建议谨慎，原因如下：

• 管理复杂性：如上所述，Hadoop不是单一产品，而是一个庞大的软件生态系统，部署通常需要熟练掌握一系列工具，包括HDFS，Yarn，Spark，Impala，Hive，Flume，Zookeeper和Kafka。对于整个业务管理数据的组织（例如Facebook或LinkedIn），Hadoop可能是一个明智的选择。但是，对于许多客户而言，最好避免使用支持数据库解决方案的分析平台。即使是大规模的MPP解决方案，部署和维护也比Hadoop简单得多。
• 不成熟的查询工具：关系数据库管理系统包括数十年的自动查询调优经验，可以高效地执行复杂的SQL查询。但是，大多数基于Hadoop的SQL工具都没有达到所需的复杂程度，并且通常依赖暴力来执行查询。这导致机器资源的低效使用，基于云的（按需付费）基础可能很快变得昂贵。
• 小文件问题：虽然非常大的数据处理的吞吐量在并行完全执行时可以是高效的，但是处理相对较小的文件会导致非常差的查询响应时间。
• 数据混洗：与MPP解决方案不同，MPP解决方案的数据可以通过一致的散列密钥或数据复制来共存，因此没有选项可以在Hadoop节点上放置数据。这意味着跨多个表的连接操作（按设计）在整个群集中随机分布，可能导致大规模的数据重组和可能出现严重的性能问题。这在下图中说明。

• 低延迟查询性能差：虽然数据缓存解决方案可能有所帮助，但Hadoop / HDFS对于低延迟查询来说是一个非常糟糕的解决方案，例如，将数据提供给仪表板。同样，这与主要设计为使用强力批处理服务非常大的数据集的体系结构有关。
• 其他缺点：与MPP平台中描述的缺点类似，此解决方案缺乏弹性，无法扩展，以及计算资源极度过剩的可能性，尤其是在用作Data Lake时。

关于为什么Hadoop是一个不适合市场的解决方案的优秀演讲，请观看图灵奖章获得者Michael Stonebraker博士的讲座 - 大数据（至少）有四个不同的问题。

选项4：EPP：弹性并行处理

类似于MPP解决方案，其中许多独立运行的无共享节点并行存储和处理查询，EPP（弹性并行处理）架构提供了令人印象深刻的可伸缩性水平。

但是，与数据存储直接连接到每个节点的MPP集群不同，EPP架构将计算和存储分开，这意味着每个节点可以独立缩放或弹性缩小。

如下图所示：

在上图中，长期存储由存储服务提供，该存储服务 从群集中的每个节点都可见。查询将提交给服务层，服务层 负责整体查询协调，查询调优和事务管理，并在计算层上执行实际工作- 实际上是MPP集群。

虽然计算层通常直接连接磁盘或快速SSD用于本地存储，但使用独立存储服务层意味着数据存储可以独立于计算容量进行扩展。这意味着可以弹性调整计算群集的大小，提供MPP架构的所有优势，同时在很大程度上消除了许多缺点。

截至2018年，有几个分析平台（在不同程度上）可以被描述为支持弹性并行处理，其中包括来自Snowflake Computing，Microsoft，HP，Amazon和Google的解决方案。

“新的云架构和基础架构挑战了关于大数据和并置存储和计算的传统思维”。 - Tripp Smith - CTO Clarity Insights。

Snowflake：弹性数据仓库

在Snowflake弹性数据仓库是目前真正的弹性EPP分析平台的目前最好的例子，本节将介绍该解决方案的优点。

下图说明了Snowflake数据仓库即服务解决方案的独特优势之一。不是通过共享存储服务支持单个MPP集群，而是可以启动多个独立的计算资源集群，每个集群的大小和操作都是独立的，但是可以从公共数据存储中加载和查询数据。

这提供的巨大优势之一是卓越的敏捷性，包括按需启动，暂停或调整任何群集的选项，无需停机或对当前正在执行的工作负载产生影响。根据需要，在已调整大小（更大或更小）的群集上自动启动新查询。

下图说明了另一个关键优势，即可以在同一个共享数据存储上独立执行潜在的竞争工作负载，大吞吐量工作负载并行运行，针对相同数据的低延迟，快速响应时间查询。这只能通过在单个共享数据存储上运行多个计算资源的独特能力来实现。

由于Snowflake可以部署多个独立的计算资源集群，因此几乎在所有其他SMP，MPP或EPP系统上都可以找到低延迟和高吞吐量工作负载之间的拉锯战。这意味着您可以在与批量ETL加载完全相同的数据上运行具有密集数据科学操作的真正混合工作负载，同时还为业务用户仪表板提供亚秒响应时间。如下图所示：

最后，由于存在多个集群，因此可以在不停机或对性能产生影响的情况下即时扩展和扩展解决方案。与某些EPP解决方案不同，Snowflake提供真正的弹性，并且可以从双节点增长到128节点集群，并且可以在不中断服务的情况下再次返回。

优点

EPP解决方案具有与上述MPP架构类似的优点，但没有许多缺点。这些包括：

• 可扩展性和并发性：除了能够扩展外，通过添加额外的计算节点，EPP系统可以扩展以执行要求越来越高的工作负载，或添加额外的相同大小的节点以在用户数量增加的同时保持并发性。
• 成本和高可用性：某些EPP解决方案可以部署在本地，混合或云环境中。无论哪种方式，在许多情况下，解决方案可以配置为根据需要提供高可用性和自动故障转移。如果部署到云环境，还可以选择关闭或挂起数据库以控制成本，并在需要时重新启动。
• 读写吞吐量：由于EPP系统实际上是一个具有独立计算和存储的MPP解决方案，因此它们在吞吐量方面具有与MPP相同的优势，但具有可扩展性和弹性的额外优势。
• 数据分布不太重要：在某些情况下（例如Snowflake），数据分布是可选的，以便在处理非常大（超过1TB）的数据集时最大化吞吐量，而在其他平台（例如Microsoft或Amazon Redshift）上，它更多设置正确的分配密钥以避免数据混乱很重要。
• 潜在的零停机时间：与MPP解决方案（通常需要停机时间来调整群集大小）不同，EPP解决方案可以（例如使用Snowflake）即时扩展或缩小群集大小，停机时间为零。除了自动添加或删除节点以自动调整所需的并发级别之外，还可以按需增大或缩小计算资源。在其他解决方案（例如Redshift）上，系统需要在调整大小操作期间重新启动到只读模式。
• 扩展所有三个维度：与MPP解决方案不同，MPP解决方案通常仅支持横向扩展（添加相同大小的节点），EPP解决方案可以独立扩展计算和存储。此外，还可以扩展到更大（更强大）的群集，或者从群集中添加或删除节点。该架构在三个维度上的独特能力如下图所示。这表明群集可以按比例放大以最大化吞吐量，扩展以在添加其他用户（并发）时通过添加数据存储来维持约定的响应时间。

• 正确尺寸的硬件和存储：与SMP系统（其大小往往不灵活）以及Hadoop和MPP解决方案（可能存在过度配置计算资源的风险）不同，可以调整EPP平台以适应问题的大小。这意味着可以将小型集群安装在数PB的数据上，或者根据需要在较小的数据集上运行大型强大的系统。

总结和结论

本文总结了用于支持大型分析或商业智能平台的主要硬件架构，包括SMP（具有多个处理器的单个节点），MPP（具有并行数据加载和分布式查询处理的多个节点），以及最终EPP（弹性并行处理） ，它解决了MPP平台的许多缺点，并支持真正的弹性和灵活性。

许多数据库供应商已经部署或拥有EPP架构解决方案，包括Amazon Redshift，Google BigQuery，HP Vertica和Teradata，尽管到目前为止，只有一个解决方案Snowflake提供全面的弹性和按需灵活性，零停机解决方案使用多个独立的集群。

虽然Hadoop可能声称对传统数据库提出了挑战，但实际上，系统复杂性和计算过度配置的缺点使得这对于分析平台来说是一个糟糕的解决方案。但是，Hadoop确实提供了一个出色的框架来提供实时处理和文本分析。

无论哪种方式，我都坚信敏捷性和成本控制的强大优势将意味着越来越多的分析，实际上所有的计算处理最终都将在云中执行。我还相信EPP架构是支持分析工作负载的最佳方法，尤其是在基于云的情况下。

您可以阅读免费电子书，云数据仓库平台的比较的市场中部选项的比较，尽管几乎任何解决方案架构师都会证明，验证某个特定平台是否适合您的使用的最佳方法是 -案例是使用概念证明进行测试。

谢谢

感谢您阅读本文。

原文标题《Database Architectures Compared》

作者：John Ryan

译者：February

不代表云加社区观点，更多详情请查看原文链接