关于postgresql分片的信息

「PostgreSQL架构」为什么RDBMS是分布式数据库的未来

大约10年前，我加入了Amazon Web Services，在那里我第一次看到了在分布式系统中进行权衡的重要性。在大学里，我已经了解了一致性和可用性之间的权衡（CAP定理），但实际上，频谱要比这深得多。任何设计决策都可能涉及延迟，并发性，可伸缩性，耐用性，可维护性，功能性，操作简便性以及系统其他方面之间的权衡，而这些权衡会对应用程序的功能和用户体验产生有意义的影响，并且即使是业务本身的有效性。

也许在权衡需求最明显的分布式系统中最具挑战性的问题是构建分布式数据库。当应用程序开始需要可以在许多服务器上扩展的数据库时，数据库开发人员开始做出极端的权衡。为了在许多节点上实现可伸缩性，分布式键值存储（NoSQL）抛弃了传统关系数据库管理系统（RDBMS）提供的丰富功能集，包括SQL，联接，外键和ACID保证。由于每个人都想要可伸缩性，因此RDBMS消失只是时间问题，对吗？实际上，关系数据库继续主导着数据库领域。这就是为什么：

在分布式系统（或任何系统）中进行权衡时，要考虑的最重要方面是开发成本。

数据库软件所做出的权衡将对应用程序的开发成本产生重大影响。在高级应用程序中处理需要可用性，可靠性和性能的数据是一个固有地需要解决的问题。成功解决每个小问题所需的工时数量可能很大。幸运的是，数据库可以解决许多这些子问题，但是数据库开发人员也面临成本问题。实际上，要使数据库足以满足大多数应用程序的功能，保证和性能，就需要数十年的时间。那就是建立关系数据库如PostgreSQL和MySQL的地方。

在Citus Data，我们从不同角度解决了数据库可伸缩性的需求。我和我的团队在过去的几年中花费了很多时间将已建立的RDBMS转换为分布式数据库，而又不会失去其强大功能或从基础项目中分叉。通过这样做，我们发现RDBMS是构建分布式数据库的理想基础。

使RDBMS对开发应用程序（尤其是开源RDBMS，尤其是云RDBMS）如此吸引人的原因在于，您可以有效地利用数十年来对RDBMS进行的工程投资，并利用这些RDBMS功能。您的应用，降低了开发成本。

RDBMS为您提供：

这些功能几乎对任何非平凡的应用都很重要，但是要花很长时间才能开发。另一方面，某些应用程序的工作量对于单台计算机来说太过苛刻，因此需要水平可伸缩性。

许多新的分布式数据库正在开发中，并且正在分布式键值存储（“ NewSQL”）之上实现RDBMS功能，例如SQL。尽管这些较新的数据库可以使用多台计算机的资源，但是在SQL支持，查询性能，并发性，索引，外键，事务，存储过程等方面，它们仍远未建立在关系数据库系统上。您遇到许多要在应用程序中解决的复杂问题。

许多大型互联网公司采用的替代方法是RDBMS的手动，应用程序层分片（通常是PostgreSQL或MySQL）。手动分片意味着有许多RDBMS节点，并且应用程序会根据某种条件（例如，用户ID）决定连接到哪个节点。应用程序本身负责如何处理数据放置，架构更改，查询多个节点，复制表等，因此，如果执行手动分片，最终将在应用程序中实现自己的分布式数据库，这可能甚至更多。昂贵。

幸运的是，有一种方法可以解决开发成本难题。

PostgreSQL已有数十年的发展 历史 ，其令人难以置信的重点是代码质量，模块化和可扩展性。这种可扩展性提供了一个独特的机会：无需分叉就可以将PostgreSQL转换为分布式数据库。这就是我们构建Citus的方式。

大约5年前，当我加入一家名为Citus Data的初创公司时，我为在竞争激烈的市场中建立高级分布式数据库而无任何现有基础架构，品牌知名度，进入市场，资本或大量工程师的挑战感到沮丧 。 仅开发成本就似乎是无法克服的。 但是，就像应用程序开发人员利用PostgreSQL来构建复杂的应用程序一样，我们利用PostgreSQL来构建……分布式PostgreSQL。

