一台机器具有多个应用程序的 Postgres 架构
我有一台机器，上面托管了多个应用程序。应用程序处理单独的数据并且不交互 - 每个应用程序只需要访问自己的数据。我想使用 PostgreSQL 作为 RDBMS。以下哪一项最好，为什么？
- 一台全局 Postgres 服务器、一个全局数据库、每个应用程序一个架构。
- 一台全局 Postgres 服务器，每个应用程序一个数据库。
- 每个应用程序一台 Postgres 服务器。
如果您认为其他架构比上述架构更好，请随时提出建议。
I have one machine on which several applications are hosted. Applications work on separated data and don't interact - each application only needs access to its own data. I want to use PostgreSQL as RDBMS. Which one of the following is best and why?
- One global Postgres sever, one global database, one schema per application.
- One global Postgres server, one database per application.
- One Postgres server per application.
Feel free to suggest additional architectures if you think they would be better than the ones above.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要问自己的问题：是否有任何应用程序需要访问另一个应用程序的数据（在同一个 SQL 语句中）。如果您可以明确回答“否”，那么您至少应该使用单独的数据库。跨数据库查询在 Postgres 中并不是那么简单，因此如果不同的应用程序确实需要来自其他应用程序的大量数据，那么解决方案 1 可能是需要考虑的部署布局。如果这只涉及很少的表，那么使用具有不同数据库的外部数据包装器可能仍然是更好的解决方案。
从每个应用的角度来看，解决方案2和3或多或少是相同的。在 2 和 3 之间做出选择时要记住的一件事是可用性。 Postgres 的某些配置更改需要重新启动服务。在这种情况下，即使只有一个应用程序需要进行更改，所有应用程序的中断是否可以接受？
但您始终可以从选项 2 开始，然后将数据库移动到不同的服务器。
另一个要问的问题是，是否所有应用程序始终使用相同的（主要）Postgres 版本 对于解决方案 2，您必须确保所有应用程序都与新的 Postgres 版本兼容（如果其中一个应用程序想要升级，例如因为应用程序需要新功能）使用。
The questions you need to ask yourself: does any application ever need to access data from another application (in the same SQL statement). If you can can answer that with a clear NO, then you should at least go for separate databases. Cross-database queries aren't that straight-forward in Postgres, so if the different applications do need a lot of data from other applications, then solution 1 might be deployment layout to think about. If this would only concern very few tables, then using foreign data wrappers with different databases might still be a better solution.
Solution 2 and 3 are more or less the same from the perspective of each application. One thing to keep in mind when deciding between 2 and 3 is availability. Some configuration changes to Postgres require a restart of the service. Is an outage of all applications acceptable in that case, even though the change was only necessary for one?
But you can always start with option 2 and then move database to different servers later.
Another question to ask is if all applications always use the same (major) Postgres version With solution 2 you must make sure that all applications are compatible with a new Postgres version if one of them wants to upgrade e.g. because of new features that the application wants to use.
解决方案 1 很愚蠢：SQL 模式不是数据库。对一个具有“生产”、“销售”、“营销”、“财务”等多个“部分”的应用程序使用 SQL 模式...
而最终的数据量不会太重，并且用户赢得的数量也不会太多不要太多，只使用一个 PG 集群来方便管理任务
如果数据量或用户数量增加，就需要将不同的数据库分离到新的不同 PG 集群上......
Solution 1 is stupid : a SQL schema is not a database. Use SQL schema for one application that have multiple "parts" like "Poduction", "sales", "marketing", "finances"...
While the final volume of the data won't be too heavy and the number of user won't be too much, use only one PG cluster to facilitate administration tasks
If the volume of data or the number of user increases, it will be time to separates your different databases on new distinct PG clusters....