看我做的数据库包装器

newkid

再给楼主支个招，我老早以前讲过的：
http://www.itpub.net/viewthread.php?tid=1102036
看5楼的例子。

等你全面提速了再来和我打擂。

yulihua49

原帖由 newkid 于 2009-1-1 01:41 发表
"83%已经是很不错的成就了（我想知道存储过程能达到多少？）......"
唉，怎么还说存储过程呢？我干吗用存储过程加载数据?我用SQL LOADER和外部表。外部表根本不用加载！

祝你在新年谱写新的篇章！

为了编程的便利性而进行包装，必然要付出代价。
加载是个测试平台，我想知道PL/SQL的插入和其他数据操作的速度。

一般的事务处理，是与SQL*loader有诸多不同。

一般的事务处理                                   SQL*loader
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
使用通用方法                               可能使用专用方法，内部的。
多数是单条处理                             可能块处理，例如数组bind，块读写等。
有用户自己的处理逻辑                        处理逻辑简单


因此，能达到83％已经是很不简单的了，而且不见得都是包装开销，可能PL/SQL本身也就如此了。

这就是为什么希望你百忙之中进行一下试验。即使你能够达到SQL*Loader的性能，对我来说，也不过提高了20％，
有必要为此牺牲编程便利性吗？
要在包装器中支持bind是很复杂的，就是我原先不愿意bind的原因，现在，既然看到了具有如此高的性能改进，我就是费尽千辛万苦也要实现它。
安全、效率仍然是我们宗旨。一句话解决一个问题仍然是我们的特色。
通过DAU，程序员只需要掌握几个函数，而且这些函数的自变量都很少，具有非常简单的逻辑状态，极少的概念。
一个初级的程序员，就容易写出相当高级的功能。极大的提高了劳动生产率，节约了人员培训成本。

其实，作为三层的客户－服务器模型的应用服务器，广义的讲，都是加载－卸载程序。比方说前边的席位申请，可以看作卸载一组你申请的席位，
记帐服务就是加载一个售票存根等等。
因此，我用这个加载程序的目的，是测试数据访问性能。通过这个测试，我大概知道了，申请一个席位，我原来的软件大约是5ms，将来改进了，可达到1ms。
千万别以为我向你们推销load，只是想让你们知道，DAU编程如何简单，不点列名怎样进行数据操作，怎样实现程序与数据独立。
当然，最后那个程序代码还比较多，那是因为bind还没有集成到包装器里，正好可以让大家看看包装器是如何处理数据的。

[ 本帖最后由 yulihua49 于 2009-1-2 12:08 编辑 ]

newkid

"这就是为什么希望你百忙之中进行一下试验。"
我可没办法自己写一个程序和SQL LOADER比较。假如非得用PLSQL读取数据，那么数据文件就必须存在于服务器端，那我直接就用外部表了，我从来不干吃力不讨好的事情。

“只是想让你们知道，DAU编程如何简单，不点列名怎样进行数据操作，怎样实现程序与数据独立。”
前面说过了，这些你认为的优点我看都是缺点。做数据库应用的编程，就是得知道数据结构，就是不能脱离数据库，否则迟早都会搞砸！

等你全部完工了，请再贴一个你的得意之作，我拭目以待。

CS-IM

花了三小时才勉勉强强看完这贴。

yulihua49

这两天进行一些测试，回答对包装器性能的疑问,还是前边的统计文件，7552条记录。
测试结果：
按唯一性条件查询一条记录的时间，包括prepare、bind、fetch一条，close cursor。
0.77ms
插入一条记录：
0.152ms
修改一条记录
0.545ms
按唯一性条件查询一条记录的时间,保持游标，每次都是bind-reopen-fetch：
查找不到：0.153ms
找到：0.271ms

stillwalking

仅对看到的一些片段说说看法，大可无视。
sqlldr的direct模式应该是oracle加载大量数据的最快方式。因为跳过了sql层，直接写入。另外那个sqlldr的readsize，bindsize也不是越大就越快，其实想想有操作系统I/O在那限制着，哪可能想读多少就读多少。
绑定变量，如果把业务量放大，sql每天都要运行几十万次，甚至上百万次，绑定变量的效果就很明显了。
PL/SQL存储过程学习开发比较快，但是如果系统比较复杂，多个数据库要同时访问，就会比较麻烦了。而且如果每天的业务量都在百万级别以上（仅算涉及到更新的，查询的不算），存储过程就撑不住了，不如类似PROC这样的程序快。

[ 本帖最后由 stillwalking 于 2009-1-12 00:28 编辑 ]

newkid

"sqlldr的direct模式应该是oracle加载大量数据的最快方式。因为跳过了sql层，直接写入。另外那个sqlldr的readsize，bindsize也不是越大就越快，其实想想有操作系统I/O在那限制着，哪可能想读多少就读多少。"
这只是为了减少提交次数，并不指望超越OS上限。
外部表是最佳的加载方式，比DIRECT的SQLLDR还好。

"PL/SQL存储过程学习开发比较快，但是如果系统比较复杂，多个数据库要同时访问，就会比较麻烦了。"
都是ORACLE的话，用DB LINK，没什么麻烦的。

