看我做的数据库包装器

gszoracle · 发表于 2013-4-21 18:34

再拜读几年前的贴子，被两位的精神折服。
改变一个人的观念何其难。
12306也是楼主团队开发的，或类似的思想主导的，难怪性能老被吐槽。

yulihua49 · 发表于 2013-4-23 11:12

本帖最后由 yulihua49 于 2013-4-23 11:55 编辑

gszoracle 发表于 2013-4-21 18:34
再拜读几年前的贴子，被两位的精神折服。
改变一个人的观念何其难。
12306也是楼主团队开发的，或类似的思 ...

错啦，12306要是听我的就不会有这些问题，他们多半是架构问题而不是数据库问题。
君不见，我的性能已经登峰造极了吗，超过了PL/SQL，超过了sqlldr，甚至超过了direct path。
这两个帖子，说的是OCI，其实都是DAU，这个包装器的战果：
49楼：
http://www.itpub.net/thread-1738533-5-1.html
40楼是RAC的，42楼是单机的：
http://www.itpub.net/thread-1737612-5-1.html
何来此言？

12306确实不是我的思路主导，还真是基于存储过程的。
一个人的思想基于他的环境，进入这个环境，就是这个思想，思想的转变基于环境的转变，而不管别人说什么，别人的意见可以改进你的方法，不可能转变思想。
我们的技术，其价值在于有相同环境的需求。

这个，61楼：http://www.itpub.net/thread-1314001-7-1.html

这就是环境，环境产生思想，否则，干这个活也必须用存储过程？也是最方便最高效，最无缝的存储过程？

换句话说，玩存储过程的高手有的是，轮不着我。就是因为问题解决不了了，我这个才有用。

gszoracle · 发表于 2013-4-23 19:00

本帖最后由 gszoracle 于 2013-4-23 19:00 编辑

yulihua49 发表于 2013-4-23 11:12
错啦，12306要是听我的就不会有这些问题，他们多半是架构问题而不是数据库问题。
君不见，我的性能已经 ...

听君一席话，觉得您对Oracle的了解并不全面，对于Oracle的导入速度能超过Sqlldr+direct+并行？数据库如何接受？如能实现，恰恰说明Oracle服务端应用的强大效率和吞吐率。

yulihua49 · 发表于 2013-4-23 20:27

本帖最后由 yulihua49 于 2013-4-23 21:05 编辑

gszoracle 发表于 2013-4-23 19:00
听君一席话，觉得您对Oracle的了解并不全面，对于Oracle的导入速度能超过Sqlldr+direct+并行？数据库如何 ...

sqlldr ＋ direct，没有并行。

这就是测试结果，最近还想找机会再测测。发的那个结果还不是最好的，它的瓶颈在于读文件，居然追不上插入数据库，正在改进中。
我也很惊叹ORACLE的处理能力，我只不过发挥的比较充分而已（还达不到最充分）。

那个测试采用的csv格式，我发现解释这个格式很消耗，我用了12个线程解析它，（之后有个单线程的结果收集器，估计瓶颈在此，正在改进之），还是追不上批量插入。
我估计sqlldr不会用那么多线程去解析csv格式，所以它追不上我。
结果收集器把每1000个记录打一包，分发（使用完全异步的通信架构）给后台3台服务器，共96个线程进行计算，结果通过队列交由共12个连接，通过2个RAC节点进行插入。
sqlldr怎么可能动用这么多资源呢？它追不上我是正常的。单纯的存储过程又如何能管理这么多资源？
对它的机制没有一定的了解，又怎能超越它？

不开玩笑，现在这个系统是基础生产系统，7*24小时运行的。

gszoracle · 发表于 2013-4-23 20:58

yulihua49 发表于 2013-4-23 20:27
sqlldr ＋ direct，没有并行。

这就是测试结果，最近还想找机会再测测。发的那个结果还不是最好的，它 ...

其实您所作的努力都是在客户端，服务端还没饱和，客户端、网络都可能已成瓶颈，若把负载有选择地往服务端迁，岂不更好。

gszoracle · 发表于 2013-4-23 21:00

yulihua49 发表于 2013-4-23 20:27
sqlldr ＋ direct，没有并行。

这就是测试结果，最近还想找机会再测测。发的那个结果还不是最好的，它 ...

在我们大规模数据导入时，开几十个sqlldr 也是有的，当然针对不同的数据或格式

yulihua49 · 发表于 2013-4-23 21:27

本帖最后由 yulihua49 于 2013-4-23 21:42 编辑

gszoracle 发表于 2013-4-23 20:58
其实您所作的努力都是在客户端，服务端还没饱和，客户端、网络都可能已成瓶颈，若把负载有选择地往服务端 ...

现在查出就是单线程的结果收集器是瓶颈。网络传输时经过压缩，网络没饱和。
但是OCI客户端往服务器送时没有压缩，流量大，但没饱和。

其实处理性能已经能够满足要求，我就是想看看ORACLE到底有多大能耐。

gszoracle · 发表于 2013-4-23 21:29

yulihua49 发表于 2013-4-23 21:27
现在查出就是单线程的结果收集器是瓶颈。网络传输时经过压缩，网络没饱和。

佩服Yu老师的执着劲。

yulihua49 · 发表于 2013-4-23 21:29

本帖最后由 yulihua49 于 2013-4-23 21:33 编辑

gszoracle 发表于 2013-4-23 21:00
在我们大规模数据导入时，开几十个sqlldr 也是有的，当然针对不同的数据或格式

我还要计算呢，不单单是入库。
我们有50多个表要入库，就这一个表需要计算，其它都是sqlldr直接入库，比我这个慢多了。

gszoracle · 发表于 2013-4-23 21:32

数据导入毕竟要通过客户端，这工作用存储过程不一定合适，存储过程合适实现和数据库相关的业务逻辑

[PRO*C] 看我做的数据库包装器