「PostgreSQL」用MapReduce的方式思考，但使用SQL

对于那些考虑使用Citus的人来说，如果您的用例看起来很合适，我们通常愿意花一些时间与您一起帮助您了解Citus数据库及其可以提供的性能类型。我们通常与我们的一位工程师进行大约两个小时的配对，以完成此操作。我们将讨论架构，加载一些数据并运行一些查询。如果最后有时间，将相同的数据和查询加载到单节点Postgres中并查看我们如何进行比较总是很有趣。在看了多年之后，我仍然很高兴看到单节点数据库的性能提高了10到20倍，在高达100倍的情况下也是如此。

最好的部分是，它不需要对数据管道进行大量的重新架构。它所要做的只是一些数据建模以及与Citus的并行化。

我们之前已经讨论过这一点，但是获得这些性能提升的首要关键是Citus将您的数据隐藏在更小的，更易于管理的部分。这些碎片（是标准Postgres表）分布在多个物理节点上。这意味着您可以从系统中获得更多的集体能力。当您定位单个分片时，它非常简单：查询被重新路由到基础数据，一旦获得结果，它就会返回它们。

MapReduce已经存在了很多年，并由Hadoop普及。关于大规模数据的问题是为了从中获得及时的答案，您需要对问题进行分解并并行进行操作。或者，您会找到一个非常快的系统。使用更大，更快的设备的问题在于，数据增长超过了硬件改进的速度。

MapReduce本身是一个框架，用于拆分数据，根据需要将数据改组到节点，然后在重新组合结果之前对数据的子集执行工作。让我们举一个例子，例如累计总浏览量。如果我们想在此基础上利用MapReduce，我们会将浏览量分成4个单独的存储桶。我们可以这样做：

for i = 1 to 4:
  for page in pageview:
    bucket[i].append(page)

现在，我们将有4个存储桶，每个存储桶都具有一组网页浏览量。从这里我们可以执行许多操作，例如搜索以找到每个存储桶中最近的10个，或计算每个存储桶中的综合浏览量：

for i = 1 to 4:
  for page in bucket:
    bucket_count[i]++

现在，通过合并结果，我们可以获得页面浏览总数。如果将工作分配到四个不同的节点，则与使用一个节点的所有计算来执行计数相比，可以看到性能大约提高了4倍。

MapReduce在Hadoop生态系统中广为人知，但您不必跳入Java来利用。Citus本身有多个不同的执行器来处理各种工作负载，我们的实时执行器实质上与成为MapReduce执行器是同义的。

如果您在Citus中有32个分片并运行SELECT count（*），我们将其拆分并运行多个计数，然后将最终结果汇总到协调器上。但是，除了计数（*）以外，您还可以做更多的事情，而平均值呢。对于平均值，我们从所有节点和计数中获得总和。然后，我们将总和与计数加在一起，并在协调器上进行最终数学运算，或者您可以将每个节点的平均值求和。实际上，它是：

SELECT avg(page), day FROM pageviews_shard_1 GROUP BY day; average | date ---------+---------- 2 | 1/1/2019 4 | 1/2/2019 (2 rows) SELECT avg(page), day FROM pageviews_shard_2 GROUP BY day; average | date ---------+---------- 8 | 1/1/2019 2 | 1/2/2019 (2 rows)

当我们将以上结果输入表中，然后取它们的平均值时，����,����我们得到：

average | date ---------+---------- 5 | 1/1/2019 3 | 1/2/2019 (2 rows)

请注意，在Citus中，您实际上不必运行多个查询。在后台，我们的实时执行器可以处理它，实际上就像运行一样简单：

SELECT avg(page), day FROM pageviews GROUP BY day; average | date ---------+---------- 5 | 1/1/2019 3 | 1/2/2019 (2 rows)

对于大型数据集，MapReduce中的思路为您提供了无需费力即可获得出色性能的途径。最好的部分可能是您不必编写数百行来完成它，您可以使用与编写相同的SQL来完成。在幕后，我们负责繁重的工作，但是很高兴知道它在幕后如何工作。