我们创建了Citus，这是开源的PostgreSQL扩展，而不是从头开始创建分布式数据库，它以提供水平扩展的方式透明地分发表和查询，但是应用程序开发人员需要具备所有PostgreSQL功能才能成功。

通过使用在计划查询时Postgres调用的内部挂钩，我们能够将分布式表的概念添加到Postgres。

分布式表的分片存储在具有所有现有功能的常规PostgreSQL节点中，Citus发送常规SQL命令以查询分片，然后合并结果。 我们还添加了参考表的概念，该参考表可在所有节点上复制，因此可以通过任何列与分布式表连接。 通过进一步增加对分布式事务，查询路由，分布式子查询和CTE，序列，更新等的支持，我们达到了最先进的PostgreSQL功能可以使用的规模，但现在已经可以大规模使用。

Citus相对来说还很年轻，但是已经建立在PostgreSQL之上，已经成为世界上最先进的分布式数据库之一。与PostgreSQL的完整功能集相比，这令人毛骨悚然，还有许多工作要做，Citus现在提供的功能及其扩展方式使其在分布式数据库环境中具有很大的独特性。许多当前的Citus用户最初使用Postgres中的许多高级功能在单节点PostgreSQL服务器上建立业务，然后仅用几周的开发工作就迁移到Citus，以将其数据库模式转换为分布式表和引用表。对于任何其他数据库，从单节点数据库到分布式数据库的这种迁移可能要花费数月甚至数年的时间。

像PostgreSQL这样的RDBMS具有几乎无限的功能和成熟的SQL引擎，可让您以多种方式查询数据。当然，这些功能只有在速度很快时才对应用程序有用。幸运的是，PostgreSQL很快，并且通过诸如实时查询编译之类的新功能不断提高，但是当您拥有大量数据或流量以至于一台机器速度太慢时，那些强大的功能就不再那么有用了……除非您可以结合许多计算机的计算能力。这就是功能成为超级大国的地方。

通过采用PostgreSQL功能并进行扩展，Citus具有许多超级功能，这些功能使用户可以将数据库扩展到任意大小，同时保持高性能及其所有功能。

尽管大多数这些功能对于开发需要扩展的复杂应用程序来说似乎都是必不可少的，但并不是所有分布式数据库都支持它们。下面我们根据公开提供的文档对一些流行的分布式数据库进行比较。

与在分布式数据库中拥有超级功能相比，更重要的是能够组合数据库超级功能来解决复杂的用例。

由于支持查询路由，参考表，索引，分布式事务和存储过程，因此即使最先进的多租户OLTP应用程序（例如Copper）也可以使用Citus扩展到单个PostgreSQL节点之外，而不会在应用程序中做出任何牺牲。

如果将子查询下推与并行的分布式DML结合使用，则可以在数据库内部转换大量数据。一个常见的示例是使用INSERT…SELECT构建汇总表，该表可以并行化以适应任何类型的数据量。结合通过COPY，索引，联接和分区进行的批量加载，您将拥有一个非常适合时间序列数据和实时分析应用程序（如Algolia仪表板）的数据库。

正如Microsoft的Min Wei在谈到Microsoft如何使用Citus和PostgreSQL分析Windows数据时指出的那样：Citus使您能够使用分布式OLTP解决大规模OLAP问题。

Citus与其他分布式数据库有些不同，后者通常是从头开始开发的。 Citus没有引入PostgreSQL中尚未提供的任何功能。 Citus数据库以满足需要扩展的用例的方式扩展了现有功能。重要的是，大多数PostgreSQL功能已经针对各种用例进行了数十年的开发和测试，而当今用例的功能要求最终并没有太大不同；主要是数据的规模和大小不同。因此，在构建现代应用程序时，基于世界上最先进的开源RDBMS（PostgreSQL！）构建的分布式数据库（如Citus）可以成为您的武器库中最强大的工具。

原文：

本文：

