在扩展 GitLab 数据库和我们应用的解决方案，去帮助解决我们的数据库设置中的问题时，我们深入分析了所面临的挑战。

很长时间以来 GitLab.com 使用了一个单个的 PostgreSQL 数据库服务器和一个用于灾难恢复的单个复制。在 GitLab.com 最初的几年，它工作的还是很好的，但是，随着时间的推移，我们看到这种设置的很多问题，在这篇文章中，我们将带你了解我们在帮助解决 GitLab.com 和 GitLab 实例所在的主机时都做了些什么。

例如，数据库长久处于重压之下， CPU 使用率几乎所有时间都处于 70% 左右。并不是因为我们以最好的方式使用了全部的可用资源，而是因为我们使用了太多的（未经优化的）查询去“冲击”服务器。我们意识到需要去优化设置，这样我们就可以平衡负载，使 GitLab.com 能够更灵活地应对可能出现在主数据库服务器上的任何问题。

在我们使用 PostgreSQL 去跟踪这些问题时，使用了以下的四种技术：

1. 优化你的应用程序代码，以使查询更加高效（并且理论上使用了很少的资源）。
2. 使用一个连接池去减少必需的数据库连接数量（及相关的资源）。
3. 跨多个数据库服务器去平衡负载。
4. 分片你的数据库

在过去的两年里，我们一直在积极地优化应用程序代码，但它不是一个完美的解决方案，甚至，如果你改善了性能，当流量也增加时，你还需要去应用其它的几种技术。出于本文的目的，我们将跳过优化应用代码这个特定主题，而专注于其它技术。

连接池

在 PostgreSQL 中，一个连接是通过启动一个操作系统进程来处理的，这反过来又需要大量的资源，更多的连接（及这些进程）将使用你的数据库上的更多的资源。 PostgreSQL 也在 max\_connections 设置中定义了一个强制的最大连接数量。一旦达到这个限制，PostgreSQL 将拒绝新的连接， 比如，下面的图表示的设置：

这里我们的客户端直接连接到 PostgreSQL，这样每个客户端请求一个连接。

通过连接池，我们可以有多个客户端侧的连接重复使用一个 PostgreSQL 连接。例如，没有连接池时，我们需要 100 个 PostgreSQL 连接去处理 100 个客户端连接；使用连接池后，我们仅需要 10 个，或者依据我们配置的 PostgreSQL 连接。这意味着我们的连接图表将变成下面看到的那样：

这里我们展示了一个示例，四个客户端连接到 pgbouncer，但不是使用了四个 PostgreSQL 连接，而是仅需要两个。

对于 PostgreSQL 有两个最常用的连接池：

• pgbouncer
• pgpool-II

pgpool 有一点特殊，因为它不仅仅是连接池：它有一个内置的查询缓存机制，可以跨多个数据库负载均衡、管理复制等等。

另一个 pgbouncer 是很简单的：它就是一个连接池。

数据库负载均衡

数据库级的负载均衡一般是使用 PostgreSQL 的 “ 热备机 hot-standby ” 特性来实现的。 热备机是允许你去运行只读 SQL 查询的 PostgreSQL 副本，与不允许运行任何 SQL 查询的普通 备用机 standby 相反。要使用负载均衡，你需要设置一个或多个热备服务器，并且以某些方式去平衡这些跨主机的只读查询，同时将其它操作发送到主服务器上。扩展这样的一个设置是很容易的：（如果需要的话）简单地增加多个热备机以增加只读流量。

这种方法的另一个好处是拥有一个更具弹性的数据库集群。即使主服务器出现问题，仅使用次级服务器也可以继续处理 Web 请求；当然，如果这些请求最终使用主服务器，你可能仍然会遇到错误。

然而，这种方法很难实现。例如，一旦它们包含写操作，事务显然需要在主服务器上运行。此外，在写操作完成之后，我们希望继续使用主服务器一会儿，因为在使用异步复制的时候，热备机服务器上可能还没有这些更改。

分片

分片是水平分割你的数据的行为。这意味着数据保存在特定的服务器上并且使用一个分片键检索。例如，你可以按项目分片数据并且使用项目 ID 做为分片键。当你的写负载很高时，分片数据库是很有用的（除了一个多主设置外，均衡写操作没有其它的简单方法），或者当你有大量的数据并且你不再使用传统方式保存它也是有用的（比如，你不能把它简单地全部放进一个单个磁盘中）。

不幸的是，设置分片数据库是一个任务量很大的过程，甚至，在我们使用诸如 Citus 的软件时也是这样。你不仅需要设置基础设施 （不同的复杂程序取决于是你运行在你自己的数据中心还是托管主机的解决方案），你还得需要调整你的应用程序中很大的一部分去支持分片。

反对分片的案例

在 GitLab.com 上一般情况下写负载是非常低的，同时大多数的查询都是只读查询。在极端情况下，尖峰值达到每秒 1500 元组写入，但是，在大多数情况下不超过每秒 200 元组写入。另一方面，我们可以在任何给定的次级服务器上轻松达到每秒 1000 万元组读取。

存储方面，我们也不使用太多的数据：大约 800 GB。这些数据中的很大一部分是在后台迁移的，这些数据一经迁移后，我们的数据库收缩的相当多。

接下来的工作量就是调整应用程序，以便于所有查询都可以正确地使用分片键。 我们的一些查询包含了一个项目 ID，它是我们使用的分片键，也有许多查询没有包含这个分片键。分片也会影响提交到 GitLab 的改变内容的过程，每个提交者现在必须确保在他们的查询中包含分片键。

最后，是完成这些工作所需要的基础设施。服务器已经完成设置，监视也添加了、工程师们必须培训，以便于他们熟悉上面列出的这些新的设置。虽然托管解决方案可能不需要你自己管理服务器，但它不能解决所有问题。工程师们仍然需要去培训（很可能非常昂贵）并需要为此支付账单。在 GitLab 上，我们也非常乐意提供我们用过的这些工具，这样社区就可以使用它们。这意味着如果我们去分片数据库， 我们将在我们的 Omnibus 包中提供它（或至少是其中的一部分）。确保你提供的服务的唯一方法就是你自己去管理它，这意味着我们不能使用主机托管的解决方案。

