查看原文
其他

第22期吐槽:DB容灾节点延迟了,网络带宽瓶颈?用CPU换啊!该“魔法”PG还不支持!

digoal PostgreSQL码农集散地 2024-07-08

文中参考文档点击阅读原文打开, 同时推荐2个学习环境: 

1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像

2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库

3、PolarDB开源数据库内核、最佳实践等学习图谱:  https://www.aliyun.com/database/openpolardb/activity 

关注公众号, 持续发布PostgreSQL、PolarDB、DuckDB等相关文章. 


第22期吐槽:PG 不支持libpq协议层压缩

1、产品的问题点

  • PG 不支持libpq协议层压缩

2、问题点背后涉及的技术原理

  • libpq是PG 客户端基础驱动, 客户端与数据库交互的信息流不支持压缩传输

3、这个问题将影响哪些行业以及业务场景

  • 网络带宽或延迟成为瓶颈的场景, 例如广域网链路的数据导入、导出备份、容灾实例。用过海外的服务器你就知道带宽资源有多宝贵。

  • 写入量、查询返回记录较多的业务, 例如IOT, 时序类.

4、会导致什么问题?

  • 可能把网络带宽打满, 成为瓶颈

  • 可能导致备份时间变长

5、业务上应该如何避免这个坑

  • 建立加密压缩隧道, 例如SSH隧道, 在隧道之上再建立数据库连接

参考文章:

  • 《ssh隧道加密压缩方法 - a simple wan speed method》

  • 《ssh隧道加密压缩方法 - SSH Tunnels Compression speed up PostgreSQL data transport in WAN environment》

  • 《PostgreSQL 备份链路sslcompression压缩 (openssl)》

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

  • 管理复杂度增加

7、数据库未来产品迭代如何修复这个坑

  • 内核层支持libpq压缩 , 可能快了, 请看这个patch: https://www.postgresql.org/message-id/flat/CAOYmi%2Bnv5cndsU5XEvZdDMkfuqC5uG0MtQ%2B5w8GS8d-FX0yaXQ%40mail.gmail.com#8b0b5839390370fcd86bc3677bed87e9


本期彩蛋-招商中,有需要的小伙伴可联系嵌入...


文章中的参考文档请点击阅读原文获得. 


欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.  

近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号:


继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存