讨论：请加入知识星球或者微信圈子【首席架构师圈】

相关问答

Q1: 什么是一个好办法，在PostgreSQL的水平片段

PostgreSQL允许划分两种不同的方式.a个是由范围，而另一个是由列表。表继承做分区。 通过分区范围，通常一个日期范围，是但通过分区列表可以的，如果是这样的分区变量是静态的，没有歪斜。 分区是通过表继承这样做的优先件事就是建立新的子表。

CREATE TABLE measurement (

x int not null,

y date not null,

z int

);

CREATE TABLE measurement_y2006 (

CHECK ( logdate = DATE '2006-01-01' AND logdate DATE '2007-01-01' )

) INHERITS (measurement);

CREATE TABLE measurement_y2007 (

CHECK ( logdate = DATE '2007-01-01' AND logdate DATE '2008-01-01' )

) INHERITS (measurement);

那么无论是规则或触发器需要删除该数据在正确的表格。 规则是更快的批量更新，单触发更新 CodeGo.net，以及更易于维护。下面是一个示例触发。

CREATE TRIGGER insert_measurement_trigger

BEFORE INSERT ON measurement

FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();

和触发函数来进行插入

CREATE OR REPLACE FUNCTION measurement_insert_trigger()

RETURNS TRIGGER AS $$

BEGIN

IF ( NEW.logdate = DATE '2006-01-01'

AND NEW.logdate DATE '2007-01-01' ) THEN

INSERT INTO measurement_y2006 VALUES (NEW.*);

ELSIF ( NEW.logdate = DATE '2007-01-01'

AND NEW.logdate DATE '2008-01-01' ) THEN

INSERT INTO measurement_y2006m03 VALUES (NEW.*);

ELSE

RAISE EXCEPTION 'Date out of range.';

END IF;

RETURN NULL;

END;

$$

LANGUAGE plpgsql;

这些例子是简化了的PostgreSQL版本，以便于阅读。 我不熟悉pgpool2，但gridsql是专为EnterpriseDB公司，这是建立在PostgreSQL的顶部数据库的产品。他们的产品是非常好的，但我不认为它会工作在标准postgresl。

2. 那么，如果问题是关于分片，那么的pgpool和PostgreSQL的分区函数是无效的答案。 分区的分区是在服务器上。 分片是更通用，使用时数据库被分割在几个服务器上。分片分区的时候是不可能的更多，比如对于不适合在单个磁盘上的大型数据库。 对于真正的分片那么Skype的PL /代理可能是最好的。

3. PL /代理（通过Skype等）是一个很好的解决方案。它需要你的访问是通过一个函数的API，但一旦你有，它可以让它非常透明。

Q2: postgresql的语法与mysql有什么区别

一、 PostgreSQL 的稳定性极强， Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多 MySQL 用户都遇到过Server级的数据库丢失的场景——mysql系统库是MyISAM的，相比之下，PG数据库这方面要好一些。

二、任何系统都有它的性能极限，在高并发读写，负载逼近极限下，PG的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，而 MySQL 明显出现一个波峰后下滑（5.5版本之后，在企业级版本中有个插件可以改善很多，不过需要付费）。

三、PG 多年来在 GIS 领域处于优势地位，因为它有丰富的几何类型，实际上不止几何类型，PG有大量字典、数组、bitmap 等数据类型，相比之下mysql就差很多，instagram就是因为PG的空间数据库扩展POSTGIS远远强于MYSQL的my spatial而采用PGSQL的。

四、PG 的“无锁定”特性非常突出，甚至包括 vacuum 这样的整理数据空间的操作，这个和PGSQL的MVCC实现有关系。

五、PG 的可以使用函数和条件索引，这使得PG数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。

六、PG有极其强悍的 SQL 编程能力（9.x 图灵完备，支持递归！），有非常丰富的统计函数和统计语法支持，比如分析函数（ORACLE的叫法，PG里叫window函数），还可以用多种语言来写存储过程，对于R的支持也很好。这一点上MYSQL就差的很远，很多分析功能都不支持，腾讯内部数据存储主要是MYSQL，但是数据分析主要是HADOOP+PGSQL（听李元佳说过，但是没有验证过）。

