有关连接 Postgres 数据库的首选方式的问题
首先，我使用 Postgres。
套接字连接是首选连接方式吗（我将把我的数据库放在与我的应用程序相同的物理计算机上的单独虚拟机中）？套接字连接速度更快吗？另外，当我需要将数据库扩展到单独的机器时，此设置是否会导致问题？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
跨机器工作，即使其中一台是虚拟机，也需要套接字连接。
当您需要扩大规模时，这会导致更少的问题；您将继续使用相同的连接方法，但可能只是针对新计算机/数据库。
Working across machines, even if one of them is a VM, requires socket connections.
It will lead to fewer issues when you need to scale up; you will continue using the same connectivity method, but might simply target a new machine/database.
对于任何打算扩展到单个节点（容器/pod/主机）之外的应用程序，都应始终实现套接字连接。也就是说，在应用程序开发的整个过程中，必须仔细考虑和不断参考扩展问题，并且必须包含比基本套接字连接更多的内容。
您必须考虑您正在使用的数据类型（例如：关系、面向对象、分层、分布式、图形、操作、网络、地理位置、文档、时间序列、流内容等）。您还必须考虑数据的使用/交互方式（例如：大容量交易、电力报告、大数据分析等）。
Postgres 不是一把瑞士军刀。没有数据库。与几乎所有其他数据库一样，Postgres 并不适用于所有数据类型和用例。此外，所有数据库中始终存在功率报告和大容量事务之间的斗争，在确定主机/节点要求时必须考虑这一点。事务性与高级用户的拉锯战甚至可能需要将数据库复制到单独的节点上，以按类型和处理要求隔离工作负载。所有这些都必须在开发过程中在应用程序代码级别考虑，而不仅仅是在事后的数据库部署中考虑。坦率地说，现有的任何数据库都无法弥补未按比例编写的代码。
许多高度可扩展的数据库产品使用的常见方法是分片功能，该功能允许数据跨多个节点和卷进行条带化。 Postgres 也在朝这个方向发展，并且有许多专有分支已经完全提供了此功能（请参阅：https://wiki.postgresql.org/wiki/Built-in_Sharding）。也就是说，在选择要开发的 Postgres 分支之前，您应该详细考虑您的扩展需求。
总之，缩放不是您在数据库本身中执行的操作。它只是数据库向经过正确编写以利用它的应用程序提供的一种功能。 Base Postgres 或其分支之一可能是也可能不是您的答案。
Socket connections should always be implemented in the case of any application that intends to scale beyond a single node (container/pod/host). That said, the issue of scaling must be carefully considered and referenced constantly for the full duration of application development and must encompasses a lot more than basic socket connectivity.
You must consider the type of data you are working with (Ex.: relational, object-oriented, hierarchical, distributed, graph, operational, network, geolocation, document, time-series, streaming content, etc...). You must also consider how the data will be used / interacted with (Ex.: High volume transactional vs. power reporting vs. big data analytics, etc.).
Postgres is not a Swiss army knife. No database is. Like virtually every other database out there, Postgres does not perform well with all data types and use cases. Further there is always a battle in all databases between power reporting and high-volume transactions that must be considered when determining host/node requirements. That transactional vs power user tug of war may even warrant database replication onto separate nodes to segregate workloads by type and processing requirements. All of this has to be considered at the application code level during development, not just in the database deployment after the fact. To put it bluntly, no database in existence can compensate for code that is not written to scale.
A common method used by many highly scalable database offerings is the sharding feature that allows data to be striped across multiple nodes and volumes. Postgres is moving in this direction as well, and there are a number of proprietary branches that already offer this capability in full (see: https://wiki.postgresql.org/wiki/Built-in_Sharding). That said, you should consider your scaling needs in detail before selecting which branch of Postgres you will develop for.
In summary, scaling is not something you do in the database itself. It is merely a capability the database offers to applications that are properly written to exploit it. Base Postgres or one of its branches may or may not be your answer.