PostgreSQL 杂谈第一节,开篇

研究PostgreSQL数据库已经有好些年了,一直没能用上。最近,我准备迁移DotNetNukeMono平台上去(代号MonoNuke),是重新认识PostgreSQL的时候,这关系到这个项发是否可行。对于Linux软件方案,PostgreSQL寄托着很多开发者的梦想。不管是javaphpperlruby或者其他的,我们知道,问题不在于使用什么样的语言,而在于采用什么样的架构和方案。数据库是应用程序及解决方案中的重要环节。信息蕴藏这大量的机遇和财富,对每一个人都很重要。就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应该针对平台重新设计,这对志愿者社区而言,很明显,成本太高,不太可能。维护两份代码基成本是很可怕的,这导致了PostgreSQLWindows平台所遇到的问题。社团已经做了很大的努力改进 PostgreSQL windows平台下的表现,特别是新版的PostgreSQL使用Visual C++ 2005完成编译工作,这很大程度上改进了系统的性能,Visual C++ 编译器的表现是一直比较不错,我认为。问题在于,如果不能改进模型,那么问题将始终无法得到解决。就我们的方案而言,这个问题并没有实质性的影响,因为我们的系统本来就是定位在Linux平台上运行的,了解一下PostgreSQL对于未来使用它应该是一种优势。

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

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

你可能感兴趣的:(PostgreSQL)