android - 用于连接到Postgresql DB的Android应用程序的连接池

Question

我想为我的Android社交网络风格的应用程序设置某种故障保护，以便当很多用户通过它连接到我的Postgresql数据库时，它继续工作并处理大量并发连接。
我不知道在最大负载下会有多少用户，但是在任何给定的时间大约有70个用户会很好。
通过代码/基础设施实现这一目标的最佳方法是什么？
我已经计划使用一个小的web服务来处理数据库连接，但是我不确定在我最终使用的任何平台上，无论是PHP、Python还是Ruby，如何处理连接池。

Answer 1

如何进行连接池
每个平台都有不同的连接池接口。您需要阅读您使用的特定平台（Ruby+Rails或其他）的文档，或者使用一个通用的池中间层，如PgBouncer。
与一个工具（比如，带有Zend框架的PHP）相关的答案与与与另一个工具（比如Ruby on Rails）相关的答案无关。即使您选择了PgBouncer之类的东西，仍然有一些细节与平台如何处理事务生命周期、根据应用程序需要选择的池模式等相关。
所以你需要首先确定你在用什么以及你需要用它做什么。然后研究如何建立连接池。（很多工具都是自动的）。
如果您在阅读了所选平台的文档后仍然陷入困境，请提出一个新的、针对该平台标记的详细而具体的问题。
池和中间件
不要让你的应用直接连接到PostgreSQL。尤其是当它是通过互联网从随机客户。
使用PostgreSQL服务器附近的web服务器，让它接受web服务请求，通过一个定义良好的web API来代理对数据库的访问，该API具有尽可能大的请求范围的短事务。
这不仅仅是一个公认的智慧案例——有充分的理由这么做，而且在互联网上从随机设备运行PostgreSQL也存在严重的问题。
Android应用与Pg直接对话
许多客户通过互联网直接与Pg交谈的问题包括：
每个PostgreSQL后端都有一个成本，不管是否空闲。事务池模式中的PgBouncer在某种程度上有助于实现这一点。
当你在互联网上工作时，连接会随机丢失。WiFi下降，动态IP服务上的IP地址改变，移动服务逐渐淡出或容量最大化，或者随着高包丢失而错开。这就使得PostgreSQL有很多处于不确定状态的连接，可能是打开的事务，给了您<IDLE> in transaction问题，并且需要允许比实际工作更多的连接。
它是事务性的——如果某些事情没有完成，你可以终止事务，并知道它不会有任何效果。
中间层的优点
在Android设备上响应应用程序的HTTP web服务请求以充当数据库访问代理的服务器可能是一个很大的优势。
您可以定义一个版本化的API，因此当您引入新特性或需要更改API时，不必中断旧客户端。这在使用存储过程或大量视图的Pg中是可能的，但可能会变得笨拙。
严格控制数据库访问的范围和事务的生命周期。
您可以定义一个等幂API，其中多次运行同一请求只会产生一个效果。（我强烈建议这样做，因为下一点）。
一切都是无状态的，可能会有很短的超时。如果有些东西不起作用，你就再试一次。
每一个数据库连接都通过一个池，所以没有空闲会话。每个数据库后端都在努力实现最大吞吐量。
你可以排队工作，而不是试图同时做吨和颠簸的服务器。（您也可以在事务池模式下使用PgBouncer执行此操作）。
... 然后重新编辑以更改问题的含义：
性能
你的“同样”表现真的是一个完全不同的问题（最好是这样张贴）。非常简短的版本：如果没有更多关于工作负载的信息，如每个客户端应用程序请求的数据库请求数、数据类型、查询类型、数据大小、查询频率、缓存实用性等，完全无法预测。。。。。。没完没了。任何声称明确回答这个问题的人，要么是历史上第一个真正的通灵者，要么就是完全充满了这个问题。
您需要大致了解您的数据大小、查询模式等。找出你能负担多少缓存在中间层缓存，如redis/memcached，你能让它有多陈旧，你需要什么级别的缓存失效。确定您的“热门”数据集（您经常访问）是否适合RAM。确定经常查询的表的索引是否适合RAM。找出大致的读/写平衡是什么，写多少可能是只插入（append）或更常规的OLTP（insert/update/delete）。虚拟化一个数据集和一些客户端工作负载。然后你可以开始回答这个问题-也许吧。要想做得好，你还必须模拟停滞/消失的客户机等。
明白为什么它不只是一个“也”.