骑虎的康盛，两难的站长，关于Discuz发展的讨论

本文因为某些问题因而在我个人空间中被管理隐藏不显示，故存档于 http://xiaozhong.biz/thread-274-1-1.html

午休有点时间，就随便写写

DZ2.5出了一段时间了，可这官网论坛的bug版块可越来越热闹。神马问题的都有，神奇的是版主的回复往往都是“我这儿测试没问题”。这可就奇怪了，不少问题是很多人发帖都遇到的， 排除站长方面非技术问题（比如设置有误、中毒、网络出问题），总有和技术（程序代码）有关的疑难吧，可为何官方人员测试又正常呢？

康盛的版主可能就没仔细考虑过原因所在。刚才灵光一闪忽然明白了 ～～ 那就是版主测试的系统数据是“逻辑”完整的，而站长们的数据往往是“逻辑”不完整甚至有错误的。所以有缺陷的代码引发的bug无法在版主那儿被触发。这细节说来可就话长了，时间不多，在此简要分析之。

不少站长是从老版本一路升级上来，因为DZ本身代码缺陷以及没使用数据库事务（Transaction,）来保证数据之间参考完整性导致在对数据库进行写入操作（发帖、删帖）时会因为各种原因产生数据逻辑错误。比如删除主题时先把所有回帖删除，待删除主题时出错，这种情况还好办最多是个无回帖的光主题。如果是版主前台删除主题到回收站，程序先把主题打上删除标签，在写入回收站表（7.2下是threadsmod）时出错，这就会产生在后台看到回收站有N个主题，点击进去却没记录的状况。这也好办，如果遇上合并版块、合并/拆分主题(7.2在拆分时代码有bug)、删除用户等大数据量长操作时间的操作时一旦中途出错停止，数据库无法回滚数据（rollback），这问题可就不小了罗。
再加上垃圾的msyql时不时表崩溃等让你来修复，这数据可就一团乱麻了。

这种情况下老系统还能凑合用，一旦升级了新系统。新来方丈这经可就不好念哟：逻辑错误的数据将会被新系统新增的功能、模块所访问使用并产生一系列‘灵异’故障。说灵异是因为这代码在官方那儿可是跑得欢，但到了站长庙里就蔫了～

数据库数据逻辑错误这问题看似简单但不好解决——直接删除错误数据一了百了，但哪些有用哪些无用该如何判断？ 如果要转换有用的错误数据，又该如何重新关联、重建相关环境数据呢？

说到底，这根就在这MySQL上了。大家都知道mysql傻快，但往往不知道为啥快。简而言之就是因为“简单”，程序代码简单，功能也简单——处理个简单SQL查询很快，一旦是多表连接多条件查询，立马现原形，要做结果差集操作？没门，这正是mysql不能被严格成为“关系型数据库”（RDBMS）的原因。
在discuz X系列以前，站长论坛累计的数据量不大，一般就百万条帖子吧。虽然dz代码有缺陷，mysql不给力但还是能跑跑的（忽然想起《活着》中那句‘急了也能跑’，哈哈）。到X推出后现今数据量超千万的站也不会少了，虽然康盛对新版程序构架优化、数据库优化分库上做了不少改进，但这些改进带来的一点提升却被暴增的新功能所吞噬尽，反而因为更加复杂的SQL或者因为服务器分表的多次查询延迟而更加恶化——代码级的优化已经无法环节系统的缓慢。mysql只能接受简单的查询，对于新增的关系复杂的功能多带来的复杂查询条件力不从心。

数据库此时就是整个系统的瓶颈。

即便采用了内存缓存技术（memcache），可总是有数据要写入数据库的，比如session，pv，在线时间等等。myisam一写表就锁表，遇上高流量即便没有发帖系统照样扛不住。你说换支持行锁的innodb引擎吧，可mysql不能再说自己飞快了，一个 SELECT count(*)就能让系统龟速。最坑爹的是才知道innodb的所谓行锁是锁索引，使用也是有条件的：

InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。
（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
（2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是 使用相同的索引键，是会出现锁冲突的。应用设计的时候要注意这一点。
（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索 引或普通索引，InnoDB都会使用行锁来对数据加锁。
（4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决 定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突 时，别忘了检查SQL的执行计划，以确认是否真正使用了索引

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的 索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁 （Next-Key锁）。