最终，我们决定不使用数据库分片，因为它是昂贵的、费时的、复杂的解决方案。

GitLab 的连接池

对于连接池我们有两个主要的诉求：

1. 它必须工作的很好（很显然这是必需的）。
2. 它必须易于在我们的 Omnibus 包中运用，以便于我们的用户也可以从连接池中得到好处。

用下面两步去评估这两个解决方案（pgpool 和 pgbouncer）：

1. 执行各种技术测试（是否有效，配置是否容易，等等）。
2. 找出使用这个解决方案的其它用户的经验，他们遇到了什么问题？怎么去解决的？等等。

pgpool 是我们考察的第一个解决方案，主要是因为它提供的很多特性看起来很有吸引力。我们其中的一些测试数据可以在 这里 找到。

最终，基于多个因素，我们决定不使用 pgpool 。例如， pgpool 不支持 粘连接 sticky connection 。 当执行一个写入并（尝试）立即显示结果时，它会出现问题。想像一下，创建一个 工单 issue 并立即重定向到这个页面， 没有想到会出现 HTTP 404，这是因为任何用于只读查询的服务器还没有收到数据。针对这种情况的一种解决办法是使用同步复制，但这会给表带来更多的其它问题，而我们希望避免这些问题。

另一个问题是， pgpool 的负载均衡逻辑与你的应用程序是不相干的，是通过解析 SQL 查询并将它们发送到正确的服务器。因为这发生在你的应用程序之外，你几乎无法控制查询运行在哪里。这实际上对某些人也可能是有好处的， 因为你不需要额外的应用程序逻辑。但是，它也妨碍了你在需要的情况下调整路由逻辑。

由于配置选项非常多，配置 pgpool 也是很困难的。或许促使我们最终决定不使用它的原因是我们从过去使用过它的那些人中得到的反馈。即使是在大多数的案例都不是很详细的情况下，我们收到的反馈对 pgpool 通常都持有负面的观点。虽然出现的报怨大多数都与早期版本的 pgpool 有关，但仍然让我们怀疑使用它是否是个正确的选择。

结合上面描述的问题和反馈，最终我们决定不使用 pgpool 而是使用 pgbouncer 。我们用 pgbouncer 执行了一套类似的测试，并且对它的结果是非常满意的。它非常容易配置（而且一开始不需要很多的配置），运用相对容易，仅专注于连接池（而且它真的很好），而且没有明显的负载开销（如果有的话）。也许我唯一的报怨是，pgbouncer 的网站有点难以导航。

使用 pgbouncer 后，通过使用 事务池 transaction pooling 我们可以将活动的 PostgreSQL 连接数从几百个降到仅 10 - 20 个。我们选择事务池是因为 Rails 数据库连接是持久的。这个设置中，使用 会话池 session pooling 不能让我们降低 PostgreSQL 连接数，从而受益（如果有的话）。通过使用事务池，我们可以调低 PostgreSQL 的 max_connections 的设置值，从 3000 （这个特定值的原因我们也不清楚) 到 300 。这样配置的 pgbouncer ，即使在尖峰时，我们也仅需要 200 个连接，这为我们提供了一些额外连接的空间，如 psql 控制台和维护任务。

对于使用事务池的负面影响方面，你不能使用预处理语句，因为 PREPARE 和 EXECUTE 命令也许最终在不同的连接中运行，从而产生错误的结果。 幸运的是，当我们禁用了预处理语句时，并没有测量到任何响应时间的增加，但是我们 确定 测量到在我们的数据库服务器上内存使用减少了大约 20 GB。

为确保我们的 web 请求和后台作业都有可用连接，我们设置了两个独立的池： 一个有 150 个连接的后台进程连接池，和一个有 50 个连接的 web 请求连接池。对于 web 连接需要的请求，我们很少超过 20 个，但是，对于后台进程，由于在 GitLab.com 上后台运行着大量的进程，我们的尖峰值可以很容易达到 100 个连接。

今天，我们提供 pgbouncer 作为 GitLab EE 高可用包的一部分。对于更多的信息，你可以参考 “Omnibus GitLab PostgreSQL High Availability”。

GitLab 上的数据库负载均衡

使用 pgpool 和它的负载均衡特性，我们需要一些其它的东西去分发负载到多个热备服务器上。

对于（但不限于） Rails 应用程序，它有一个叫 Makara 的库，它实现了负载均衡的逻辑并包含了一个 ActiveRecord 的缺省实现。然而，Makara 也有一些我们认为是有些遗憾的问题。例如，它支持的粘连接是非常有限的：当你使用一个 cookie 和一个固定的 TTL 去执行一个写操作时，连接将粘到主服务器。这意味着，如果复制极大地滞后于 TTL，最终你可能会发现，你的查询运行在一个没有你需要的数据的主机上。

Makara 也需要你做很多配置，如所有的数据库主机和它们的角色，没有服务发现机制（我们当前的解决方案也不支持它们，即使它是将来计划的）。 Makara 也 似乎不是线程安全的，这是有问题的，因为 Sidekiq （我们使用的后台进程）是多线程的。 最终，我们希望尽可能地去控制负载均衡的逻辑。

除了 Makara 之外 ，还有一个 Octopus ，它也是内置的负载均衡机制。但是 Octopus 是面向分片数据库的，而不仅是均衡只读查询的。因此，最终我们不考虑使用 Octopus。

最终，我们直接在 GitLab EE构建了自己的解决方案。 添加初始实现的 合并请求 merge request 可以在 这里找到，尽管一些更改、提升和修复是以后增加的。

我们的解决方案本质上是通过用一个处理查询的路由的代理对象替换 ActiveRecord::Base.connection 。这可以让我们均衡负载尽可能多的查询，甚至，包括不是直接来自我们的代码中的查询。这个代理对象基于调用方式去决定将查询转发到哪个主机， 消除了解析 SQL 查询的需要。

粘连接

