PostgreSQL 正面临抉择
点击上方“芋道源码”,选择“设为星标”
管她前浪,还是后浪?
能浪的浪,才是好浪!
每天 10:33 更新文章,每天掉亿点点头发...
源码精品专栏
面向进程模型是一种数据库系统的架构模型,核心思想是将不同的数据库服务分配给不同的进程,每个进程独立运行,相互之间通过进程间通信(IPC)进行协作。这种模型被广泛应用于数据库系统中,例如 PostgreSQL 数据库系统。
正如上文所说,进程模型使得 PostgreSQL 可以将不同的服务分配给多个进程独立运行,每个进程负责不同的任务,例如查询处理、并发控制、锁管理等。进程模型还可以可以保证系统的稳定性和可靠性。当一个进程出现问题时,不会影响到其他进程的正常运行,从而提高了系统的可用性。
这样的特点使得 PostgreSQL 可以同时处理大量的并发请求,提高了系统的性能和响应速度;除此之外,PostgreSQL 还可以很容易地进行水平扩展,增加更多的节点以应对更高的负载。不过与此同时,也让 PostgreSQL 面对着管理和维护成本相对较高、需要较为复杂的进程间通信和协调机制、需要消耗更多的系统资源等缺点。
6 月初,Heikki Linnakangas 发布了将 PostgreSQL 转为线程模型的提案。
线程模型是一种数据库系统的架构模型,与面向进程模型类似,它是将不同的数据库服务分配给不同的线程,每个线程独立运行,相互之间通过线程间通信进行协作。线程模型在一些轻量级的数据库系统中得到广泛应用,例如 SQLite。
线程模型与进程模型的最大区别在于,线程模型中所有的线程共享同一个进程的地址空间,每个线程有自己的堆栈,共享代码段和数据段。这意味着线程之间可以直接访问同一份内存,因此线程间通信的成本相对较低,不过这也意味着线程间的数据共享可能会带来安全性问题。
从进程模型转换成线程模型的优缺点:
优点
更轻量级:线程模型相对于进程模型更加轻量级,可以更加高效地使用系统资源,尤其是在单机上运行多个实例时,线程模型可以将多个实例运行在同一个进程中,减少了系统调用和进程间通信带来的开销。 更高的响应速度:线程模型中线程之间的通信成本相对较低,因此在高并发场景下具有更高的响应速度。 更少的内存占用:线程模型中线程共享同一份地址空间,因此可以避免进程模型中同一份代码和数据被多个进程重复加载到内存的问题,节省了系统内存占用。
缺点
安全性问题:线程之间共享同一份内存,可能会带来安全性问题,例如数据竞争和锁竞争等。 可靠性问题:线程模型中一个线程崩溃可能会影响到整个进程的稳定性和可靠性。 多线程编程难度较大:线程之间的通信需要进行同步和互斥,编写多线程程序的难度相对较大。
PostgreSQL 开发者、EnterpriseDB 高级数据库架构师 Andres Freund 指出:
我认为原有流程模型开始产生诸多限制,这个问题在大型设备上体现得尤其明显。跨进程上下文切换所带来的开销,原本就比在同一进程内的不同线程间切换要更高 —— 我估计这种开销还将持续提升。面对大量连接,整个体系最终一定会因 TLB 未命中而浪费大量时间。这是进程模型无法跨进程共享 TLB 的天然属性造成的必然结果。
目前这还仅仅只是一项提议,并且由于 PostgreSQL 被广泛用于生产环境,转换到线程模型的过程需要非常谨慎。开发团队需要在不影响现有生产环境的情况下测试新的线程模型,以确保其稳定性和可靠性。即便这个提议通过,这个转化过程肯定也是无法通过单一版本彻底完成,从网上的各方评价来看,目前大多数人都支持这项提议。
相关链接:https://lwn.net/ml/pgsql-hackers/[email protected]/
欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢:
已在知识星球更新源码解析如下:
最近更新《芋道 SpringBoot 2.X 入门》系列,已经 101 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。
获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。
文章有帮助的话,在看,转发吧。
谢谢支持哟 (*^__^*)
微信扫码关注该文公众号作者