这真难办啊，myisam是快，可是大并发下锁表阻塞严重，还时不时抽风坏表；innodb支持事务（先不谈支持的程度）不坏表吧可速度就慢多了（尤其是对于论坛这种经常要做select count(*)操作的）。这mysql众多引擎，各有特色，可就没一顺手放心的，还是那句话，就一坑爹的要你命3000（不知道的去看周星星的《大内密探零零七》）。
可康盛已经被mysql所捆绑了，构架优化都是针对MySQL的，比如分表到服务器，查询SQL切分连表操作为多个单表查询。要换数据库？还不如重写DZ呢。
现有新增功能已经因为历史数据而产生多多的问题，也让数据库更加疲惫，所以对于站长对新功能的呼声，官方只能忽视了。

骑虎之势的康盛～～

要说这些改进无用是不正确的，可对于普通站长来说如果想要论坛跑得欢，就得考虑如下配置：
1台或以上web服务器，2台或以上数据库服务器，1台或以上附件服务器，再加上可能的多台反向代理服务器（跑nginx反向代理或者vanish图片缓存）……
不带这么玩的吧～ 不说服务器造价，光是IDC托管费用就是普通站长无法负担的

悲摧郁闷的站长……


即便到现在7.2的bug现在依然不少： http://www.oschina.net/question/126398_36342  
X2.5只会更多～

ADD：
对于站长来说，如果自己不懂编程也不愿意花钱找人维护系统，那么只能是跟随DZ的升级而解决bug问题。不过DZX系列从之前的纯论坛转变到社区系统，这并不适合部分站长纯论坛小巧快速的要求。不升级？无法解决bug；升级？功能庞大并且bug也多。是谓两难。

枯心树 发表于 2012-6-6 22:20

直观技术对比：  http://bbs.chinaunix.net/thread-1688208-1-1.html   

更详尽的技术对比：  http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#COUNT.28.2A.29

关于主从技术对比： http://www.theserverside.com/feature/Comparing-MySQL-and-Postgres-90-Replication
pgsql是wal-base底层同步，主库所有变动后信息完整同步到从库。mysql是statement-base表达式同步主库上执行的SQL会在从库上重新“执行”一次，这种方式可会会因为从库数据冲突导致复制失败。

关于堆表与索引组织表的对比： http://www.itpub.net/thread-1382702-1-1.html

我最近获悉，PostgreSQL跟InnoDB一样也支持通过主键索引顺序遍历（译者注：InnoDB访问全表返回数据按主键顺序排列）。对于 InnoDB，这意味着所有的全表扫描是在扫描主键索引，主键索引本身就是表。据我了解，这可能导致大的顺序扫描慢很多（译者注：这个比较扯淡，在数据静止的情况下，PostgreSQL一样要通过block的指针访问下一个block，InnoDB通过页的指针访问下一个页）。在PostgreSQL，因为表不是按（主键）索引组织，顺序扫描总是按物理顺序进行，并且完全不需要访问索引，这也意味着我们可以跳过任何访问索引非叶子节点的IO或CPU开销（译者注：这位兄台应该忘记了什么是B+树）。显然按物理顺序访问是很困难的，但是肯定可以实现，因为Oracle支持。这是MySQL一个非常有用的功能，PostgreSQL一旦有了覆盖索引扫描功能，对PostgreSQL也将是非常有用的提升。


pgsql9.2beta已经实现类似覆盖索引扫描功能，就此mysql的性能优势更小了：

•             Allow queries to retrieve data only from indexes,            avoiding heap access (Robert Haas, Ibrar Ahmed, Heikki            Linnakangas, Tom Lane)
              This is often called "index-only scans", a feature            which now enables the use of indexes with additional            columns, or "covering indexes". This is possible for            heap pages with exclusively all-visible tuples, as            reported by the visibility map. The visibility map was            made crash-safe as a necessary part of implementing            this feature.
  

http://www.postgresql.org/docs/devel/static/release-9-2.html

pgsql与mysql性能对比： http://www.oschina.net/question/126398_23854
此文是摘要，文中有原文链接。对比的是MySQL 5.1.30 and PostgreSQL 8.3.7。pg版本比较低，现在最新稳定版是9.1.3。原文有这么一段