粘连接是通过在执行写入时，将当前 PostgreSQL WAL 位置存储到一个指针中实现支持的。在请求即将结束时，指针短期保存在 Redis 中。每个用户提供他自己的 key，因此，一个用户的动作不会导致其他的用户受到影响。下次请求时，我们取得指针，并且与所有的次级服务器进行比较。如果所有的次级服务器都有一个超过我们的指针的 WAL 指针，那么我们知道它们是同步的，我们可以为我们的只读查询安全地使用次级服务器。如果一个或多个次级服务器没有同步，我们将继续使用主服务器直到它们同步。如果 30 秒内没有写入操作，并且所有的次级服务器还没有同步，我们将恢复使用次级服务器，这是为了防止有些人的查询永远运行在主服务器上。

检查一个次级服务器是否就绪十分简单，它在如下的 Gitlab::Database::LoadBalancing::Host#caught_up? 中实现：

def caught_up?(location)
  string = connection.quote(location)

  query = "SELECT NOT pg_is_in_recovery() OR " \
    "pg_xlog_location_diff(pg_last_xlog_replay_location(), #{string}) >= 0 AS result"

  row = connection.select_all(query).first

  row && row['result'] == 't'
ensure
  release_connection
end

这里的大部分代码是运行原生查询（raw queries）和获取结果的标准的 Rails 代码，查询的最有趣的部分如下：

SELECT NOT pg_is_in_recovery()
OR pg_xlog_location_diff(pg_last_xlog_replay_location(), WAL-POINTER) >= 0 AS result"

这里 WAL-POINTER 是 WAL 指针，通过 PostgreSQL 函数 pg_current_xlog_insert_location() 返回的，它是在主服务器上执行的。在上面的代码片断中，该指针作为一个参数传递，然后它被引用或转义，并传递给查询。

使用函数 pg_last_xlog_replay_location() 我们可以取得次级服务器的 WAL 指针，然后，我们可以通过函数 pg_xlog_location_diff() 与我们的主服务器上的指针进行比较。如果结果大于 0 ，我们就可以知道次级服务器是同步的。

当一个次级服务器被提升为主服务器，并且我们的 GitLab 进程还不知道这一点的时候，添加检查 NOT pg_is_in_recovery() 以确保查询不会失败。在这个案例中，主服务器总是与它自己是同步的，所以它简单返回一个 true。

后台进程

我们的后台进程代码 总是 使用主服务器，因为在后台执行的大部分工作都是写入。此外，我们不能可靠地使用一个热备机，因为我们无法知道作业是否在主服务器执行，也因为许多作业并没有直接绑定到用户上。

连接错误

要处理连接错误，比如负载均衡器不会使用一个视作离线的次级服务器，会增加主机上（包括主服务器）的连接错误，将会导致负载均衡器多次重试。这是确保，在遇到偶发的小问题或数据库失败事件时，不会立即显示一个错误页面。当我们在负载均衡器级别上处理 热备机冲突 的问题时，我们最终在次级服务器上启用了 hot_standby_feedback ，这样就解决了热备机冲突的所有问题，而不会对表膨胀造成任何负面影响。

我们使用的过程很简单：对于次级服务器，我们在它们之间用无延迟试了几次。对于主服务器，我们通过使用越来越快的回退尝试几次。

更多信息你可以查看 GitLab EE 上的源代码：

• https://gitlab.com/gitlab-org/gitlab-ee/tree/master/lib/gitlab/database/load_balancing.rb
• https://gitlab.com/gitlab-org/gitlab-ee/tree/master/lib/gitlab/database/load_balancing

数据库负载均衡首次引入是在 GitLab 9.0 中，并且 仅 支持 PostgreSQL。更多信息可以在 9.0 release post 和 documentation 中找到。

Crunchy Data

我们与 Crunchy Data 一起协同工作来部署连接池和负载均衡。不久之前我还是唯一的 数据库专家，它意味着我有很多工作要做。此外，我对 PostgreSQL 的内部细节的和它大量的设置所知有限 (或者至少现在是)，这意味着我能做的也有限。因为这些原因，我们雇用了 Crunchy 去帮我们找出问题、研究慢查询、建议模式优化、优化 PostgreSQL 设置等等。

在合作期间，大部分工作都是在相互信任的基础上完成的，因此，我们共享私人数据，比如日志。在合作结束时，我们从一些资料和公开的内容中删除了敏感数据，主要的资料在 gitlab-com/infrastructure#1448，这又反过来导致产生和解决了许多分立的问题。

这次合作的好处是巨大的，它帮助我们发现并解决了许多的问题，如果必须我们自己来做的话，我们可能需要花上几个月的时间来识别和解决它。

幸运的是，最近我们成功地雇佣了我们的 第二个数据库专家 并且我们希望以后我们的团队能够发展壮大。

整合连接池和数据库负载均衡

整合连接池和数据库负载均衡可以让我们去大幅减少运行数据库集群所需要的资源和在分发到热备机上的负载。例如，以前我们的主服务器 CPU 使用率一直徘徊在 70%，现在它一般在 10% 到 20% 之间，而我们的两台热备机服务器则大部分时间在 20% 左右：

在这里， db3.cluster.gitlab.com 是我们的主服务器，而其它的两台是我们的次级服务器。

其它的负载相关的因素，如平均负载、磁盘使用、内存使用也大为改善。例如，主服务器现在的平均负载几乎不会超过 10，而不像以前它一直徘徊在 20 左右：

在业务繁忙期间，我们的次级服务器每秒事务数在 12000 左右（大约为每分钟 740000），而主服务器每秒事务数在 6000 左右（大约每分钟 340000）：

可惜的是，在部署 pgbouncer 和我们的数据库负载均衡器之前，我们没有关于事务速率的任何数据。

我们的 PostgreSQL 的最新统计数据的摘要可以在我们的 public Grafana dashboard 上找到。

我们的其中一些 pgbouncer 的设置如下：

除了前面所说的这些外，还有一些工作要作，比如： 部署服务发现（#2042）， 持续改善如何检查次级服务器是否可用（#2866），和忽略落后于主服务器太多的次级服务器 （#2197）。

值得一提的是，到目前为止，我们还没有任何计划将我们的负载均衡解决方案，独立打包成一个你可以在 GitLab 之外使用的库，相反，我们的重点是为 GitLab EE 提供一个可靠的负载均衡解决方案。

如果你对它感兴趣，并喜欢使用数据库、改善应用程序性能、给 GitLab上增加数据库相关的特性（比如： 服务发现），你一定要去查看一下我们的 招聘职位 和 数据库专家手册 去获取更多信息。

