PostgreSQL中citus节点间的网络需求有哪些

本篇内容介绍了“PostgreSQL中citus节点间的网络需求有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！citus 节点间的网络需求：1、cn节点访问所有worker节点。oltp业务的访问较频繁。2、重分布数据时，worker节点间相互访问。访问频度不大，OLAP业务常见，一旦有可能数据交换吞吐较大。citus的cn节点连worker节点为有两种模式，一种为事务级保持连接模式（每条SQL发起时建立连接，SQL结束后释放连接(除非在事务中，否则SQL结束立即释放连接)。），另一种为会话级保持连接模式（会话发起时建立连接，会话结束后释放连接。）。1、跑OLAP类的SQL时，使用的是第一种即时连接模式（OLAP场景并发不高，建立连接带来的额外开销不明显）可以在worker节点打开参数进行跟踪例子，以下两条SQL均为即时短连接模式(Custom Scan (Citus Task-Tracker) Custom Scan (Citus Real-Time))。2、跑OLTP查询时（通常并发很高，前端有连接池（保持会话）），为会话级保持连接模式（Custom Scan (Citus Router)）。以下SQL为长连接模式（不会立即释放，而是等会再释放，以降低高并发时连接带来的开销）看以上两种场景，CITUS应该说设计得已经很不错了。既能满足TP也能满足AP。但是前面也说了，连接保持是在事务或会话层面的，如果查询量大，或者用户使用了短连接，建立连接的开销就会很凸显。在worker节点上，部署pgbouncer，所有与worker节点建立的连接都通过pgbouncer连接池，以此来保持住连接，降低worker节点频繁新建连接的开销。部署方法pgbouncer配置启动在一个citus集群中，可以同时存在直连worker或者通过pgbouncer连接worker。不同的database可以有不同的配置。以下例子，新建一个database，使用pgbouncer连接worker.新建数据库，插件将worker添加到集群配置，使用pgbouncer的连接端口MX配置，免费主机域名同样，将worker节点添加到元数据同步中。开启同步到元数据。1、tpc-b 长连接测试性能与不使用pgbouncer差不多，因为使用了长连接测试简单SQL（本身citus就使用了会话级连接保持，没有短连接问题）。在一个新建的会话中，第一次查询总是需要需要耗费更多的时间（如果没有建立连接，那么包括建立连接的时间。即使已建立连接，也需要耗费额外的一些时间）（具体原因可以跟踪分析一下code）。以下使用的是pgbouncer连接worker，因此第一次QUERY不包含建立连接的时间。多出的几毫秒，我们社区的小伙伴邓彪、王健给出了原因如下，很多地方需要检查安装的citus版本与citus.control控制文件的版本是否兼容(比如加载分布式TABLE的RELCACHE时，第一次访问就是这个问题)，不兼容报错：详见代码https://github.com/citusdata/citus/blob/3fa04d8f2c8f27b1377fe4c1468ee47358117e3c/src/backend/distributed/utils/me免费主机域名tadata_cache.c1、对于业务层短连接会有比较好的效果。可以降低至少5毫秒左右的延迟。2、对于大量复杂查询（需要motion的查询），可以减少节点间的连接数。“PostgreSQL中citus节点间的网络需求有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注云技术网站，小编将为大家输出更多高质量的实用文章！

相关推荐: InnoDB表为什么一定要用自增列做主键

这篇文章主要介绍InnoDB表为什么一定要用自增列做主键，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！ 我们先了解下InnoDB引擎表的一些关键特征： InnoDB引擎表是基于B+树的索引组织表(IOT)； 每个表都需要有一个聚集索引(…