I’m a full time MySQL DBA who loves PostgreSQL. :)
Completely sick and tired of the bug of the week. I’m perfectly happy to deal with a few planner warts in certain circumstances on PG vs completely hair brained bug and improper feature additions in MySQL.
PostgreSQL has a significantly better planner overall and supports many different types of joins. MySQL isn’t cost based and only supports loop joins.
MySQL is a toy.

Mysql 全职DBA对PG的公正评价

相关讨论记录：
http://www.oschina.net/question/96003_18961
http://www.oschina.net/question/96003_13994

这是我之前一个主题，里面有相关对比分析：http://xiaozhong.biz/thread-272-1-1.html

“In PostgreSQL there is no built-in mechanism for limiting database size. This is the main reason why the most of the web hosting companies are using MySQL.”

mysql可以限制表行数，DZ后台设置中“限制登录用户最大数”就是使用这个功能。这也是很多主机商提供mysql的一个重要原因：可以限制客户数据库容量。



简单来说，mysql简单快速，但在大数据量大并发下性能急剧恶化，并且存在表损坏这种对于在其他数据库看起来绝对无法接受的问题；pgsql功能强大，在普通应用中能与商业数据库相媲美，对系统资源消耗较高。 但极其安全，基本上不可能出现库表崩溃的情况。即便因为外部因素比如磁盘崩溃，pgsql也有抵抗能力。
对于资源消耗这点，pgsql占用资源高所以可以承受高并发，而mysql看似占用资源小，但实际上即便有充足资源它也无法有效利用结果是无法应付高并发。  这就是为啥往往硬件配置不错但mysql CPU及内存占用总不高的系统缓慢原因。

另外，pgsql在日本使用率非常高。许多公司采用它，包括外包到中国的项目。

mark35 发表于 2012-6-7 10:42
直观技术对比：  http://bbs.chinaunix.net/thread-1688208-1-1.html  
  (CU正在维护中)

更详尽的 ...

主机商那边还好对付，安装两种数据库就可以支持。问题是程序那边。

你还没有说明，如果需要过度到新的数据库平台pgsql，容易吗？这个问题最主要。

主要是转换数据库平台这个影响太大了。如果需要过度，那么DZ就必须要从新写？哇，这个工程浩大了，没有三年五载估计不行吧？

六、那么我究竟应该使用MySQL还是PostgreSQL

这个问题很难说得清，而且事实上除了MySQL和PostgreSQL外，使用Oracle、Sybase、Informix等也是明智的选择。如何你确定只在MySQL和PostgreSQL中进行选择，以下规则总是有效的。

1、如果你的操作系统是Windows，你应该使用MySQL。

2、如果你对数据库并不了十分了解，甚至不知道事务、存储过程等究竟是什么，你应该使用MySQL。

3、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。例如是一个论坛和社区，你应该使用MySQL。

4、你的应用是一个严肃的商业应用，对数据完整性要求很高。而且你希望对一些商业数据逻辑进行很好的封装，例如是一个网上银行，你应该使用PostgreSQL。

5、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。

6、你是一个数据库内核的狂热爱好者，你甚至希望拥有你自己版本的数据库，毫无疑问，你必须使用PostgreSQL，没准下一个PostgreSQL版本中某一个模块的作者就是你。

原文地址：http://it.chinawin.net/database/article-5c10.html

mysql好像支持事务了，那是不是说明程序可以针对性的优化？那你说的那些问题影响会不会降低很多呢？

感觉最主要估计是pgsql对微软系统支持不是很好。如果可解决这个问题。估计普及就好很多了.. 速度如果相差不是很大，pgsql倒也不失为一个可以考虑的对象。

开源数据库不一样的声音！您所不了解的PostgreSQL！（获奖名单已公布-2012-5-23）
http://bbs.chinaunix.net/thread-3701209-1-1.html

在技术上，我觉得POSTGRESQL跟商业的数据库上差异并不很大，随着更多的商业公司开始资助POSTGRESQL项目，这种技术上的差异，会更加缩小，
比如著名的网络电话公司SKYPE使用POSTGRESQL支撑全球业务，巴西CAIXA银行核心业务上使用它，就有力地证明在技术上的可行。

在海量数据处理年代，使用传统的商业数据库成本越来越昂贵，而事实上，新崛起的大型网络数据处理公司，基本上都是用开源解决方案，连淘宝这种有钱的公司，也开始逐步要“去ORACLE化”，可见，开源数据库的应用具有趋势性，掌握一种主流的开源数据库，是从事数据处理技术人员的一种必须工具。