via: https://about.gitlab.com/2017/10/02/scaling-the-gitlab-database/

作者：Yorick Peterse 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在 Citus 公司，为让事情做的更好，我们与客户一起在数据建模、优化查询、和增加 索引上花费了许多时间。我的目标是为客户的需求提供更好的服务，从而创造成功。我们所做的其中一部分工作是持续为你的 Citus 集群保持良好的优化和 高性能；另外一部分是帮你了解关于 Postgres 和 Citus 你所需要知道的一切。毕竟，一个健康和高性能的数据库意味着 app 执行的更快，并且谁不愿意这样呢？ 今天，我们简化一些内容，与客户分享一些关于 Postgres 索引的信息。

Postgres 有几种索引类型， 并且每个新版本都似乎增加一些新的索引类型。每个索引类型都是有用的，但是具体使用哪种类型取决于（1）数据类型，有时是（2）表中的底层数据和（3）执行的查找类型。接下来的内容我们将介绍在 Postgres 中你可以使用的索引类型，以及你何时该使用何种索引类型。在开始之前，这里有一个我们将带你亲历的索引类型列表：

• B-Tree
• 倒排索引 Generalized Inverted Index (GIN)
• 倒排搜索树 Generalized Inverted Seach Tree (GiST)
• 空间分区的 Space partitioned GiST (SP-GiST)
• 块范围索引 Block Range Index (BRIN)
• Hash

现在开始介绍索引。

在 Postgres 中，B-Tree 索引是你使用的最普遍的索引

如果你有一个计算机科学的学位，那么 B-Tree 索引可能是你学会的第一个索引。B-tree 索引 会创建一个始终保持自身平衡的一棵树。当它根据索引去查找某个东西时，它会遍历这棵树去找到键，然后返回你要查找的数据。使用索引是大大快于顺序扫描的，因为相对于顺序扫描成千上万的记录，它可以仅需要读几个 页 (当你仅返回几个记录时)。

如果你运行一个标准的 CREATE INDEX 语句，它将为你创建一个 B-tree 索引。 B-tree 索引在大多数的数据类型上是很有价值的，比如文本、数字和时间戳。如果你刚开始在你的数据库中使用索引，并且不在你的数据库上使用太多的 Postgres 的高级特性，使用标准的 B-Tree 索引可能是你最好的选择。

GIN 索引，用于多值列

倒排索引 Generalized Inverted Index ，一般称为 GIN，大多适用于当单个列中包含多个值的数据类型。

据 Postgres 文档：

“GIN 设计用于处理被索引的条目是复合值的情况，并且由索引处理的查询需要搜索在复合条目中出现的值。例如，这个条目可能是文档，查询可以搜索文档中包含的指定字符。”

包含在这个范围内的最常见的数据类型有：

• hStore
• Array
• Range
• JSONB

关于 GIN 索引中最让人满意的一件事是，它们能够理解存储在复合值中的数据。但是，因为一个 GIN 索引需要有每个被添加的单独类型的数据结构的特定知识，因此，GIN 索引并不是支持所有的数据类型。

GiST 索引， 用于有重叠值的行

倒排搜索树 Generalized Inverted Seach Tree （GiST）索引多适用于当你的数据与同一列的其它行数据重叠时。GiST 索引最好的用处是：如果你声明一个几何数据类型，并且你希望知道两个多边型是否包含一些点时。在一种情况中一个特定的点可能被包含在一个盒子中，而与此同时，其它的点仅存在于一个多边形中。使用 GiST 索引的常见数据类型有：

• 几何类型
• 需要进行全文搜索的文本类型

GiST 索引在大小上有很多的固定限制，否则，GiST 索引可能会变的特别大。作为其代价，GiST 索引是有损的（不精确的）。

据官方文档：

“GiST 索引是有损的，这意味着索引可能产生虚假匹配，所以需要去检查真实的表行去消除虚假匹配。 (当需要时 PostgreSQL 会自动执行这个动作)”

这并不意味着你会得到一个错误结果，它只是说明了在 Postgres 给你返回数据之前，会做了一个很小的额外工作来过滤这些虚假结果。

特别提示：同一个数据类型上 GIN 和 GiST 索引往往都可以使用。通常一个有很好的性能表现，但会占用很大的磁盘空间，反之亦然。说到 GIN 与 GiST 的比较，并没有某个完美的方案可以适用所有情况，但是，以上规则应用于大部分常见情况。

SP-GiST 索引，用于更大的数据

空间分区 GiST （SP-GiST）索引采用来自 Purdue 研究的空间分区树。 SP-GiST 索引经常用于当你的数据有一个天然的聚集因素，并且不是一个平衡树的时候。 电话号码是一个非常好的例子 (至少 US 的电话号码是)。 它们有如下的格式：

• 3 位数字的区域号
• 3 位数字的前缀号 (与以前的电话交换机有关)
• 4 位的线路号

这意味着第一组前三位处有一个天然的聚集因素，接着是第二组三位，然后的数字才是一个均匀的分布。但是，在电话号码的一些区域号中，存在一个比其它区域号更高的饱合状态。结果可能导致树非常的不平衡。因为前面有一个天然的聚集因素，并且数据不对等分布，像电话号码一样的数据可能会是 SP-GiST 的一个很好的案例。

BRIN 索引， 用于更大的数据

块范围索引（BRIN）专注于一些类似 SP-GiST 的情形，它们最好用在当数据有一些自然排序，并且往往数据量很大时。如果有一个以时间为序的 10 亿条的记录，BRIN 也许就能派上用场。如果你正在查询一组很大的有自然分组的数据，如有几个邮编的数据，BRIN 能帮你确保相近的邮编存储在磁盘上相近的地方。

当你有一个非常大的比如以日期或邮编排序的数据库， BRIN 索引可以让你非常快的跳过或排除一些不需要的数据。此外，与整体数据量大小相比，BRIN 索引相对较小，因此，当你有一个大的数据集时，BRIN 索引就可以表现出较好的性能。

Hash 索引， 总算不怕崩溃了