"而且如果每天的业务量都在百万级别以上（仅算涉及到更新的，查询的不算），存储过程就撑不住了，不如类似PROC这样的程序快"
百万算什么？
你得看负载是落在PLSQL还是SQL. 一般都在SQL, 因此存储过程是最佳选择。你不管用什么东西代替存储过程，SQL都是绕不过的。

stillwalking

原帖由 newkid 于 2009-1-12 03:01 发表
"sqlldr的direct模式应该是oracle加载大量数据的最快方式。因为跳过了sql层，直接写入。另外那个sqlldr的readsize，bindsize也不是越大就越快，其实想想有操作系统I/O在那限制着，哪可能想读多少就读多少。"
这只是为了减少提交次数，并不指望超越OS上限。
外部表是最佳的加载方式，比DIRECT的SQLLDR还好。

"PL/SQL存储过程学习开发比较快，但是如果系统比较复杂，多个数据库要同时访问，就会比较麻烦了。"
都是ORACLE的话，用DB LINK，没什么麻烦的。

"而且如果每天的业务量都在百万级别以上（仅算涉及到更新的，查询的不算），存储过程就撑不住了，不如类似PROC这样的程序快"
百万算什么？
你得看负载是落在PLSQL还是SQL. 一般都在SQL, 因此存储过程是最佳选择。你不管用什么东西代替存储过程，SQL都是绕不过的。

你说的外部表是最佳的加载方式，不知道你外部表加载数据用的什么driver，不也是sqlldr吗。
外部表在使用上确实更加灵活，对数据的处理也比sqlldr要好，但是速度上最多和sqlldr一样快。

dblink这个东东不好说，是挺方便，但是，如果我有几千万数据要快速处理完，dblink肯定不如proc同时建立多个长连接快。

先确定一点，SQL肯定都是绕不过去。
但是存储过程至少在多线程或者多进程，内存申请上肯定比不过proc或者oci灵活，效率肯定就比不上。存储过程是最佳选择也只是在某些情况下（估计你也是这个意思）。
如果你业务繁忙的时候需要应急修改一下程序，这个时候我可以杀掉程序修改编译，存储过程可能就比较麻烦了，太多人在调用存储过程，编译的时候肯定会卡死（当然这种情况压根就不应该发生）。

[ 本帖最后由 stillwalking 于 2009-1-12 12:38 编辑 ]

gzluma

很想向您请教具体的做法，希望不用ISCSI或NAC等

newkid

"你说的外部表是最佳的加载方式，不知道你外部表加载数据用的什么driver，不也是sqlldr吗。
外部表在使用上确实更加灵活，对数据的处理也比sqlldr要好，但是速度上最多和sqlldr一样快。"

虽然我不知道其内部实现，但可以猜测外部表是借鉴了SQLLDR代码。但是SQLLDR有“写”的动作，而外部表纯粹是“读”，这两者不可比。
单纯就“读”的部分而言，外部表可以并行读，可以JOIN其他表，可以用复杂的过滤，这是SQLLDR比不上的。

再看看“写”的部分。外部表用INSERT SELECT, CTAS 可以完成类似SQLLDR的写操作。这里是TOM的书中的数据：

------------------------------------------------------------------------------
Method                                     CPU     Elapsed    Rows
SQLLDR direct=true                         29      42         1,833,792
External table INSERT /*+ APPEND */        33      38         1,833,792
External table CREATE TABLE AS SELECT      32      37         1,833,792
External table INSERT (conventional path)  42      130        1,833,792
SQLLDR (conventional path)                 50      410        1,833,792
------------------------------------------------------------------------------
可以看到传统路径加载把SQLLDR远远抛在身后。


"但是，如果我有几千万数据要快速处理完，dblink肯定不如proc同时建立多个长连接快。"
你说的是什么？长连接是指C/S结构下的连接？
如果你是指在数据库之间传输大批数据（如ETL），那么DB LINK肯定不合适，通常做法是
导出->压缩->传输->解压缩->导入
如果是指数据处理，那么我们可以通过DB LINK调用远程存储过程，该存储过程还是处理它的本地数据。
分布式事务肯定是要用DB LINK，让ORACLE处理两段提交最方便，你在客户端建立多个连接只会把问题复杂化。


"先确定一点，SQL肯定都是绕不过去。
但是存储过程至少在多线程或者多进程，内存申请上肯定比不过proc或者oci灵活，效率肯定就比不上。"
举个例子？
我到目前为止还没有过申请内存的需求。PLSQL的自动分配内存、自动垃圾回收非常方便，ORACLE也提供了几个参数让你在一定程度上手动分配。


"存储过程是最佳选择也只是在某些情况下（估计你也是这个意思）。"
如果是做数据库应用，我还没发现有例外的。如果你有的例子的话举一个出来。


"如果你业务繁忙的时候需要应急修改一下程序，这个时候我可以杀掉程序修改编译，存储过程可能就比较麻烦了，太多人在调用存储过程，编译的时候肯定会卡死（当然这种情况压根就不应该发生）。"
这正是存储过程的优点啊？难道你希望有些人是用旧版本的程序生成数据，而另外一些人则用新版本？
你的程序可以杀掉，数据库连接也可以杀掉的。