PostgreSQL 杂谈第一节，开篇

研究PostgreSQL数据库已经有好些年了，一直没能用上。最近，我准备迁移DotNetNuke到Mono平台上去（代号MonoNuke），是重新认识PostgreSQL的时候，这关系到这个项发是否可行。对于Linux软件方案，PostgreSQL寄托着很多开发者的梦想。不管是java、php、perl、ruby或者其他的，我们知道，问题不在于使用什么样的语言，而在于采用什么样的架构和方案。数据库是应用程序及解决方案中的重要环节。信息蕴藏这大量的机遇和财富，对每一个人都很重要。就MonoNuke的设想而言，数据库也是最重要的问题之一。

      使用PostgreSQL的第一个困惑在于类型，就像学习C语言或者汇编语言一样，第一个需要阐明的概念就是类型，而PostgreSQL几乎提供了所有数据库系统中最丰富的类型（就我所知），我们知道软件里有一个很重要的法则就是2/8法则，把80%的精力放到20%重要的功能上去，而PostgreSQL不是，PostgreSQL给我的第一个感觉就是浅尝辄止。学术产品和商业产品（或者我们心目中合格的产品）最重要的差别在于可靠性，仅仅做一件事情可能20行代码就能解决问题，但是如果要把他放到商业软件中去，那么可能会扩充到80行甚至更多。这还不包括为了照顾总体模型所增加的代码代价。就我而言，我希望PostgreSQL是可靠的，如果能够做到这一点，多一些功能也无妨。但是，很不幸，在我的实验环境中，PostgreSQL for Windows 不是很稳定，这多少有些让人伤心。我知道，这种状况在Linux几乎不会出现，Linux版本的PostgreSQL很稳定，毕竟Windows 版本只是一个迁移版本，主要的代码模型是基于Unix族的。PostgreSQL有众多的类型，但是我可能不会在我的项目中使用不常用的类型，主要的问题不在于复杂和担心扩展类型的可靠行，而是我觉的数据库系统做了自己不该做的事情。数据库系统的任务应该是存储、检索和协助管理，扩展类型夹杂了太多的逻辑到其中。正确的做法应该把这些放到客户代码中去，我明白数据库fans们总是期待能够改进我们的模型，并且热衷于加入更多的功能，现在处理这种关系很复杂，相信这也很难为PostgreSQL的项目管理小组：一方面，对学术而言，重要任务和价值取向是发现理论和探索可行性，而不是尽最大努力让系统变得可靠。因此，对于研究者而言，特别是不侧重与商业应用的人而言，改进系统有时就像令人乏味的重复活，我很理解这种感情。但是这正是我们系统所遇到的问题，不管将系统是推销给谁，总是期待能够帮助他人达到目的，如果系统是不可靠的或者说是低效的，那么通常这会伤害别人对软件的信任，在这里就是失去对PostgreSQL的信任。伯克利分校的数据库研究很有趣，通过研究相关的理论我们能发现学术的神奇之处，如果准备研究这个数据库系统，建议准备英语字典、数学字典和打印机；另一方面，对许多志愿者而言，志愿者倾向做创新的工作以展现自己的价值，让系统少死两次机并不会引起其他人的注意，相反增加新的模块和功能可能更符合他们的要求；还有，对于开源软件而言，更重要的是维护整个社团的和谐发展和生态圈。因此，这通常意味着不容易进行架构上的改进，关系数据库的技术已经处于稳定状态，研究者通常并不指望在这一领域能有惊天的作为，而会更加关注应用方面，因此底层的数据库研究者数量就会降低，这对PostgreSQL这中纯开源数据库而言，有些不利。

        影响PostgreSQL发展的第二个问题在于，PostgreSQL采用了进程模型，问题不在于进程模型和线程模型之间的差异，在于windows族和Unix族操作系统对于进程和线程处理的差异，对于进程模型，很多人都是直接的给予批评，从某种程度上而言，这是由于误解导致的：在现代的计算机科学教育中，我们对于进程和线程的第一个认识就是，进程是操作系统分配资源的单位，线程是运行的单位，再程序设计时，应该优先考虑采用线程模型而不是进程模型。利益主体决定模型取向，对于程序而言，增加一个新进程将会额外分配新的资源，显然者要比在父进程中启动一个线程能占有更多的资源，如果启动一个线程，那么她会分享进程的资源；如果让操作系统决定，系统可能更倾向于使用线程。由于系统设计的不同，影响了进程和线程的使用：

首先，因为资源分配的问题，启动进程是需要时间的，特别是在windows平台下，这能有效的防止蠕虫类程序的泛滥（应该只能能起一定的作用）；

对于线程，不同的系统实现方法是不同的，对于Windows而言，所有的线程都是内核线程，系统统一处理线程的问题，并且，这跟系统的消息机制也有关系，影响了windows的性能（有时是正面，有时是负面的）。而对于Unix族而言，系统在用户库层面上实现线程库，这影响了系统对对线程优势的发掘；由于历史的原因，Unix族平台程序喜欢使用进程模型，并且表现的也很好，Apache 服务器就是一个例子，Unix平台更像是一个专用平台，所以他关注的是把一件事情做好，因此相对于线程所带来的优势，服务器系统更喜欢核心部分占有更多的资源，进程模型是一个好方法。

影响进程和线程的另一个问题在于系统的资源模型，由于Unix族系统是一个弱模型的系统，系统通过抽象文件接口，把资源抽象到文件接口层面。由于系统相对较简单，没有复杂的模型和过多的层次，因此进程间通信的效率相对较高，方法也较多。而对于windows而言，windows系统是基于模型的系统。系统有明确的模型和分层，因此进程间通信的代价较高，并且使用资源的代价也较高，这就导致进程模型很不适合windows系统。对于PostgreSQL而言，这带来的直接问题就是，PostgreSQL应该针对平台重新设计，这对志愿者社区而言，很明显，成本太高，不太可能。维护两份代码基成本是很可怕的，这导致了PostgreSQL在Windows平台所遇到的问题。社团已经做了很大的努力改进 PostgreSQL在 windows平台下的表现，特别是新版的PostgreSQL使用Visual C++ 2005完成编译工作，这很大程度上改进了系统的性能，Visual C++ 编译器的表现是一直比较不错，我认为。问题在于，如果不能改进模型，那么问题将始终无法得到解决。就我们的方案而言，这个问题并没有实质性的影响，因为我们的系统本来就是定位在Linux平台上运行的，了解一下PostgreSQL对于未来使用它应该是一种优势。

       PostgreSQL将扮演Mono平台战略中SQL Server 的角色，了解它是我们前进的有力助手。

       希望关于进程和线程的讨论不要引发战争。