Hash 索引在 Postgres 中已经存在多年了，但是，在 Postgres 10 发布之前，对它们的使用一直有个巨大的警告，它不是 WAL-logged 的。这意味着如果你的服务器崩溃，并且你无法使用如 wal-g 故障转移到备机或从存档中恢复，那么你将丢失那个索引，直到你重建它。 随着 Postgres 10 发布，它们现在是 WAL-logged 的，因此，你可以再次考虑使用它们 ，但是，真正的问题是，你应该这样做吗?

Hash 索引有时会提供比 B-Tree 索引更快的查找，并且创建也很快。最大的问题是它们被限制仅用于“相等”的比较操作，因此你只能用于精确匹配的查找。这使得 hash 索引的灵活性远不及通常使用的 B-Tree 索引，并且，你不能把它看成是一种替代品，而是一种用于特殊情况的索引。

你该使用哪个？

我们刚才介绍了很多，如果你有点被吓到，也很正常。 如果在你知道这些之前， CREATE INDEX 将始终为你创建使用 B-Tree 的索引，并且有一个好消息是，对于大多数的数据库， Postgres 的性能都很好或非常好。 :) 如果你考虑使用更多的 Postgres 特性，下面是一个当你使用其它 Postgres 索引类型的备忘清单：

• B-Tree - 适用于大多数的数据类型和查询
• GIN - 适用于 JSONB/hstore/arrays
• GiST - 适用于全文搜索和几何数据类型
• SP-GiST - 适用于有天然的聚集因素但是分布不均匀的大数据集
• BRIN - 适用于有顺序排列的真正的大数据集
• Hash - 适用于相等操作，而且，通常情况下 B-Tree 索引仍然是你所需要的。

如果你有关于这篇文章的任何问题或反馈，欢迎加入我们的 slack channel。

via: https://www.citusdata.com/blog/2017/10/17/tour-of-postgres-index-types/

作者：Craig Kerstiens 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

前段时间新的重大版本的 PostgreSQL 10 发布了！ 强烈建议阅读公告、发布说明和“新功能”概述可以在这里、这里和这里。像往常一样，已经有相当多的博客覆盖了所有新的东西，但我猜每个人都有自己认为重要的角度，所以与 9.6 版一样我再次在这里列出我印象中最有趣/相关的功能。

与往常一样，升级或初始化一个新集群的用户将获得更好的性能（例如，更好的并行索引扫描、合并 join 和不相关的子查询，更快的聚合、远程服务器上更加智能的 join 和聚合），这些都开箱即用，但本文中我想讲一些不能开箱即用，实际上你需要采取一些步骤才能从中获益的内容。下面重点展示的功能是从 DBA 的角度来汇编的，很快也有一篇文章从开发者的角度讲述更改。

升级注意事项

首先有些从现有设置升级的提示 - 有一些小的事情会导致从 9.6 或更旧的版本迁移时引起问题，所以在真正的升级之前，一定要在单独的副本上测试升级，并遍历发行说明中所有可能的问题。最值得注意的缺陷是：

• 所有包含 “xlog” 的函数都被重命名为使用 “wal” 而不是 “xlog”。

后一个命名可能与正常的服务器日志混淆，因此这是一个“以防万一”的更改。如果使用任何第三方备份/复制/HA 工具，请检查它们是否为最新版本。

• 存放服务器日志（错误消息/警告等）的 pg\_log 文件夹已重命名为 “log”。

确保验证你的日志解析或 grep 脚本（如果有）可以工作。

• 默认情况下，查询将最多使用 2 个后台进程。

如果在 CPU 数量较少的机器上在 postgresql.conf 设置中使用默认值 10，则可能会看到资源使用率峰值，因为默认情况下并行处理已启用 - 这是一件好事，因为它应该意味着更快的查询。如果需要旧的行为，请将 max_parallel_workers_per_gather 设置为 0。

• 默认情况下，本地主机的复制连接已启用。

为了简化测试等工作，本地主机和本地 Unix 套接字复制连接现在在 pg_hba.conf 中以“ 信任 trust ”模式启用（无密码）！因此，如果其他非 DBA 用户也可以访问真实的生产计算机，请确保更改配置。

从 DBA 的角度来看我的最爱

• 逻辑复制

这个期待已久的功能在你只想要复制一张单独的表、部分表或者所有表时只需要简单的设置而性能损失最小，这也意味着之后主要版本可以零停机升级！历史上（需要 Postgres 9.4+），这可以通过使用第三方扩展或缓慢的基于触发器的解决方案来实现。对我而言这是 10 最好的功能。

• 声明分区

以前管理分区的方法通过继承并创建触发器来把插入操作重新路由到正确的表中，这一点很烦人，更不用说性能的影响了。目前支持的是 “range” 和 “list” 分区方案。如果有人在某些数据库引擎中缺少 “哈希” 分区，则可以使用带表达式的 “list” 分区来实现相同的功能。

• 可用的哈希索引

哈希索引现在是 WAL 记录的，因此是崩溃安全的，并获得了一些性能改进，对于简单的搜索，它们比在更大的数据上的标准 B 树索引快。也支持更大的索引大小。

• 跨列优化器统计

这样的统计数据需要在一组表的列上手动创建，以指出这些值实际上是以某种方式相互依赖的。这将能够应对计划器认为返回的数据很少（概率的乘积通常会产生非常小的数字）从而导致在大量数据下性能不好的的慢查询问题（例如选择“嵌套循环” join）。

• 副本上的并行快照

现在可以在 pg\_dump 中使用多个进程（-jobs 标志）来极大地加快备用服务器上的备份。

• 更好地调整并行处理 worker 的行为

参考 max_parallel_workers 和 min_parallel_table_scan_size/min_parallel_index_scan_size 参数。我建议增加一点后两者的默认值（8MB、512KB）。

• 新的内置监控角色，便于工具使用

新的角色 pg_monitor、pg_read_all_settings、pg_read_all_stats 和 pg_stat_scan_tables 能更容易进行各种监控任务 - 以前必须使用超级用户帐户或一些 SECURITY DEFINER 包装函数。

• 用于更安全的副本生成的临时 (每个会话) 复制槽
• 用于检查 B 树索引的有效性的一个新的 Contrib 扩展

这两个智能检查发现结构不一致和页面级校验未覆盖的内容。希望不久的将来能更加深入。

• Psql 查询工具现在支持基本分支（if/elif/else）

