一直以来,我的项目使用 PHP + MySQL-InnoDB 来提供事务安全的应用服务,目前运行的比较良好。
但最近突然对 PostgreSQL 感了兴趣,就查了很多相关资料,总结下来,呈现 PostgreSQL 比 MySQL 强的多这么一个结论。但是大部分能查到的评论都出自几年前,那个时候的 MySQL 被戏称为玩具数据库。重要的是,MySQL 这几年的发展十分迅速,提供了很多商业数据库必不可少的功能特性,从我这个对 PostgreSQL 不是很了解的角度来看,两者对于我的应用而言,差别已经不是很大了。
其实心中还有这么一个情结:总觉得采用 BSD 许可证,和同样是出自加州伯克利分校的 PostgreSQL,能够更好的在 FreeBSD 上面运行。因为 MySQL 是 Linux 阵营的东西,所以作为 FreeBSD 的忠实用户,不免心中会有拥护 PostgreSQL 而排挤 MySQL 的情绪~~
但产品终究是用来应用的,所以希望大家能针对这两款数据库,结合当下最新的状况,对其在 FreeBSD 下的运行特性,做一些建设性的讨论~~
我是从去年12月与老板沟通后才开始打算将系统逐步向postgresql迁移,之前的数据库有ms sql,mysql。自从我逐步开始迁移到debian+postgresql8.3.7系统之后,到目前为止,尚无什么问题,运行一直都很稳定。
还有一点,很多习惯用mysql的人总喜欢用postgresql的进程访问方式为诟病,其实我个人认为这完全是对unix/linux的进程和线程历史理解的缺乏。据我个人所知,oralce在windows中采用了线程访问方式,这主要是windows中进程的上下文切换的代价要远远比 unix/linux大的多。而oracle在unix/linux则推荐使用进程方式,进程方式拥有高得多的可靠性和数据完整性,因为一个Oracle 进程不可能污染另一个Oracle进程的地址空间,此外oracle的进程方式反而能够稍微更好的提升性能。除此之外,有过unix/linux开发的都知道一些,就是unix包括freebsd中的线程在kernel中实际是一种变相的进程方式运行,只有linux2.6内核以后的线程才开始似乎摆脱了这种情况与进程独立开来。此外在真正的系统运行过程中,难道有人真的会傻的认为1000个线程的并发访问性能会高于2个进程?姑且不说别的,单就2.6的 linux内核创建posix 线程的时候,默认为线程预留2M内存,100线程就开始占用200M内存(当然这个可以调节),此外100线程的上下文切换带来的性能损失远远高于预想的代价。尤其面对大多数高并发的数据库访问,都采用类似数据库连接池方式,在此方式中,如果访问突破某个阀值点,越是高并发,持续时间越久,多cpu,反而越是进程的性能,稳定优势开始集中体现出来。
往往很多人的测试都还在这个阀值点之下,随便写个test程序发布上去搞搞测试,就天天叫嚣着进程如何如何不好。这种才是糊弄一批人。
网上有人比较了lighttpd 的 fastcgi 的进程和线程访问方式,他利用高并发详细测试进程和线程在不同情况下的情况,这其实跟数据库这种方式类似,希望以后客观的说明不要再误导人了。
甚至有次我看到某人疑问,1000客户端访问那难道数据库要启动1000个进程?某人借此来论述postgresql的进程模型如何不好不好。当时正在喝水,我差点都要喷出来。
我想即便是线程模型,也不会傻到1000个客户端连接上来,去启动1000个线程。1000个线程即便启动了,上下文的切换一损耗,说不定还不如2线程跑得快。
postgresql是一个很不错的优秀数据库,我最近也在尝试看他的源码,觉得甚有感触。虽然他的进程模型目前尚没有表现出来最强的优势,但这绝不是进程模型的问题。
我主导的几个系统运行在debian+postgresql+Ice平台上,服务端足够的高并发访问,那核心是基于socket访问的,一直很稳定,我真不知道某些人的疑问从何而来
的确,MySQL 是最快的。
正因为 MyISAM 不支持事务,所以 MySQL 后来引入了 InnoDB。
最新版的 MySQL 已经支持 MyISAM 里的外键,InnoDB 的效率也在提升。个人认为,MySQL 完全可以胜任业务需求,在需要事务安全的部位使用 InnoDB 引擎,其它要求性能的地方可以用 MyISAM。
但最近突然对 PostgreSQL 感了兴趣,就查了很多相关资料,总结下来,呈现 PostgreSQL 比 MySQL 强的多这么一个结论。但是大部分能查到的评论都出自几年前,那个时候的 MySQL 被戏称为玩具数据库。重要的是,MySQL 这几年的发展十分迅速,提供了很多商业数据库必不可少的功能特性,从我这个对 PostgreSQL 不是很了解的角度来看,两者对于我的应用而言,差别已经不是很大了。
其实心中还有这么一个情结:总觉得采用 BSD 许可证,和同样是出自加州伯克利分校的 PostgreSQL,能够更好的在 FreeBSD 上面运行。因为 MySQL 是 Linux 阵营的东西,所以作为 FreeBSD 的忠实用户,不免心中会有拥护 PostgreSQL 而排挤 MySQL 的情绪~~
但产品终究是用来应用的,所以希望大家能针对这两款数据库,结合当下最新的状况,对其在 FreeBSD 下的运行特性,做一些建设性的讨论~~
我是从去年12月与老板沟通后才开始打算将系统逐步向postgresql迁移,之前的数据库有ms sql,mysql。自从我逐步开始迁移到debian+postgresql8.3.7系统之后,到目前为止,尚无什么问题,运行一直都很稳定。
还有一点,很多习惯用mysql的人总喜欢用postgresql的进程访问方式为诟病,其实我个人认为这完全是对unix/linux的进程和线程历史理解的缺乏。据我个人所知,oralce在windows中采用了线程访问方式,这主要是windows中进程的上下文切换的代价要远远比 unix/linux大的多。而oracle在unix/linux则推荐使用进程方式,进程方式拥有高得多的可靠性和数据完整性,因为一个Oracle 进程不可能污染另一个Oracle进程的地址空间,此外oracle的进程方式反而能够稍微更好的提升性能。除此之外,有过unix/linux开发的都知道一些,就是unix包括freebsd中的线程在kernel中实际是一种变相的进程方式运行,只有linux2.6内核以后的线程才开始似乎摆脱了这种情况与进程独立开来。此外在真正的系统运行过程中,难道有人真的会傻的认为1000个线程的并发访问性能会高于2个进程?姑且不说别的,单就2.6的 linux内核创建posix 线程的时候,默认为线程预留2M内存,100线程就开始占用200M内存(当然这个可以调节),此外100线程的上下文切换带来的性能损失远远高于预想的代价。尤其面对大多数高并发的数据库访问,都采用类似数据库连接池方式,在此方式中,如果访问突破某个阀值点,越是高并发,持续时间越久,多cpu,反而越是进程的性能,稳定优势开始集中体现出来。
往往很多人的测试都还在这个阀值点之下,随便写个test程序发布上去搞搞测试,就天天叫嚣着进程如何如何不好。这种才是糊弄一批人。
网上有人比较了lighttpd 的 fastcgi 的进程和线程访问方式,他利用高并发详细测试进程和线程在不同情况下的情况,这其实跟数据库这种方式类似,希望以后客观的说明不要再误导人了。
甚至有次我看到某人疑问,1000客户端访问那难道数据库要启动1000个进程?某人借此来论述postgresql的进程模型如何不好不好。当时正在喝水,我差点都要喷出来。
我想即便是线程模型,也不会傻到1000个客户端连接上来,去启动1000个线程。1000个线程即便启动了,上下文的切换一损耗,说不定还不如2线程跑得快。
postgresql是一个很不错的优秀数据库,我最近也在尝试看他的源码,觉得甚有感触。虽然他的进程模型目前尚没有表现出来最强的优势,但这绝不是进程模型的问题。
我主导的几个系统运行在debian+postgresql+Ice平台上,服务端足够的高并发访问,那核心是基于socket访问的,一直很稳定,我真不知道某些人的疑问从何而来
的确,MySQL 是最快的。
正因为 MyISAM 不支持事务,所以 MySQL 后来引入了 InnoDB。
最新版的 MySQL 已经支持 MyISAM 里的外键,InnoDB 的效率也在提升。个人认为,MySQL 完全可以胜任业务需求,在需要事务安全的部位使用 InnoDB 引擎,其它要求性能的地方可以用 MyISAM。
作者:jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美,在于尽态极妍 | 应用之美,在于药到病除
地址:https://jackxiang.com/post/2585/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明!
评论列表