七、PG 的有多种集群架构可以选择，plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。

八、一般关系型数据库的字符串有限定长度8k左右，无限长 TEXT 类型的功能受限，只能作为外部大数据访问。而 PG 的 TEXT 类型可以直接访问，SQL语法内置正则表达式，可以索引，还可以全文检索，或使用xml xpath。用PG的话，文档数据库都可以省了。

九，对于WEB应用来说，复制的特性很重要，mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。还有mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制，pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。

十，pgsql对于numa架构的支持比mysql强一些，比MYSQL对于读的性能更好一些，pgsql提交可以完全异步，而mysql的内存表不够实用（因为表锁的原因）

最后说一下我感觉 PG 不如 MySQL 的地方。

第一，MySQL有一些实用的运维支持，如 slow-query.log ，这个pg肯定可以定制出来，但是如果可以配置使用就更好了。

第二是mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分，

第三点，MySQL的复制可以用多级从库，但是在9.2之前，PGSQL不能用从库带从库。

第四点，从测试结果上看，mysql 5.5的性能提升很大，单机性能强于pgsql，5.6应该会强更多.

第五点，对于web应用来说,mysql 5.6 的内置MC API功能很好用，PGSQL差一些。

另外一些：

pgsql和mysql都是背后有商业公司，而且都不是一个公司。大部分开发者，都是拿工资的。

说mysql的执行速度比pgsql快很多是不对的，速度接近，而且很多时候取决于你的配置。

对于存储过程，函数，视图之类的功能，现在两个数据库都可以支持了。

另外多线程架构和多进程架构之间没有绝对的好坏，oracle在unix上是多进程架构，在windows上是多线程架构。

很多pg应用也是24/7的应用，比如skype. 最近几个版本VACUUM基本不影响PGSQL 运行，8.0之后的PGSQL不需要cygwin就可以在windows上运行。

至于说对于事务的支持，mysql和pgsql都没有问题。

Q3: MySQL与PostgreSQL相比哪个更好

MySQL

MySQL声称自己是最流行的开源数据库。LAMP中的M指的就是MySQL。构建在LAMP上的应用都会使用MySQL，如WordPress、Drupal等大多数php开源程序。MySQL最初是由MySQL AB开发的，然后在2008年以10亿美金的价格卖给了Sun公司，Sun公司又在2010年被Oracle收购。Oracle支持MySQL的多个版本：Standard、Enterprise、Classic、Cluster、Embedded与Community。其中有一些是免费下载的，另外一些则是收费的。其核心代码基于GPL许可，由于MySQL被控制在Oracle，社区担心会对MySQL的开源会有影响，所以开发了一些分支，比如： MariaDB和Percona。

PostgreSQL

PostgreSQL标榜自己是世界上最先进的开源数据库。PostgreSQL的一些粉丝说它能与Oracle相媲美，而且没有那么昂贵的价格和傲慢的客服。最初是1985年在加利福尼亚大学伯克利分校开发的，作为Ingres数据库的后继。PostgreSQL是完全由社区驱动的开源项目。它提供了单个完整功能的版本，而不像MySQL那样提供了多个不同的社区版、商业版与企业版。PostgreSQL基于自由的BSD/MIT许可，组织可以使用、复制、修改和重新分发代码，只需要提供一个版权声明即可。

MySQL与PostgreSQL的对比

MySQL的背后是一个成熟的商业公司，而PostgreSQL的背后是一个庞大的志愿开发组。这使得MySQL的开发过程更为慎重，而PostgreSQL的反应更为迅速。这样的两种背景直接导致了各自固有的优点和缺点。

PostgreSQL相对于MySQL的优势

1)不仅仅是关系型数据库

除了存储正常的数据类型外，还支持存储：

array，不管是一位数组还是多为数组均支持

json(hStore)和jsonb，相比使用text存储接送要高效很多

json和jsonb之间的区别

jsonb和json在更高的层面上看起来几乎是一样的，但在存储实现上是不同的。