例如下面的将启用具有特定版本分支（对 pg\_stat* 视图等有不同列名）的单个维护/监视脚本，而不是许多版本特定的脚本。

SELECT :VERSION_NAME = '10.0' AS is_v10 \gset 
\if :is_v10
SELECT 'yippee' AS msg;
\else
SELECT 'time to upgrade!' AS msg;
\endif

这次就这样了！当然有很多其他的东西没有列出，所以对于专职 DBA，我一定会建议你更全面地看发布记录。非常感谢那 300 多为这个版本做出贡献的人！

via: http://www.cybertec.at/best-of-postgresql-10-for-the-dba/

作者：Kaarel Moppel 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

PingCAP 推出了 TiDB 1.0，一个可扩展的混合数据库解决方案

2017 年 10 月 16 日， 一家尖端的分布式数据库技术公司 PingCAP Inc. 正式宣布发布 TiDB 1.0。TiDB 是一个开源的分布式混合事务/分析处理 （HTAP） 数据库，它使企业能够使用单个数据库来满足这两个负载。

在当前的数据库环境中，基础架构工程师通常要使用一个数据库进行在线事务处理（OLTP），另一个用于在线分析处理（OLAP）。TiDB 旨在通过构建一个基于实时事务数据的实时业务分析的 HTAP 数据库来打破这种分离。有了 TiDB，工程师现在可以花更少的时间来管理多个数据库解决方案，并有更多的时间为他们的公司提供业务价值。TiDB 的一个金融证券公司的用户正在利用这项技术为财富管理和用户角色的应用提供支持。借助 TiDB，该公司可以轻松处理 web 量级的计费记录，并进行关键任务时间敏感的数据分析。

PingCAP 联合创始人兼 CEO 刘奇（Max Liu）说：

“两年半前，Edward、Dylan 和我开始这个旅程，为长期困扰基础设施软件业的老问题建立一个新的数据库。今天，我们很自豪地宣布，这个数据库 TiDB 可以面向生产环境了。亚伯拉罕·林肯曾经说过，‘预测未来的最好办法就是创造’，我们在 771 天前预测的未来，现在我们已经创造了，这不仅是我们团队的每一个成员，也是我们的开源社区的每个贡献者、用户和合作伙伴的努力工作和奉献。今天，我们庆祝和感谢开源精神的力量。明天，我们将继续创造我们相信的未来。”

TiDB 已经在亚太地区 30 多家公司投入生产环境，其中包括 摩拜、Gaea 和 YOUZU 等快速增长的互联网公司。使用案例涵盖从在线市场和游戏到金融科技、媒体和旅游的多个行业。

TiDB 功能

水平可扩展性

TiDB 随着你的业务发展而增长。你可以通过添加更多机器来增加存储和计算能力。

兼容 MySQL 协议

像用 MySQL 一样使用 TiDB。你可以用 TiDB 替换 MySQL 来增强你的应用，且在大多数情况下不用更改一行代码，也几乎没有迁移成本。

自动故障切换和高可用性

你的数据和程序始终处于在线状态。TiDB 自动处理故障并保护你的应用免受整个数据中心的机器故障甚至停机。

一致的分布式事务

TiDB 类似于单机关系型数据库系统（RDBMS）。你可以启动跨多台机器的事务，而不用担心一致性。TiDB 使你的应用程序代码简单而强大。

在线 DDL

根据你的要求更改 TiDB 模式。你可以添加新的列和索引，而不会停止或影响你正在进行的操作。

现在尝试TiDB！

使用案例

• yuanfudao.com 中 TiDB 如何处理快速的数据增长和复杂查询
• 从 MySQL 迁移到 TiDB 以每天处理数千万行数据

更多信息：

TiDB 内部：

• 数据存储
• 计算
• 调度

via: https://pingcap.github.io/blog/2017/10/17/announcement/

作者：PingCAP 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在编写高效 SQL 时，你可能遇到的最有影响的事情就是索引。但是，一个很重要的事实就是很多 SQL 客户端要求数据库做很多“不必要的强制性工作”。

跟我再重复一遍：

不必要的强制性工作

什么是“不必要的强制性工作”？这个意思包括两个方面：

不必要的

假设你的客户端应用程序需要这些信息：

这没什么特别的。我们运行着一个电影数据库（例如 Sakila 数据库），我们想要给用户显示每部电影的名称和评分。

这是能产生上面结果的查询：

SELECT title, rating
FROM film

然而，我们的应用程序（或者我们的 ORM（LCTT 译注： 对象关系映射 （ Object-Relational Mapping ） ））运行的查询却是：

SELECT *
FROM film

我们得到什么？猜一下。我们得到很多无用的信息：

甚至一些复杂的 JSON 数据全程在下列环节中加载：

• 从磁盘
• 加载到缓存
• 通过总线
• 进入客户端内存
• 然后被丢弃

是的，我们丢弃了其中大部分的信息。检索它所做的工作完全就是不必要的。对吧？没错。

强制性

这是最糟糕的部分。现今随着优化器变得越来越聪明，这些工作对于数据库来说都是强制执行的。数据库没有办法知道客户端应用程序实际上不需要其中 95% 的数据。这只是一个简单的例子。想象一下如果我们连接更多的表...

你想想那会怎样呢？数据库还快吗？让我们来看看一些之前你可能没有想到的地方：

内存消耗

当然，单次执行时间不会变化很大。可能是慢 1.5 倍，但我们可以忍受，是吧？为方便起见，有时候确实如此。但是如果你每次都为了方便而牺牲性能，这事情就大了。我们不说性能问题（单个查询的速度），而是关注在吞吐量上时（系统响应时间），事情就变得困难而难以解决。你就会受阻于规模的扩大。

让我们来看看执行计划，这是 Oracle 的：

--------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes |
--------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 |   166K|
|   1 |  TABLE ACCESS FULL| FILM |  1000 |   166K|
--------------------------------------------------

对比一下：

--------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes |
--------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1000 | 20000 |
|   1 |  TABLE ACCESS FULL| FILM |  1000 | 20000 |
--------------------------------------------------

