看我做的数据库包装器

gszoracle

newkid 发表于 2013-4-23 22:01
说了多少次了，用外部表+SQL+存储过程入库，比什么都好。TOM都说了sqlldr已经死亡。
就这么个入库的东西让 ...

看来我重新挑起两位的论战

gszoracle

yulihua49 发表于 2013-4-23 22:11
早就试过了，慢得要死。
这要是能行，早就用不着我了，这的高手也多着呢。
我来之前，之后都有人试过 ...

有的偏激，这速度也算是极品飞车了

yulihua49

newkid 发表于 2013-4-23 22:24
看看慢在哪个环节，1000行数据怎么可能慢？

1000w行数据，不是1000行。
测试时是400W行。
在一个盘上读写，读之后csv格式处理，既没有多线程，又没有并行吧？
读与插，单一流程，交替进行,没有并行。
看我们的架构：
从客户端的盘上读文件（与数据库不是一个盘，完全并行的）（异步，发出去不管，立即读下一行）
分12个线程解析CSV格式
1000个记录一组，发到3台服务器（异步，发出去不管，立即收集下一分组），96个线程进行计算。
计算结果交给12个连接，通过2台RAC节点同时插入。

每个环节都是独立并行的。
你就一个SQL语句，能控制这么多资源吗？

你好比是特战高手，论武功，擒拿格斗，我绝对不是你的对手。
但是我要进行的是多兵种协同的海空一体化联合演习，拼的是架构。这个架构的薄弱环节就是数据持久化，苦于没有高性能的持久化工具。
ORACLE，给了我们一个高性能的持久化平台。方便高效的使用这个平台就是开发DAU的初衷。
DAU融入了，支撑了这个架构。而存储过程难以融入这个架构。这就是环境，环境决定思想。

这个系统：
7台服务器，140核，344G内存，两组磁盘阵列。
当性能不能满足要求时，业主说，给你添机器，你要多少？
（现在有个观点，对于性能，软件已经不重要了，可以用硬件堆。没有合适的软件，你给我堆一个试试）

一个SQL语句，给你机器，你又能怎样呢？你连RAC节点全用起来都不易。

gszoracle

yulihua49 发表于 2013-4-24 11:07
1000w行数据，不是1000行。
测试时是400W行。
在一个盘上读写，读之后csv格式处理，既没有多线程，又 ...

yu老师别拼了，用了这么多硬件才堆了点入库的数据源，入库速度最后目标还是让数据进入数据库。用Newkid的方法只用数据库服务器就能搞定，一台额外的硬件资源都不需要，您说谁更优呢？

newkid

数据那么大，先压缩，然后上传到数据库服务器解开，然后用并行选项的SQL处理外部表。

yulihua49

gszoracle 发表于 2013-4-24 19:52
yu老师别拼了，用了这么多硬件才堆了点入库的数据源，入库速度最后目标还是让数据进入数据库。用Newkid的 ...

那要看业主的需求。
如果业主说，用最少的设备。。。。。
要是：最快的速度，不差钱。。。。。。。

其实我也不一定需要那么多设备，少一些也是可以的，最优的配置应该是比这个少。

问题是，如果有这么多资源，你用的上吗？

如果NEWKID的办法灵，我们还费这一年的事干什么？从技术上讲，我们没有排斥任何人或任何技术的想法，追求用最短的时间做最多的事。
实在的说，没有其他办法能满足业主需求。

yulihua49

newkid 发表于 2013-4-24 21:44
数据那么大，先压缩，然后上传到数据库服务器解开，然后用并行选项的SQL处理外部表。

这时间我早就干完了。还没等你传完文件。
就这类项目而言，你还没计算呢。

gszoracle

yulihua49 发表于 2013-4-25 13:33
那要看业主的需求。
如果业主说，用最少的设备。。。。。
要是：最快的速度，不差钱。。。。。。。

响应习总号召，降低单位产出的资源消耗。开发人员普遍存在的心理是性能性上不去就加机器加配置，很少会从降低开消上去做文章，只有解放了硬件，软件才能进入新天地。数据库应用优化的核心指导思想是少干事，最好不干，小任务变大任务，平台能干的事让平台干，应用绝不浪费一条语句、一个指令、一趟传输、一次交互...，
发动巨大的客户端资源往数据库压，某种意义上是把数据库往绝路上逼。资源够用就行，调用的资源多，浪费也大。
从数据库角度看，您一年多努力的意义值得商榷。
本帖仅一家之言，决无冒犯之意。

yulihua49

gszoracle 发表于 2013-4-25 18:32
响应习总号召，降低单位产出的资源消耗。开发人员普遍存在的心理是性能性上不去就加机器加配置，很少会从 ...

你误解了，这个道理我20年前就懂。
不是为压数据库而压数据库，而是应用的要求，一天的数据必须在规定时间内完成，我们只是其中一个工序，后边还有好多的工序。
你以为业主花费好几百万就为了我压数据库玩？
你可能没看到前边我给的连接，那里概述了这个任务，它是清分业务的基础。
业主那里，开发商这里，高人云集，不比在座的水平差。你们的办法都用过，比这高明的办法也用过。
事情绝不是入库那么简单，我只不过略去了其它，单用这个例子来说明，这个架构能够提供比单一的存储过程强大得多的能力，更能够发挥数据库的威力。能够解决传统手段不能解决的问题。
你的观点，似乎数据库就是一切。
在云计算的架构里，数据库只是一部分，不是太大，但是很关键的一部分。不可能让数据库去解决一切问题。

回到原来的问题，给你设备，你能用的上吗？
当然，人家给你设备的前提是经过投入产出评估的（你不要认为业主是傻子或别有用心），也是咨询了你的意见的，你说可以，人家才考虑的。

要是你，你会添置些什么设备呢？或者不添，或者比我的方案便宜？（原有一对数据库服务器和盘阵）。
NEWKID的方案，是大大的不能满足性能要求。那么，在我之前的状态就摆在你面前了。
我就是要了3台8核的服务器，结果到了购机的时候，原来8核的价格可以买到32核的了，就被你扣了个浪费资源的帽子。
如果96核还灌不满数据库，就太对不起这配置了。

如果单纯使用数据库，那么就要另购数据库服务器和盘阵，加上ORACLE的许可证，费用比我要高一个数量级，还未必能满足要求。

newkid

我被你搞得稀里糊涂的。你真的试过我的方法？我看了你582楼的贴，似乎你入库之前就进行了那个所谓的“清分”计算。我可没说要用存储过程去做你那个“清分”计算。
我讲的方法就是入库而已；1000w入库算什么？
至于那个“清分”计算，我也讲了我的看法，应该简化需求，现在的做法根本没有道理。