json存储完的文本，json列会每次都解析存储的值，它不支持索引，但你可以为查询创建表达式索引。

jsonb存储的二进制格式，避免了重新解析数据结构。它支持索引，这意味着你可以不使用指定的索引就能查询任何路径。

当我们比较写入数据速度时，由于数据存储的方式的原因，jsonb会比json稍微的慢一点。json列会每次都解析存储的值，这意味着键的顺序要和输入的时候一样。但jsonb不同，以二进制格式存储且不保证键的顺序。因此，如果你有软件需要依赖键的顺序，jsonb可能不是你的应用的最佳选择。使用jsonb的优势还在于你可以轻易的整合关系型数据和非关系型数据， PostgreSQL对于mongodb这类的基于文档的数据库是个不小的威胁，毕竟如果一个表中只有一列数据的类型是半结构化的，没有必要为了迁就它而整个表的设计采用schemaless的结构。

2)支持地理信息处理扩展

PostGIS 为PostgreSQL提供了存储空间地理数据的支持，使PostgreSQL成为了一个空间数据库，能够进行空间数据管理、数量测量与几何拓扑分析。在功能上，和MYSQL对比，PostGIS具有下列优势：

O2O业务场景中的LBS业务使用PostgreSQL + PostGIS有无法比拟的优势。

3)可以快速构建REST API

PostgREST 可以方便的为任何 PostgreSQL 数据库提供完全的 RESTful API 服务。

4)支持树状结构

支持R-trees这样可扩展的索引类型，可以更方便地处理一些特殊数据。MySQL 处理树状的设计会很复杂, 而且需要写很多代码, 而 PostgreSQL 可以高效处理树结构。

5)有极其强悍的 SQL 编程能力

支持递归，有非常丰富的统计函数和统计语法支持。

MySQL：支持 CREATE PROCEDURE 和 CREATE FUNCTION 语句。存储过程可以用 SQL 和 C++ 编写。用户定义函数可以用 SQL、C 和 C++ 编写。

PostgreSQL：没有单独的存储过程，都是通过函数实现的。用户定义函数可以用 PL/pgSQL(专用的过程语言)、PL/Tcl、PL/Perl、PL/Python 、SQL 和 C 编写。

6)外部数据源支持

可以把 70 种外部数据源 (包括 Mysql, Oracle, CSV, hadoop …) 当成自己数据库中的表来查询。Postgres有一个针对这一难题的解决方案：一个名为“外部数据封装器(Foreign Data Wrapper，FDW)”的特性。该特性最初由PostgreSQL社区领袖Dave Page四年前根据SQL标准SQL/MED(SQL Management of External Data)开发。FDW提供了一个SQL接口，用于访问远程数据存储中的远程大数据对象，使DBA可以整合来自不相关数据源的数据，将它们存入Postgres数据库中的一个公共模型。这样，DBA就可以访问和操作其它系统管理的数据，就像在本地Postgres表中一样。例如，使用FDW for MongoDB，数据库管理员可以查询来自文档数据库的数据，并使用SQL将它与来自本地Postgres表的数据相关联。借助这种方法，用户可以将数据作为行、列或JSON文档进行查看、排序和分组。他们甚至可以直接从Postgres向源文档数据库写入(插入、更细或删除)数据，就像一个一体的无缝部署。也可以对Hadoop集群或MySQL部署做同样的事。FDW使Postgres可以充当企业的中央联合数据库或“Hub”。

7)没有字符串长度限制

一般关系型数据库的字符串有限定长度8k左右，无限长 TEXT 类型的功能受限，只能作为外部大数据访问。而PostgreSQL的 TEXT 类型可以直接访问，SQL语法内置正则表达式，可以索引，还可以全文检索，或使用xml xpath。MySQL 的各种text字段有不同的限制，要手动区分 small text, middle text, large text… PostgreSQL 没有这个限制，text 能支持各种大小。

8)支持图结构数据存储

没有具体使用过，具体可以自己搜索下。参考链接：

9)支持窗口函数