当执行 SELECT * 而不是 SELECT film, rating 的时候，我们在数据库中使用了 8 倍之多的内存。这并不奇怪，对吧？我们早就知道了。在很多我们并不需要其中全部数据的查询中我们都是这样做的。我们为数据库产生了不必要的强制性工作，其后果累加了起来，就是我们使用了多达 8 倍的内存（当然，数值可能有些不同）。

而现在，所有其它的步骤（比如，磁盘 I/O、总线传输、客户端内存消耗）也受到相同的影响，我这里就跳过了。另外，我还想看看...

索引使用

如今大部分数据库都有涵盖索引（LCTT 译注：covering index，包括了你查询所需列、甚至更多列的索引，可以直接从索引中获取所有需要的数据，而无需访问物理表）的概念。涵盖索引并不是特殊的索引。但对于一个特定的查询，它可以“意外地”或人为地转变为一个“特殊索引”。

看看这个查询：

SELECT *
FROM actor
WHERE last_name LIKE 'A%'

执行计划中没有什么特别之处。它只是个简单的查询。索引范围扫描、表访问，就结束了：

-------------------------------------------------------------------
| Id  | Operation                   | Name                | Rows  |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                     |     8 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ACTOR               |     8 |
|*  2 |   INDEX RANGE SCAN          | IDX_ACTOR_LAST_NAME |     8 |
-------------------------------------------------------------------

这是个好计划吗？如果我们只是想要这些，那么它就不是：

当然，我们浪费了内存之类的。再来看看这个查询：

SELECT first_name, last_name 
FROM actor
WHERE last_name LIKE 'A%'

它的计划是：

----------------------------------------------------
| Id  | Operation        | Name            | Rows  |
----------------------------------------------------
|   0 | SELECT STATEMENT |                 |     8 |
|*  1 |  INDEX RANGE SCAN| IDX_ACTOR_NAMES |     8 |
----------------------------------------------------

现在我们可以完全消除表访问，因为有一个索引涵盖了我们查询需要的所有东西……一个涵盖索引。这很重要吗？当然！这种方法可以将你的某些查询加速一个数量级（如果在某个更改后你的索引不再涵盖，可能会降低一个数量级）。

你不能总是从涵盖索引中获利。索引也有它们自己的成本，你不应该添加太多索引，例如像这种情况就是不明智的。让我们来做个测试：

SET SERVEROUTPUT ON
DECLARE
  v_ts TIMESTAMP;
  v_repeat CONSTANT NUMBER := 100000;
BEGIN
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Worst query: Memory overhead AND table access
      SELECT *
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Statement 1 : ' || (SYSTIMESTAMP - v_ts));
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Better query: Still table access
      SELECT /*+INDEX(actor(last_name))*/
        first_name, last_name
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Statement 2 : ' || (SYSTIMESTAMP - v_ts));
  v_ts := SYSTIMESTAMP;

  FOR i IN 1..v_repeat LOOP
    FOR rec IN (
      -- Best query: Covering index
      SELECT /*+INDEX(actor(last_name, first_name))*/
        first_name, last_name
      FROM actor
      WHERE last_name LIKE 'A%'
    ) LOOP
      NULL;
    END LOOP;
  END LOOP;

  dbms_output.put_line('Statement 3 : ' || (SYSTIMESTAMP - v_ts));
END;
/

结果是：

Statement 1 : +000000000 00:00:02.479000000
Statement 2 : +000000000 00:00:02.261000000
Statement 3 : +000000000 00:00:01.857000000

注意，表 actor 只有 4 列，因此语句 1 和 2 的差别并不是太令人印象深刻，但仍然很重要。还要注意我使用了 Oracle 的提示来强制优化器为查询选择一个或其它索引。在这种情况下语句 3 明显胜利。这是一个好很多的查询，也是一个十分简单的查询。

当我们写 SELECT * 语句时，我们为数据库带来了不必要的强制性工作，这是无法优化的。它不会使用涵盖索引，因为比起它所使用的 LAST_NAME 索引，涵盖索引开销更多一点，不管怎样，它都要访问表以获取无用的 LAST_UPDATE 列。

使用 SELECT * 会变得更糟。考虑一下……

SQL 转换

优化器工作的很好，因为它们转换了你的 SQL 查询（看我最近在 Voxxed Days Zurich 关于这方面的演讲）。例如，其中有一个称为“表连接消除”的转换，它真的很强大。看看这个辅助视图，我们写了这个视图是因为我们非常讨厌总是连接所有这些表：

CREATE VIEW v_customer AS
SELECT
  c.first_name, c.last_name, 
  a.address, ci.city, co.country
FROM customer c
JOIN address a USING (address_id)
JOIN city ci USING (city_id)
JOIN country co USING (country_id)

这个视图仅仅是把 CUSTOMER 和他们不同的 ADDRESS 部分所有“对一”关系连接起来。谢天谢地，它很工整。

现在，使用这个视图一段时间之后，想象我们非常习惯这个视图，我们都忘了所有它底层的表。然后，我们运行了这个查询：

SELECT *
FROM v_customer

我们得到了一个相当令人印象深刻的计划：

----------------------------------------------------------------
| Id  | Operation            | Name     | Rows  | Bytes | Cost |
----------------------------------------------------------------
|   0 | SELECT STATEMENT     |          |   599 | 47920 |   14 |
|*  1 |  HASH JOIN           |          |   599 | 47920 |   14 |
|   2 |   TABLE ACCESS FULL  | COUNTRY  |   109 |  1526 |    2 |
|*  3 |   HASH JOIN          |          |   599 | 39534 |   11 |
|   4 |    TABLE ACCESS FULL | CITY     |   600 | 10800 |    3 |
|*  5 |    HASH JOIN         |          |   599 | 28752 |    8 |
|   6 |     TABLE ACCESS FULL| CUSTOMER |   599 | 11381 |    4 |
|   7 |     TABLE ACCESS FULL| ADDRESS  |   603 | 17487 |    3 |
----------------------------------------------------------------

当然是这样。我们运行了所有这些表连接以及全表扫描，因为这就是我们让数据库去做的：获取所有的数据。

现在，再一次想一下，对于一个特定场景，我们真正想要的是：

是啊，对吧？现在你应该知道我的意图了。但想像一下，我们确实从前面的错误中学到了东西，现在我们实际上运行下面一个比较好的查询：

