在多个 map-reduce 作业之间传递数据库连接对象答案

【问题标题】：Passing around DB connection objects between multiple map-reduce jobs在多个 map-reduce 作业之间传递数据库连接对象
【发布时间】：2012-10-29 13:53:59
【问题描述】：

从根本上说，这个问题是关于：可以跨多个进程使用相同的数据库连接（因为不同的 map-reduce 作业位于不同的独立进程中）。

我知道这是一个微不足道的问题，但如果有人也能回答这个问题，那就太好了：如果与数据库的最大连接数（在托管数据库的服务器上预先配置）有筋疲力尽并且一个新的进程试图建立一个新的连接？它是否等待一段时间，如果是，是否有办法为此等待期设置超时。在这种特殊情况下，我说的是 PostGres DB，用于与 DB 对话的语言是 java。

为了让您了解问题的背景，我有多个并行运行的 map-reduce 作业（大约 40 个 reducer），每个都想更新 PostGres 数据库。我如何有效地管理这些进程中的这些数据库读/写。注意：数据库托管在单独的机器上，与运行 map reduce 作业的位置无关。

连接池是一种选择，但有时效率非常低，尤其是对于每秒多次读取/写入。

【问题讨论】：

标签： java database postgresql hadoop mapreduce

【解决方案1】：

可以跨多个进程使用同一个数据库连接

不，不是以任何理智或可靠的方式。您可以使用代理进程，但无论如何您离发明连接池只有一步之遥。

如果连接的最大数量达到数据库（在托管数据库的服务器上预先配置）已用尽并且一个新进程试图建立一个新的连接？

连接尝试失败，SQLSTATE 53300 too_many_connections。如果等待，服务器可能会耗尽其他限制并开始在为现有客户端提供服务时出现问题。

对于这样的问题，您通常会使用像 C3P0 或 DBCP 这样的工具来进行 JVM 内池化，但是当您有多个 JVM 时，这将不起作用。

您需要做的是使用像PgBouncer 或PgPool-II 这样的外部连接池来维护一组来自您的工作人员的轻量级连接。然后，pooler 拥有较少数量的真实服务器连接，并在来自客户端的轻量级连接之间共享这些连接。

连接池通常比不使用池更有效，因为它允许您针对硬件和工作负载优化活动 PostgreSQL 工作进程的数量，从而为工作提供准入控制。

另一种方法是让编写器进程具有一个或多个线程（每个线程一个连接），该进程从 reduce 工作人员那里获取完成的工作并写入数据库，因此 reduce 工作人员可以继续他们的下一个工作单元。如果作者落后太远，您需要有一种方法告诉 reduce 工作人员等待。有几种 Java 排队系统实现可以适用于此，或者您可以使用 JMS。

见IPC Suggestion for lots of small data

还值得尽可能优化写入 PostgreSQL 的方式，使用：

准备好的陈述
一个commit_delay
synchronous_commit = 'off' 如果您能承受在服务器崩溃时丢失一些事务的后果
将工作批量处理成更大的事务
COPY 或多值 INSERTs 插入数据块
具有有用磁盘子系统的体面硬件，而不是某些具有糟糕 I/O 的 Amazon EC2 实例或具有 5400rpm 磁盘的 RAID 5 机器
具有电池支持的回写高速缓存的适当 RAID 控制器可降低 fsync() 的成本。如果你不能做大批量的工作或使用提交延迟，最重要的是；如果由于批处理和组提交而导致 fsync 速率较低，则影响较小。

见：

【讨论】：

感谢您提供宝贵的信息，但您对我的问题有什么解决方案吗？
你答案的最后一部分为这个问题提供了一个很好的方法。甚至我都在考虑这些问题。非常感谢您提供的所有宝贵信息。
@AbhishekJain 使用 PgBouncer 进行外部连接池，这是最简单的方法。或者（根据修改后的答案）使用具有 JMS 或另一个 IPC 队列的共享写入器模型将工作从减少工作人员传递给写入器。
@AbhishekJain 不客气。请记住，您也需要调整 PostgreSQL 以实现快速写入；使用commit_delay，使用synchronous_commit = 'off'，如果你能承受在服务器崩溃时丢失一些事务，在回写模式或其他快速 fsync() 存储中使用电池支持的 RAID 控制器，等等。
非常感谢您添加如此宝贵的信息。