窗口函数提供跨行相关的当前查询行集执行计算的能力。仅当调用跟着OVER子句的聚集函数，作为窗口函数;否则它们作为常规的聚合函数。窗口也是一种分组，但和 group by 的分组不同。窗口，可以提供分组之外，还可以执行对每个窗口进行计算。可以相像成是group by 后，然后对每个分组进行计算，而不像Group by ，只是单纯地分组。MySQL 不支持 OVER 子句, 而PostgreSQL支持。OVER 子句能简单的解决 “每组取 top 5” 的这类问题。MySQL支持的SQL语法(ANSI SQL标准)的很小一部分。不支持递归查询、通用表表达式(Oracle的with 语句)或者窗口函数(分析函数)。

10)对索引的支持更强

PostgreSQL 的可以使用函数和条件索引，这使得PostgreSQL数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。对于索引类型：

MySQL：取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。

PostgreSQL：支持 B-树、哈希、R-树和 Gist 索引。

InnoDB的表和索引都是按相同的方式存储。也就是说表都是索引组织表。这一般要求主键不能太长而且插入时的主键最好是按顺序递增，否则对性能有很大影响。PostgreSQL不存在这个问题。

索引类型方面，MySQL取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。PostgreSQL支持 B-树、哈希、R-树和 Gist 索引。

11)集群支持更好

Mysql Cluster可能与你的想象有较大差异。开源的cluster软件较少。复制(Replication)功能是异步的并且有很大的局限性。例如，它是单线程的(single-threaded)，因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master。

PostgreSQL有丰富的开源cluster软件支持。plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。

另外，PostgreSQL的主备复制属于物理复制，相对于MySQL基于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小。对于WEB应用来说，复制的特性很重要，mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。还有mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制，pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。

12)事务隔离做的更好

MySQL 的事务隔离级别 repeatable read 并不能阻止常见的并发更新, 得加锁才可以, 但悲观锁会影响性能, 手动实现乐观锁又复杂. 而 PostgreSQL 的列里有隐藏的乐观锁 version 字段, 默认的 repeatable read 级别就能保证并发更新的正确性, 并且又有乐观锁的性能。

13)对于字符支持更好一些

MySQL 里需要 utf8mb4 才能显示 emoji 的坑, PostgreSQL 没这个坑。

14)对表连接支持较完整

对表连接支持较完整，MySQL只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join)。PostgreSQL都支持。

15)存储方式支持更大的数据量

PostgreSQL主表采用堆表存放，MySQL采用索引组织表，能够支持比MySQL更大的数据量。

16)时间精度更高

MySQL对于时间、日期、间隔等时间类型没有秒以下级别的存储类型，而PostgreSQL可以精确到秒以下。

17)优化器的功能较完整

MySQL对复杂查询的处理较弱，查询优化器不够成熟，explain看执行计划的结果简单。性能优化工具与度量信息不足。

PostgreSQL很强大的查询优化器，支持很复杂的查询处理。explain返回丰富的信息。提供了一些性能视图，可以方便的看到发生在一个表和索引上的select、delete、update、insert统计信息，也可以看到cache命中率。网上有一个开源的pgstatspack工具。

18)序列支持更好

MySQL 不支持多个表从同一个序列中取 id, 而 PostgreSQL 可以。

19)对子查询支持更好

对子查询的支持。虽然在很多情况下在SQL语句中使用子查询效率低下，而且绝大多数情况下可以使用带条件的多表连接来替代子查询，但是子查询的存在在很多时候仍然不可避免。而且使用子查询的SQL语句与使用带条件的多表连接相比具有更高的程序可读性。几乎任何数据库的子查询 (subquery) 性能都比 MySQL 好。

20)增加列更加简单

MySQL表增加列，基本上是重建表和索引，会花很长时间。PostgreSQL表增加列，只是在数据字典中增加表定义，不会重建表.

MySQL相对于PostgreSQL的优势

1)MySQL比PostgreSQL更流行