POSTGRESQL由于在8.0之前，没有原生的WINDOWS版，导致应用面比较窄，使MYSQL这种缺乏很多数据库基本特性的产品，大行其道。

现在我们公司的一个小型系统中，就使用了POSTGRESQL来处理数据，感觉很爽，我可以在LINUX、FREEBSD等操作系统中测试折腾，在配置文件中，设定参数，调整优化，还可以看源代码，他们是怎么处理的（虽然看不太懂，但起码也能满足我的好奇心
^_^），使用微软的SQL
SERVER就无法有这种体验和乐趣。

在稳定性上，采用进程体系的，比线程要稳定，因为线程体系，很多数据都是共享的，一旦某个线程出了问题，就会污染公共数据，导致整体系统错误，
而进程体系的数据库，大部分都有自己的数据空间，不需要共享，出错也只能影响本进程，对其他进程不影响。这就是ORACLE、DB2比SQL
SERVER要稳定的原因。而POSTGRESQ就是进程体系，所以，它比采用线程的MYSQL
要稳定多。

POSTGRESQL的存储过程语法和常用函数跟ORACLE一模一样，从开发员的角度上，掌握了PG的存储过程编写，就几乎很容易学会ORACLE的存储过程编写，特别是现在新版的DB2也兼容ORACLE语法，所以，学会POSTGRESQL开发，就几乎会ORACLE，DB2开发，一举三得！而MY
SQL跟ORACLE语法和函数相差大，学习成本高太多了。


希望POSTGRESQL的下一版中，能加个调度功能，就像SQL
SERVER代理服务器那样，可以在里面设定调度任务，比如做备份，虽然现在可以通过操作系统来实现，但觉得还是有些问题。

另外，在过程语言中，不知道现是否有类似ORACLE的
BULK COLLECT功能，加快批量数据处理速度，如果没有，希望能再加上这个特性。
原文：http://bbs.chinaunix.net/forum.php?mod=redirect&goto=findpost&ptid=3701209&pid=22020116

这贴也很精彩。值得看一下。偶是大开眼界了。。哈哈。行外人。见笑了。

枯心树 发表于 2012-6-12 01:22
主机商那边还好对付，安装两种数据库就可以支持。问题是程序那边。

你还没有说明，如果需要过度到 ...

mysql可以做成一键LAMP安装，pgsql因为安全性相对很高所以安装不太方便，VPS还好点，在虚拟空间上就只能看空间商是否提供了。能提供pgsql的空间商很少。

如果需要过度到新的数据库平台pgsql，容易吗？这个问题最主要。主要是转换数据库平台这个影响太大了。如果需要过度，那么DZ就必须要从新写？哇，这个工程浩大了，没有三年五载估计不行吧？

如果照标准生成SQL那么更换底层数据库不是难事，只是mysql这家伙不太兼容ANSI SQL，基础的SQL98支持都很差不要说新的SQL2003, SQL2007了。导致移植时要修改许多地方，最坑爹的有三个：
1、LIMIT x,y 虽然mysql也支持 LIMIT y OFFSET x的格式，但貌似mysqler只会前者
2、$db->insert_id() 用二次查询的方式获得最近插入值，这是因为mysql没有序列生成器（Sequence）只有Autoincreament。
3、SELECT * FROM ...GROUP BY id 不在GROUP BY中字段必须使用聚集函数，但几乎所有mysqler都是这种写法，并且mysql居然也能执行
后两者简直是贻害无穷。

7.2我自己修改移植到pgsql花了半年时间
http://waiting.iteye.com/blog/1378551
http://www.oschina.net/code/snippet_126398_8411
X系列架构更复杂，不过估计要不了三五年。
另外，个人认为X系列数据库构架越整越复杂，许多优化是基于MySQL低能弱智之处，削足适屐，更加越难以移植。

http://it.chinawin.net/database/article-5c10.html你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。

MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。

MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。

这篇文章实在太老了不少结论是过时甚至错误的， MySQL 4.0.2-alpha和PostgreSQL 7.2都是很老的版本。mysql目前5.5，功能变化不太大。但pgsql到现在的变化实在是非常大。pgsql现在已经不支持R-tree索引，不过对GIS地理数据支持却是加强了。
在高并发下，多进程模式的pgsql在资源占用、连接速度上会有影响，不过可以通过连接池解决。比如pgbouncer。
pgsql自8.3开始支持 autovacuum/autoanalyze，可以在postgresql.conf中设定自动处理运行的触发规则。

