看我做的数据库包装器

yulihua49

“DAU在DB2和MYSQL的表现都很好，三者，各自以其最高效率运行。”
一些参数：
插入操作： 语句生成时间      硬解析时间      软解析时间     插入执行时间
ORACLE       60 微秒          3ms                 1ms               120微秒
DB2             60微秒         20ms                 ？？           100微秒
MYSQL         60微秒    不知道是硬还是软     60微秒          120微秒

DAU的做法，第一次，有语句生成和解析，以后只执行。所以，各自都是最高性能。

〇〇

yulihua49 发表于 2013-12-24 12:05
“DAU在DB2和MYSQL的表现都很好，三者，各自以其最高效率运行。”
一些参数：
插入操作： 语句生成时间   ...

anysql.net上的几种工具也能对付几种数据库

yulihua49

〇〇 发表于 2013-12-24 12:59
anysql.net上的几种工具也能对付几种数据库

1.各村有各村的高招。
2.不同的语言环境和平台。
3.不同的适用范围和目标诉求。

他解决不了我的问题，我也解决不了他的问题。

newkid

yulihua49 发表于 2013-12-24 12:05
“DAU在DB2和MYSQL的表现都很好，三者，各自以其最高效率运行。”
一些参数：
插入操作： 语句生成时间   ...

ORACLE这样优秀的十项全能数据库，竟然被你当作存储设备来用，和小弟们一样做些SELECT *, INSERT这样的简单操作，真是暴殄天物。

yulihua49

newkid 发表于 2013-12-25 04:53
ORACLE这样优秀的十项全能数据库，竟然被你当作存储设备来用，和小弟们一样做些SELECT *, INSERT这样的简 ...

639楼看了没有？

实际做了压力测试，数据库引擎都能达到饱和，要么是IO饱和，要么是CPU饱和，就是说，系统性能得到充分利用。
交易吞吐量，我的方案也是最高的。
就是说，同样价格买的DB服务器，我的方案，能完成的交易量是最多的，怎么就暴殄天物了？
我2分半处理的交易量，后续由存储过程处理要半小时。而且我的业务逻辑比他们复杂得多。他们那点存储过程都是非常简单的逻辑。

我们的路线，就是所有处理由应用服务器完成，数据库仅仅持久化。完成增删改查。
所有业务，均抽象为：取出数据       处理数据     存入数据。
复杂的业务，也不过就是取出若干个表的数据，交叉处理这些数据，存储或修改多个表的数据。
因此，插入和提取的效率，就代表系统的总效率，其他的处理过程，都可以通过并行处理技术，所需时间趋向0；

为什么要耗用宝贵的数据库引擎去处理计算型任务？（两台16核数据库服务器，光license就几百万，一百万就可以买好几台32核的服务器）
而且就系统的眼光，数据库引擎根本提供不了什么像样的并行操作。
观察数据库并行，资源管理一塌糊涂，该并行的资源没并行，不该并行的一大堆垃圾，互相绊脚。
完全没有应用服务器对资源的控制精确有效 --- 真正实现随着并行度增加，处理时间趋近0.使IO成为系统瓶颈。数据库，把IO处理好就阿弥陀佛啦。

这个路线，十全大补的数据库和精简数据库，性能上没有大的差异，基本都是IO性能。它为降低系统总成本开辟了巨大空间。
不过MYSQL的并发交易功能比ORACLE和DB2要差的多。

newkid

639楼哪里有什么压力测试？
达到饱和，也有可能是设计不良，SQL没写好。按你的典型做法是会把本来一个SQL能搞定的拆成很多零碎的小SQL, 这就是我所反对的。
你反复拿出来PK的无非就是批量数据加载卸载，我早说了文件操作不是存储过程的强项，存储过程应该用在事务处理。即便如此，我随手几分钟写的代码，也能达到或接近你一大堆代码的水平，如果不是追求极致，我还是会用我自己的方法。
你说的“后续由存储过程处理要半小时“又是那个什么“费用清算”吧？我早说了那是自己给自己制造障碍，不要怪罪存储过程。
"取出数据       处理数据     存入数据": 很多情况下，这三步是一个SQL可以搞定的。里面的所谓“处理”过程，很多是可以在数据库引擎完成，而且并不增添明显负担，你也说了瓶颈在于IO。
数据库的并行是不可扩缩的, 并行一般用于管理，比如数据迁移，在应付并发事务绝对不能开启并行选项。
不管你在数据库外面怎么并行，最后不还是得执行SQL？我的意思就是用更好的能够发挥数据库威力的SQL, 取代你那些零碎的小SQL。

yulihua49

newkid 发表于 2013-12-25 23:51
639楼哪里有什么压力测试？
达到饱和，也有可能是设计不良，SQL没写好。按你的典型做法是会把本来一个SQL能 ...

数据库饱和是我驱动的，使之达到了最高能力。数据库引擎，就是匹马，让我抽到跑吐血，不能再快了。
只要我的压力测试一开，数据库引擎的风扇就疯狂嗥叫，我是暴殄天物吗？
跟我PK的任何软件都达不到这个水平，吞吐量也都小的多。
有人认为数据库这样工作是病态，但我不。我认为只有这样才能看出它是否一匹好马。
它能跑这么快，是因为轻装上阵，工作尽可能让别人干了，它只干必须的工作。
都是正常的工作，没有无谓的循环和重复，所以不管怎么忙都是正常的，不是病态。
在此状态下，给它增加任何其它工作，势必减少交易量。

newkid

你的思维方式果然独特。我偶尔也会写个SQL导致风扇狂响，这时候我可没有自豪地认为自己“使之达到了最高能力”，而是看看有什么方法用更少的资源做到同样的事情。

yulihua49

newkid 发表于 2013-12-26 22:17
你的思维方式果然独特。我偶尔也会写个SQL导致风扇狂响，这时候我可没有自豪地认为自己“使之达到了最高能力 ...

而是看看有什么方法用更少的资源做到同样的事情。--这是王道。
我通篇说的都是这个。

一个存储过程，肯定容易驱动数据库引擎风扇狂响。但是把它的功能分到别处，这时数据库引擎的负载轻了。在相同的业务密度下，风扇就不会响了。
现在，风扇又响了，说明业务量有提高了。就是同一个数据库引擎，能处理更高的业务量。形容而已。
或者说，我也能让数据库引擎满载。

newkid

你 80% 都是在仅仅需要两三个列到情况下生成SELECT *, 这是"用更少的资源做到同样的事情”？
你 80% 都是把一条SQL能完成的事情拆分成几个小SQL, 这是"用更少的资源做到同样的事情”？

"一个存储过程，肯定容易驱动数据库引擎风扇狂响"
你以前还说过“存储过程会导致堵车”呢？结果怎么样？我给你写的售票过程堵车了吗？
真替你们单位写存储过程的人捉急。

你不妨就把这个"容易驱动数据库引擎风扇狂响"的过程贴出来，让我这老军医把把脉。