流行对于一个商业软件来说，也是一个很重要的指标，流行意味着更多的用户，意味着经受了更多的考验，意味着更好的商业支持、意味着更多、更完善的文档资料。易用，很容易安装。第三方工具，包括可视化工具，让用户能够很容易入门。

2)回滚实现更优

innodb的基于回滚段实现的MVCC机制，相对PG新老数据一起存放的基于XID的MVCC机制，是占优的。新老数据一起存放，需要定时触发VACUUM，会带来多余的IO和数据库对象加锁开销，引起数据库整体的并发能力下降。而且VACUUM清理不及时，还可能会引发数据膨胀。

3)在Windows上运行更可靠

与PostgreSQL相比，MySQL更适宜在Windows环境下运行。MySQL作为一个本地的Windows应用程序运行(在 NT/Win2000/WinXP下，是一个服务)，而PostgreSQL是运行在Cygwin模拟环境下。PostgreSQL在Windows下运行没有MySQL稳定，应该是可以想象的。

4)线程模式相比进程模式的优势

MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。

进程模式对多CPU利用率比较高。进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。

线程模式对资源消耗比较少。所以MySQL能支持远比PostgreSQL多的更多的连接。但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。

5)权限设置上更加完善

MySQL在权限系统上比PostgreSQL某些方面更为完善。PostgreSQL只支持对于每一个用户在一个数据库上或一个数据表上的 INSERT、SELECT和UPDATE/DELETE的授权，而MySQL允许你定义一整套的不同的数据级、表级和列级的权限。对于列级的权限， PostgreSQL可以通过建立视图，并确定视图的权限来弥补。MySQL还允许你指定基于主机的权限，这对于目前的PostgreSQL是无法实现的，但是在很多时候，这是有用的。

6)存储引擎插件化机制

MySQL的存储引擎插件化机制，使得它的应用场景更加广泛，比如除了innodb适合事务处理场景外，myisam适合静态数据的查询场景。

7)适应24/7运行

MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。

8)更加试用于简单的场景

PostgreSQL只支持堆表，不支持索引组织表，Innodb只支持索引组织表。

索引组织表的优势：表内的数据就是按索引的方式组织，数据是有序的，如果数据都是按主键来访问，那么访问数据比较快。而堆表，按主键访问数据时，是需要先按主键索引找到数据的物理位置。

索引组织表的劣势：索引组织表中上再加其它的索引时，其它的索引记录的数据位置不再是物理位置，而是主键值，所以对于索引组织表来说，主键的值不能太大，否则占用的空间比较大。

对于索引组织表来说，如果每次在中间插入数据，可能会导致索引分裂，索引分裂会大大降低插入的性能。所以对于使用innodb来说，我们一般最好让主键是一个无意义的序列，这样插入每次都发生在最后，以避免这个问题。

由于索引组织表是按一个索引树，一般它访问数据块必须按数据块之间的关系进行访问，而不是按物理块的访问数据的，所以当做全表扫描时要比堆表慢很多，这可能在OLTP中不明显，但在数据仓库的应用中可能是一个问题。

总结

MySQL从一开始就没有打算做所有事情，因而它在功能方面有一定的局限性，并不能满足一些先进应用程序的要求。MySQL对某些功能(例如引用、事务、审计等)的实现方式使得它与其他的关系型数据库相比缺少了一些可靠性。对于简单繁重的读取操作，使用PostgreSQL可能有点小题大做，同时性能也比MySQL这样的同类产品要差。除非你需要绝对的数据完整性，ACID遵从性或者设计复杂，否则PostgreSQL对于简单的场景而言有点多余。

如何你确定只在MySQL和PostgreSQL中进行选择，以下规则总是有效的：

如果你的操作系统是Windows，你应该使用MySQL。

当绝对需要可靠性和数据完整性的时候，PostgreSQL是更好的选择。

如果需要数据库执行定制程序，那么可扩展的PostgreSQL是更好的选择。

你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。

如果你对数据库并不了十分了解，甚至不知道事务、存储过程等究竟是什么，你应该使用MySQL。

Q4: 如何评价 Uber 从 PostgreSQL 改为 MySQL

