https://jackxiang.com/index.php zh-cn https://jackxiang.com/post// jack <xdy108@126.com> Mon, 18 Jan 2010 07:57:09 +0000 https://jackxiang.com/post//
但最近突然对 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。 ]]> https://jackxiang.com/post//#blogcomment <user@domain.com> Thu, 01 Jan 1970 00:00:00 +0000 https://jackxiang.com/post//#blogcomment