SELECT first_name, last_name
FROM v_customer

再来看看结果！

------------------------------------------------------------------
| Id  | Operation          | Name        | Rows  | Bytes | Cost  |
------------------------------------------------------------------
|   0 | SELECT STATEMENT   |             |   599 | 16173 |     4 |
|   1 |  NESTED LOOPS      |             |   599 | 16173 |     4 |
|   2 |   TABLE ACCESS FULL| CUSTOMER    |   599 | 11381 |     4 |
|*  3 |   INDEX UNIQUE SCAN| SYS_C007120 |     1 |     8 |     0 |
------------------------------------------------------------------

这是执行计划一个极大的进步。我们的表连接被消除了，因为优化器可以证明它们是不必要的，因此一旦它可以证明这点（而且你不会因使用 select * 而使其成为强制性工作），它就可以移除这些工作并不执行它。为什么会发生这种情况？

每个 CUSTOMER.ADDRESS_ID 外键保证了有且只有一个 ADDRESS.ADDRESS_ID 主键值，因此可以保证 JOIN 操作是对一连接，它不会产生或者删除行。如果我们甚至不选择行或查询行，当然我们就不需要真正地去加载行。可以证实地移除 JOIN 并不会改变查询的结果。

数据库总是会做这些事情。你可以在大部分数据库上尝试它：

-- Oracle
SELECT CASE WHEN EXISTS (
  SELECT 1 / 0 FROM dual
) THEN 1 ELSE 0 END
FROM dual

-- 更合理的 SQL 语句，例如 PostgreSQL
SELECT EXISTS (SELECT 1 / 0)

在这种情况下，当你运行这个查询时你可能预料到会抛出算术异常：

SELECT 1 / 0 FROM dual

产生了：

ORA-01476: divisor is equal to zero

但它并没有发生。优化器（甚至解析器）可以证明 EXISTS (SELECT ..) 谓词内的任何 SELECT 列表达式不会改变查询的结果，因此也就没有必要计算它的值。呵！

同时……

大部分 ORM 最不幸问题就是事实上他们很随意就写出了 SELECT * 查询。事实上，例如 HQL / JPQL，就设置默认使用它。你甚至可以完全抛弃 SELECT 从句，因为毕竟你想要获取所有实体，正如声明的那样，对吧？

例如：

FROM v_customer

例如 Vlad Mihalcea（一个 Hibernate 专家和 Hibernate 开发倡导者）建议你每次确定不想要在获取后进行任何更改时再使用查询。ORM 使解决对象图持久化问题变得简单。注意：持久化。真正修改对象图并持久化修改的想法是固有的。

但如果你不想那样做，为什么要抓取实体呢？为什么不写一个查询？让我们清楚一点：从性能角度，针对你正在解决的用例写一个查询总是会胜过其它选项。你可以不会在意，因为你的数据集很小，没关系。可以。但最终，你需要扩展并重新设计你的应用程序以便在强制实体图遍历之上支持查询语言，就会变得很困难。你也需要做其它事情。

计算出现次数

资源浪费最严重的情况是在只是想要检验存在性时运行 COUNT(*) 查询。例如：

这个用户有没有订单？

我们会运行：

SELECT count(*)
FROM orders
WHERE user_id = :user_id

很简单。如果 COUNT = 0：没有订单。否则：是的，有订单。

性能可能不会很差，因为我们可能有一个 ORDERS.USER_ID 列上的索引。但是和下面的这个相比你认为上面的性能是怎样呢：

-- Oracle
SELECT CASE WHEN EXISTS (
  SELECT *
  FROM orders
  WHERE user_id = :user_id
) THEN 1 ELSE 0 END
FROM dual

-- 更合理的 SQL 语句，例如 PostgreSQL
SELECT EXISTS (
  SELECT *
  FROM orders
  WHERE user_id = :user_id
)

它不需要火箭科学家来确定，一旦它找到一个，实际存在谓词就可以马上停止寻找额外的行。因此，如果答案是“没有订单”，速度将会是差不多。但如果结果是“是的，有订单”，那么结果在我们不计算具体次数的情况下就会大幅加快。

因为我们不在乎具体的次数。我们告诉数据库去计算它（不必要的），而数据库也不知道我们会丢弃所有大于 1 的结果（强制性）。

当然，如果你在 JPA 支持的集合上调用 list.size() 做同样的事情，情况会变得更糟！

近期我有关于该情况的博客以及在不同数据库上的测试。去看看吧。

总结

这篇文章的立场很“明显”。别让数据库做不必要的强制性工作。

它不必要，因为对于你给定的需求，你知道一些特定的工作不需要完成。但是，你告诉数据库去做。

它强制性，因为数据库无法证明它是不必要的。这些信息只包含在客户端中，对于服务器来说无法访问。因此，数据库需要去做。

这篇文章大部分在介绍 SELECT *，因为这是一个很简单的目标。但是这并不仅限于数据库。这关系到客户端要求服务器完成不必要的强制性工作的任何分布式算法。你的 AngularJS 应用程序平均有多少个 N+1 问题，UI 在服务结果 A 上循环，多次调用服务 B，而不是把所有对 B 的调用打包为一个调用？这是一个复发的模式。

解决方法总是相同。你给执行你命令的实体越多信息，（理论上）它能更快执行这样的命令。每次都写一个好的查询。你的整个系统都会为此感谢你的。

如果你喜欢这篇文章...

再看看近期我在 Voxxed Days Zurich 的演讲，其中我展示了一些在数据处理算法上为什么 SQL 总是会胜过 Java 的双曲线例子。

（题图：Pixabay， CC0）

via: https://blog.jooq.org/2017/03/08/many-sql-performance-problems-stem-from-unnecessary-mandatory-work

作者：jooq 译者：ictlyh 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

数据库连接池是常用的 B/S 技术，而似乎生活在这个“池子”里面的那些连接对象有点不幸。

要是顺利的话，你干完活就可以歇着了。

要是不顺利，比如你掌握的连接已经被拒绝了，那么……

你就会被“砰”地干掉。就问你怕不怕？（话说回来，回答错误会不会也被“砰”……）

via: http://turnoff.us/geek/db-connection-pool/

作者：Daniel Stori 译者&点评：wxy 校对&合成：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出