http://bbs.chinaunix.net/forum.php?mod=viewthread&tid=3701209&page=6#pid21998370
在MySQL中你失去的主要功能是subselect语句，而这正是其它的所有数据库都具有的。换而言之，这个失去的功能是一个痛苦，但是它可以被克服。

局限性
Postgres的主要局限性并不是它的性能（因为大多数网站将永远不会陷入这个问题）。但是由于编码硬化的限制，像每行8k的限制（日期会回到以前的时期）。当我使用Postgres设计Geocrawler.com，我不得不将大的e-mail分成每8k一块以绕过这个僵硬的限制。在默认情况下，Postgres被编译成只支持32个连接，这是不足以用来作高流量网站应用的，特别是考虑到Postgres生成每页的速度要比MySQL慢。

另一个限制可警惕许多PHP的用户：Postgres没有与MySQL的mysql_insertid()等价的函数调用。如果在MySQL的数据库中插入一行数据，MySQL将返回这行主关键字的ID。而在Postgres中完成这样一个操作需要绕许多圈子，这是一件非常头痛的事，而且如果用的多可能会降低效率

mysql 5开始支持子查询（subquery），不过有限制，其中一条是子查询中不能使用LIMIT/ORDER BY。
至于pgsql的行8K限制是老皇历了，新版本不存在此问题。由于使用了TOAST行外存储技术，对于超大内容字段的值是保存在外表中，结合pgsql的HOT更新技术极大减轻对主表的性能影响。

POSTGRESQL由于在8.0之前，没有原生的WINDOWS版，导致应用面比较窄，使MYSQL这种缺乏很多数据库基本特性的产品，大行其道。

pgsql以前版本对windows支持不好（也许是因为win本身太差了吧）。安装程序还有个bug：安装过程中选择地区（有关默认字符集）如果选择的不是C而是中国啥，那么安装完毕初始化集群（initdb）就会出错。
目前最新版9.1的windows版安装程序据说没这个问题了。

mysql5号称支持事务，不过仅限innodb引擎，myisam仍然不支持，或者是用不到这么高级的功能……
即便支持事务的innodb引擎，在执行DDL时无法事务回滚，并且将会强行提交未提交的事务 ，所以说“支持”和“实现”有差别，“实现”和“实用”又是另外一个差别。同样情况也适应适用mysql的分区表技术～

第一次真正接触PostgreSQL，是通过greenplum数据库。
后台完全的PostgreSQL，数据处理性能强大的令人震惊，特别能把多核的cpu性能发挥到极致。
同样的服务器，同样的数据，同样的查询语句，MySQL 1到2 个小时，都跑不完的sql语句，gp几分钟就可以出来。

可惜，mysql 就没有类似的产品。。。
http://bbs.chinaunix.net/forum.php?mod=redirect&goto=findpost&ptid=3701209&pid=21994147

拿mysql跑这种业务真的是摧残它那幼小脆弱的心灵残疾低能的身躯啊～

mark35 发表于 2012-6-12 13:56
mysql可以做成一键LAMP安装，pgsql因为安全性相对很高所以安装不太方便，VPS还好点，在虚拟空间上就只能看 ...

这样吧。我把转换pgsql的利弊做一个小小的比较。欢迎大家补充，顺便权衡权衡

认为dx 数据平台需要转换到pgsql的原因可能有以下：
1）mysql不是标准的SQL数据库，牺牲标准来换取速度
2）mysql已被商业公司收购，虽然承若到2014年继续免费。不过最近该公司已经推出了好3个版本的mysql，而且只有社区版本是免费的。不能看出，该公司为了商业版的推广和收费，免费版本的改进势必也肯定不会有很大的突破，至少不可能会以免费版本为重心去开发了。而且收购mysql的公司本身就有自己的知名商业数据库。因此，mysql免费版本就注定了不可能会有很好的发展，至少不明朗
3）mysql已经逐步不适合日益需求的数据库处理要求，经常出现错误不说。而且安全性远远没有后起之秀pgsql那么强大。当然更要命是其不是标准的sql数据库，因此就决定了，转换进程拖得更长，dz随着不断的发展，就更难转换到其他数据库平台了。