Uber工程师在官方博客上描述了他们为什么要从 Postgres 切换到 MySQL 数据库。Uber的早期架构是由 Python编写的后端应用构成，使用了 Postgres 数据库。但此后，Uber的架构发生了显著的改变，转变到了微服务模型和新的数据平台。以前他们使用 Postgres，现在则改用了基于 MySQL 的数据库分片层。Uber工程师称他们之所以切换到Schemaless和其它基于 MySQL 的后端服务，最主要的原因是Postgres 数据复制效率低下，Postgres更新已有行的效率低于 MySQL，Postgres需要重写每一个行索引，而MySQL只更新改变的索引。

Q5: 看大数据最大技术难关之模糊检索，PostgreSQL如何攻克

但是由于“大数据”和“Hadoop”这两个热门词，即使很多人实际上不需要Hadoop，他们也愿意穿上“紧身衣”。

一、如果我的数据量是几百兆，Excel可能没法加载它

对于Excel软件来说的“很大的数据”并非大数据，其实还有其它极好的工具可以使用——我喜欢的Pandas。Pandas构建于Numpy库 之上，可以以矢量格式的方式有效地把数百兆的数据载入到内存中。在我购买已3年的笔记本上，它可以用Numpy在一眨眼的功夫把1亿的浮点数乘在一起。 Matlab和R也是极好的工具。

对于几百兆的数据量，典型的做法是写一个简单的Python脚本按行读取文件行，并处理它，向另一个文件写入。

二、如果我的数据是10GB呢

我买了个新笔记本，它有16GB的内存和256GB的SSD。如果你要载入一个10GB的CSV文件到Pandas，它占用的内存实际上是很小的 ——其结果是以数字类型的字符串保存的，如“17284832583”作为4字节货8字节的整数，或存储“284572452.2435723”字符串作 为8字节的双精度浮点数。

最坏的情况是你或许不能把所有的数据都同时载入到内存中。

三、如果我的数据是100GB、500GB或1TB呢

买个2TB或4TB的硬盘，在桌面PC或服务器上安装一个Postgre来解决它。

四、Hadoop远远比不上SQL或Python脚本

在计算的表达方面，Hadoop弱于SQL，也弱于Python脚本。

SQL是一个很直接的查询语言，适合做业务分析，SQL的查询相当简单，而且还非常快——如果你的数据库使用了正确的索引，二级查询或多级查询另当别论。

Hadoop没有索引的概念，Hadoop只有全表扫描，Hadoop有高度泄露抽象——我花了很多时间来处理Java的内存错误、文件碎片以及集群竞争，这些时间远大于我花在数据分析上的时间。

如果你的数据并不是像SQL表那样的结构化数据（比如纯文本、JSON对象、二进制对象），通常是直接写一个小的Python脚本来按行处理你的数据。把数据存储于文件，处理每一个文件，等等。如果换成是Hadoop就很麻烦。

相比于SQL或Python脚本，Hadoop要慢的多。正确的使用索引后，SQL查询总是非快——PostgreSQL简单的查找索引，检索确 切的键值。而Hadoop是全表扫描的，它会把整个表进行重新排序。通过把数据表分片到多台计算机上后，重排序是很快的。另一方面，处理二进制对 象，Hadoop需要重复往返于命名节点，目的是查找和处理数据。这适合用Python脚本来实现。

五、我的数据超过了5TB

你应该考虑使用Hadoop，而无需做过多的选择。

使用Hadoop唯一的好处是可伸缩性非常好。如果你有一个包含了数TB数据的表，Hadoop有一个适合全表扫描的选项。如果你没有这样大数据量的表，那么你应该像躲避瘟疫那样避免使用Hadoop。这样使用传统的方法来解决问题会更轻松。

六、Hadoop是一个极好的工具

我并不讨厌Hadoop，当我用其它工具不能很好处理数据时我会选择Hadoop。另外，我推荐使用Scalding，不要使用Hive或Pig。Scalding支持使用Scala语言来编写Hadoop任务链，隐藏了其下的MapReduce。