达梦数据库不是中国自主产权？？？？？

wolfop

原帖由 BTxigua 于 2011-4-2 17:40 发表


你这话说的绝对了，MVCC对业务也很重要。这也不是程序员懒惰不懒惰的问题，要照这个逻辑，那大家就应该不要用数据库了，不要用java了。

MVCC不是数据库必须的，MVCC带来某些方便性的同时也带来很多问题。很多数据库不支持MVCC，也没打算支持。
Oracle自己的Timesten也没有实现MVCC，有什么问题？到底MVCC是什么，你弄清楚了吗？
那么多不支持MVCC的数据库都有在关键系统使用，你有疑问吗？

suwolf

混合型的必须考虑MVCC ，某些专一的可以不考虑MVCC.所以微软要拼命的学啊。

wolfop

原帖由 suwolf 于 2011-4-6 22:20 发表
混合型的必须考虑MVCC ，某些专一的可以不考虑MVCC.所以微软要拼命的学啊。

为什么必须考虑？多个以前的commit版本的数据在业务上带来什么好处。
稽核的时候不用锁表？那需要将状态表和日志表做JOIN才会有这样的好处，可惜谁敢在生产系统这样做。
Timesten/IDS/DB2的做法，有两个版本，一个已经提交版本，一个未提交版本，让程序选择查询谁足够了。
MVCC带来是给数据库更大的开销。

anlinew

原帖由 wolfop 于 2011-4-7 11:01 发表

为什么必须考虑？多个以前的commit版本的数据在业务上带来什么好处。
稽核的时候不用锁表？那需要将状态表和日志表做JOIN才会有这样的好处，可惜谁敢在生产系统这样做。
Timesten/IDS/DB2的做法，有两个版本，一个已经提交版本，一个未提交版本，让程序选择查询谁足够了。
MVCC带来是给数据库更大的开销。

这就是表现出来的最大的问题
oracle更加迎合开发人员尤其是广大低级的程序员以及DBA，让他们可以减少面对锁等待等问题，当然实际上他们会面对更多的因此造成的并发数据错问题，只是这些问题更加隐性

db2/mssql实际上更要命的是其加锁机制的问题
比如mssql 下 表t有 id字段记录唯一
select * from t where id=1 会被update   t set  where id=2阻塞
而id上有唯一键索引字段时就不会被阻塞
这就是说mssql在执行计划的table scan阶段就要对表进行加锁，而实际上从事实上来看，这是不需要的，如果能将加锁的阶段推后到filter之后的结果集，那么sql1就不会被sql2阻塞了
目前的情况就是db2以及mssql锁的范围与sql真正要锁定的结果无关反而与sql执行计划有非常大的关系。因此锁等待的程度与系统中表及索引对象的设计/sql及其执行计划的优化程度有很大的关系，因此也就与系统开发设计以及维护人员的能力有了很大的关系
达梦也是如此

[ 本帖最后由 anlinew 于 2011-4-7 11:23 编辑 ]

anlinew

oracle很多时候就是通过这些典型的业务场景做到你无我有来形成差异化竞争的
比如complex_view_merging
具体见：
http://space.itpub.net/27378/viewspace-683842
显然我们可以通过sql改写来达到优化的目的，但是oracle他就通过CBO能提供自动改写优化，如此一来对于程序员来说他看到的就是：你看oracle跑的很快，你就跑不动吧。。。

anlinew

再比如or扩展，具体见：http://space.itpub.net/27378/viewspace-663338
如此点点滴滴，对于具有较高优化水平的研发人员来说这些都不是问题，但是到了实际应用环境中程序员水平参差不齐，而实际上整个系统中往往就是这些20%的问题影响了整个系统的性能。
虽然oracle的or扩展也带来了一些更加严重的性能问题，远不如程序员自己改写来的稳定高效，但是在敌无我有的层面上，其他DB已经处于劣势了

anlinew

mssql锁的相关的一篇：
http://space.itpub.net/27378/viewspace-665135

ucgary

原帖由 wolfop 于 2011-4-6 15:44 发表

MVCC不是数据库必须的，MVCC带来某些方便性的同时也带来很多问题。很多数据库不支持MVCC，也没打算支持。
Oracle自己的Timesten也没有实现MVCC，有什么问题？到底MVCC是什么，你弄清楚了吗？
那么多不支持MVCC的数据库都有在关键系统使用，你有疑问吗？

淡定, 数据库的技术那么多, 技术要靠工业来驱动的,没有了mvcc,就少了很多问题吗?  看市场说话.

wolfop

原帖由 anlinew 于 2011-4-7 11:21 发表

这就是表现出来的最大的问题
oracle更加迎合开发人员尤其是广大低级的程序员以及DBA，让他们可以减少面对锁等待等问题，当然实际上他们会面对更多的因此造成的并发数据错问题，只是这些问题更加隐性

db2/mssql实际上更要命的是其加锁机制的问题
比如mssql 下 表t有 id字段记录唯一
select * from t where id=1 会被update   t set  where id=2阻塞
而id上有唯一键索引字段时就不会被阻塞
这就是说mssql在执行计划的table scan阶段就要对表进行加锁，而实际上从事实上来看，这是不需要的，如果能将加锁的阶段推后到filter之后的结果集，那么sql1就不会被sql2阻塞了
目前的情况就是db2以及mssql锁的范围与sql真正要锁定的结果无关反而与sql执行计划有非常大的关系。因此锁等待的程度与系统中表及索引对象的设计/sql及其执行计划的优化程度有很大的关系，因此也就与系统开发设计以及维护人员的能力有了很大的关系
达梦也是如此

麻烦你更新一下你的知识，数据库都在进步。sql server 有snapshot模式，DB2 9.7有当前已落实在CS隔离级别的缺省行为，IDS有use_lastcommit选项。
而且你所谓的不阻塞的结果，并不是MVCC的充要条件。MVCC是写不抑制读的充分条件，而且是一个开销过大的条件。MVCC的存在有可能导致snapshot too old的错误，这个你是否研究过？MVCC导致维护机制非常复杂，这点毋庸置疑吧。要不干嘛Oracle自己的Timesten不支持MVCC？
采用2VCC的DB2/INFORMIX/TIMESTEN都能做到写不抑制读。说到底，我怀疑你没弄清楚到底什么是MVCC，也没弄清楚他和write do not block read之间的关系。

[ 本帖最后由 wolfop 于 2011-4-7 13:58 编辑 ]

anlinew

原帖由 wolfop 于 2011-4-7 13:52 发表

麻烦你更新一下你的知识，数据库都在进步。sql server 有snapshot模式，DB2 9.7有当前已落实在CS隔离级别的缺省行为，IDS有use_lastcommit选项。
而且你所谓的不阻塞的结果，并不是MVCC的充要条件。MVCC是写不抑制读的充分条件，而且是一个开销过大的条件。MVCC的存在有可能导致snapshot too old的错误，这个你是否研究过？MVCC导致维护机制非常复杂，这点毋庸置疑吧。要不干嘛Oracle自己的Timesten不支持MVCC？
采用2VCC的DB2/INFORMIX/TIMESTEN都能做到写不抑制读。说到底，我怀疑你没弄清楚到底什么是MVCC，也没弄清楚他和write do not block read之间的关系。

呵呵，我知道你说的这些，可惜你没明白我说的。。。。