pgsql没有以上问题，相反由于其是开源免费的标准数据库，而且使用的是开源的协议，还容许任何人和团体进行2次开发。当然更重要是，pgsql 有着更多的志愿者完善，使用该数据库的站点越来越多，特别是日本大部分都是用该系统。。

认为dx 数据平台不能转换到pgsql的原因可能有以下：

1）mysql 在国内已经占有绝对的市场，而且对win系统的服务器支持比pgsql好，当然最新的pgsql已经解决了这个win系统的安装问题

2)如果需要转换到新的pgsql平台，那么对官方的开发人员以及第三方开发者是一个严峻的挑战。官方开发者都是mysql平台下的开发高手，突然要转换到pgsql平台，估计需要重新学习编程语法，而且官方开发者对pgsql的开发经验几乎是0，更不用说在dz这样的高要求下开发了。搞不好开发团队需要大换血，这样的牺牲太大了。

同时，由于是程序开发官方，如果需要转换到新的pgsql平台，那么开发人员不仅需要精通pgsql数据开发，还要对mysql也精通，毕竟现在国内网络上99%的论坛都是基于mysql的。。单单程序升级转换就头疼。 还有第三方开发团队，如果抛弃mysql，那么他们也必须要重新学习pgsql下的编程，虽然有mysql编程基础，不过毕竟是新的数据库平台，估计很大部分的开发者会选择离开。可以说是动一发牵全身。当然，这样的影响，并不仅仅是程序和第三方开发者，还有现在的云平台，周边产品全部都需要转换到新的pgsql数据库平台，，工作量岂是巨大那么简单？

3）新的数据库平台虽然很强大，适合不断发展的程序对数据库的高要求，不过，由于pgsql对服务器硬件要求教高。当然这个硬件随着硬件行业的发展，会逐渐减轻，不过pgsql数据平台也不断的开发新版本，也会对硬件越来越高的要求。。。



个人看法吧：

pgsql是一个标准数据库平台，开源免费，性能强大，拥有开源的协议。可以二次开发成自己的标准数据库，种种看来，应该会成为未来互联网的数据库主流，至少更符合开源精神。超过先天性不足的mysql也仅仅是时间问题。但是，pgsql的普及需要很多条件，人才，环境，硬件等等。最主要是精通的人才。。

当然，pgsql如果借助国内站点普及率最高的dz和pw论坛，应该可以加快普及率(或者干脆的说，没有dz和其他程序开发商的支持，国内普及基本很难）。因此mysql的轻快，在很长一段时间内（至少5年内，除非全收费了）仍然是中小站点使用的首选吧。

最后，如果pgsql在速度上如果基本达到mysql，而数据库版本的更新对硬件的要求持续降低或者保存不变（相对it硬件的发展），那么普及道路也许会更好走很多。

好吧，对这个话题兴趣了点。就多谈谈。
我很欣赏你旧贴（地址）说的

对于dx功能变化不了解不评论，对于程序架构我的感受是：DZ成也mysql败也mysql

确实让我大吃了一惊。且不说对还是错吧。毕竟自己对技术基本是0。但还是让我想起了动网。动网就是由于其编程语言和数据库平台，才导致它的没落。
如果那天mysql的免费版本被开发公司抛弃或者放慢开发步伐。那么dz步动网后尘也并非没有可能。随着DX2的版本开发进程，越来越多的功能和其他模块或者插件扩展，程序也会越来越多的bug，由于mysql的先天性不足，确实有种危机感越来越重的感觉。

同时，我又想，一旦那天国内某巨头，比如百度开发一款php+pgsql的程序。功能和性能可以媲美dx和pw的。那么会发生什么样的情况呢？？

以百度的影响力和财力，技术，还有对互联网的野心。百度开发网站程序并非是天方夜谭，也许百度早就后悔没有收购康盛。。。

mysql的查询优化器虽然也称为“基于成本的优化器” （CBO: Cost Base Optimizer）  但实践中对于多条索引的选择尚简单，无法采用效率更高的索引


加上dz自身对于数据表索引的优化也不足够，所以dz的性能受到不少影响。用户从dz后台也无法获得直观数据库运行数据来判断数据库性能，最多的恐怕就是“修复”了吧……

这是pg可以提供的信息，


对于cdb_members 这张表，尺寸是78MB，无行外存储。绝大部分是更新，极少的删除。HOT更新次数接近总更新次数，说明数据碎片不会大，执行VACUUM紧迫性不高。
关于HOT更新技术：

大家知道PostgreSQL使用多版本技术，对记录的更新操作都会产生一个新版本，版本之间从老到新形成一条版本链。此外更新操作不但会在堆中产生记录的新版本，在表的每个索引中也会产生新版本的索引记录。即对一条记录的每个版本都有对应版本的索引记录，即使更新操作没有修改索引属性，也会在每个索引中都产生一个新版本。这一技术的问题是浪费存储空间，老旧版本占用的空间只有在进行VACUUM时老能被回收，增加的数据库的负担。

为减轻这一问题，PostgreSQL 8.3中加入了HOT技术。使用HOT后，若所有索引属性都没被修改（索引键是否修改是在执行时逐行判断的，因此若一条UPDATE语句修改了某属性，但前后值相同则认为没有修改），且新版本与原版本存储在一个页面上则不会产生新的索引记录，因此这些记录被称为HOT（Heap Only Tuple）。HOT会被打上HEAP_ONLY_TUPLE标志，而HOT的上一个版本则被打上HEAP_HOT_UPDATED标志。当通过索引获取记录时首先会找到同一页中最老的拥有HEAP_ONLY_TUPLE标志的版本，然后顺着版本链向后找，直到遇到HOT为止。限制HEAP_ONLY_TUPLE版本与HOT在同一页的目的是为了通过版本链向后找时不产生额外的IO操作从而影响到性能。因此HOT技术消除了拥有完全相同键值的索引记录，减小了索引大小。

这个图片显示数据表状态。对于用户表，估算是14万行记录，顺序扫描了2.7K次，索引扫描了30M次，索引扫描占了99.99%，影响速度的全表扫描几乎没有，说明索引效率极高。
后面的删除率及更新率（百分率）如果较高的话就说明此表需要做整理（VACUUM）了，尤其是删除率。



这张图显示所有索引的信息。图中可以发现 members.email 这条索引几乎没使用，这要么是没有对email的查询，也可能会是因为索引设置不当pgsql使用了其他的索引而放弃此条索引（对于email这个例子来说不大可能）。
members.bday这条索引使用相当高，说明论坛开启了会员生日的相关功能。

5gss.cn 发表于 2012-6-20 19:00 z这个可以有。分析很透彻 哪种数据库无关紧要 分表多服务器支持亿万级负载

就性能考虑分表的确可极大改善数据库性能，千万级很轻松。不过dz目前的问题一个是数据库性能，另外一个是数据完整性。前者依靠表分区(严格说不是数据库级别的分区)或多服务器可有效解决，后者在目前构架下解决成本很高。随着论坛的运营数据价值日增，数据完整性需求也日益紧迫。涉及积分尤其积分还与金钱挂钩的操作，如果不用事务保护那结果不可预料。

mark35 发表于 2012-6-23 20:23
就技术上，mysql这么多年有多少新功能开发？ 有多少性能提升？
与此对比，学院派的pgsql是不断在进步，不 ...

归根到底还是要看官方如何权衡了。改架构，甚至如dx1.0那样重新写都可以。。但是平台转换，那就需要更更谨慎了。

当然我个人支持pgsql的。但是，还是有很多现实问题需要面对。最主要还是pgsql这方面的人才太稀少了。。。哪怕有，又缺少对dz程序了解的人才。何况包括官方的产品经理就不一定有pgsql下的开发经验。加上现在mysql还没有到不能用，非转不可的地步。勉强再走一两年还是可以的。

还有，想要转换，开发官方的态度是最直接的影响，现在dz被腾讯收购了，这就决定了，仅仅是依靠康盛原来的公司领导已经无法做如此重大的决定了（事实上康盛公司现在越来越少自主权了，可以说到了，开发方向要听腾讯公司，基本没有自主权的地步）。

腾讯会支持吗？我是腾讯，我会冒着这个风险吗？转换到pgsql平台，开发效率必然会慢很多，而现在云平台和还有腾讯开放方面的衔接还有很多想法没有去实现，现在突然转换平台。带来的影响可以说的千万元级别的损失。。这些损失仅仅是重新以pgsql数据库重新开发的人才成本和公司基本运营成本。因此。。想要大规模转换到pgsql。哪怕功能和现在的dx一样，最少也需要1年时间去投入。也就是说，要砸1年的公司运营成本进去。。。如果我是腾讯北京公司的领导，这个决定恐怕做不了，到了深圳总公司马化腾那边，以马总的眼光，性格作风，肯定不会。

因此，目前看来，想要抛弃mysql而转换到pgsql平台，pw那边倒是机会更大。然后利用竞争关系逼dz也转换过来。
毕竟pw目前很难做过dz，干脆破釜沉舟，率先用pgsql的高性能和高安全，高稳定的优点开发全新的php+pgsql平台。

如此原来，用pgsql为pw的的产品，特别社区电子商务方面增加更多动力和发展空间，同时因为是率先转换到pqgsl数据库，由于pgsql的优点，原dz那些大地方站，大客户估计有不少会转换过去，大站转换多了，经过一段时间，pgsql的口碑自然会在站长圈内流传，如此一来，中小站估计也会转换，在dz被迫也转换到pgsql的期间,  pw可以抓住这个时间又继续完善产品。。.搞不好。好吧。我不继续遐想了{:soso_e100:}。

枯心树 发表于 2012-6-24 01:39
归根到底还是要看官方如何权衡了。改架构，甚至如dx1.0那样重新写都可以。。但是平台转换，那就需要更更谨 ...

pg并不比mysql难学，并且因为其更符合标准所以会其他数据库（如oracle/mssql）的人要上手pg是非常容易的。pg的pg/plsql和oracle的pl/pgsql兼容性非常高，会oracle的写pg过程也不存在问题，移植也简单。
相反许多搞oracle/mssql的人转mysql才是痛苦——很多他们认为一个数据库应当具有的功能在mysql是不存在的。
在电子商务方面mysql由于先天缺陷是比较吃力的。
大公司都稳重，要更换一个项目中的选型是很困难的，但大公司的优势在于有财力物力去折腾。如果一味守成，竞争力会日渐衰落。葛洛夫那句“只有偏迟狂才能生存”有一定道理。

后续传送门
【Discuz能有多快？ 见识下postgreSQL的强悍，对比下mysql的低能 】 https://discuz.dismall.com/thread-2990167-1-1.html

【Discuz真实环境中PostgreSQL与myisam查询性能对比，还有人说mysql快么】https://discuz.dismall.com/thread-2993771-1-1.html

以前我跟几个开发者打算把DZ跟Oracle整合，后来，我们都放弃了…………

还不如重写得了。

主要是PHP都被mysql捆绑了……

sw08 发表于 2012-6-1 15:50
以前我跟几个开发者打算把DZ跟Oracle整合，后来，我们都放弃了…………

还不如重写得了。

用PDO即可，我换成了pgsql。mysql不标准的SQL导致移植很困难。

极其痛恨垃圾的mysql：
1、$db->insert_id()
2、 "SELECt * FROM tb .... GROUP BY colx"

看得懂上面两条的会有同样痛苦的感受，看不懂的……你是个mysqler ~

楼主的说的太对了，我们都是从其他版本升级上来的，问题比较多啊，能不能统一下版本啊

是啊 我也觉得站长挺倒霉的

sweetnest 发表于 2012-6-2 22:30
楼主的说的太对了，我们都是从其他版本升级上来的，问题比较多啊，能不能统一下版本啊

相当棘手。1

因为DZ支持指定单个数据表的dump备份及导入。这种做法存在导致数据逻辑错误的可能性。出了逻辑错误也无法发现和修复。

就是一个悲剧

楼主分析透彻，行家啊，可惜上此建议明天就沉了，MARK一下。

我一直用UCHOME，DZX2.5运行实在慢。没有好的服务器，还是不升级了。

没搞明白现在的X2.5到底是面向大部分站长，还是面向大型网站？

唉。

燧人氏 发表于 2012-6-4 22:28
楼主分析透彻，行家啊，可惜上此建议明天就沉了，MARK一下。

我一直用UCHOME，DZX2.5运行实在慢。没有好 ...

X2.5新功能介绍中，表分服务器的新功能看似不错，可又有多少站长供得起多服务器呢。最多一台服务器跑webserver+附件，另外一台跑DB。所以对于多数站长来说X2.5的性能实际上是恶化的。

醍醐灌顶啊。楼主给咱扫盲了。。。

我们的站就杯具了。以后咋整啊？