y****w
发帖数: 3747 | 1 从jdbc的result set往表中插入记录，假设类型等meta data完全匹配，怎么效率最高？
1. 循环里挨条差。小应用无所谓，数据量大了就傻眼。
2. 构造insert语句同时插入多条记录，比如100条，这个100可以参数化，可以自动评
估，注意避免sql语句的长度limit。
3. 生成临时(内存)文件，然后批处理load/bcp等。
大家有啥想法？ |
B*****g
发帖数: 34098 | 2 首先，你非药用JDBC吗？hibernate行不行？
数据有先后顺序吗？如果没有，是否考虑多现成？
用sql insert的话至少要batch吧.
高？
【在 y****w 的大作中提到】
: 从jdbc的result set往表中插入记录，假设类型等meta data完全匹配，怎么效率最高？
: 1. 循环里挨条差。小应用无所谓，数据量大了就傻眼。
: 2. 构造insert语句同时插入多条记录，比如100条，这个100可以参数化，可以自动评
: 估，注意避免sql语句的长度limit。
: 3. 生成临时(内存)文件，然后批处理load/bcp等。
: 大家有啥想法？
|
y****w
发帖数: 3747 | 3 不一定jdbc，用c api也可以。
数据不分先后。多线程没问题，如果做通用方案就有个锁的问题; 套个provider/
consumer的pattern实现方面还好.
数据量，假设我有800M records吧。
【在 B*****g 的大作中提到】
: 首先，你非药用JDBC吗？hibernate行不行？
: 数据有先后顺序吗？如果没有，是否考虑多现成？
: 用sql insert的话至少要batch吧.
:
: 高？
|
y****w
发帖数: 3747 | 4 btw, 对hibernate的性能不信任，如果它能搞定我100条一插估计也能比它好些。关键
还是数据量。
【在 B*****g 的大作中提到】
: 首先，你非药用JDBC吗？hibernate行不行？
: 数据有先后顺序吗？如果没有，是否考虑多现成？
: 用sql insert的话至少要batch吧.
:
: 高？
|
w*r
发帖数: 2421 | 5 800M, yo bet you need to use loader tool
parallel insert may get the record in, but later table maintenance is issue:
i.e. how record scattered to different disk blocks, data block splitting ,
indexing data file fragment, reorg table etcetc.
【在 y****w 的大作中提到】
: 不一定jdbc，用c api也可以。
: 数据不分先后。多线程没问题，如果做通用方案就有个锁的问题; 套个provider/
: consumer的pattern实现方面还好.
: 数据量，假设我有800M records吧。
|
y****w
发帖数: 3747 | 6 loader工具对insert的优势也不在fragment这方面。这里处理大数据就suppose没那么其他东西来捣乱，乱是乱不了的，就是乱了也不怕，这很容易控制和纠正，
loader的问题是怎么和内存(cursor)挂接起来，没有方便的api。似乎只能通过文件（哪怕是内存文件）中转下。
800M是一个极端，就是讲效率必须被重视。
btw, staging表暂时禁用log也是有价值的。
issue:
,
【在 w*r 的大作中提到】
: 800M, yo bet you need to use loader tool
: parallel insert may get the record in, but later table maintenance is issue:
: i.e. how record scattered to different disk blocks, data block splitting ,
: indexing data file fragment, reorg table etcetc.
|
w*r
发帖数: 2421 | 7 其他的我不知道，TD上面就有这个问题，你做很多 parallel insert, 如果target
table data block 64K, 很容易出现很多small data block, fragment. 做完了，我
还得在做一个insert/select..
如果loader, 一定木的这个问题
redo/undo log在loader里面直接disable，如果SQL, 每个trsanction 都在生成redo/
undo log (journal in teradata).
内存挂钩有很多tool , 直接用informatica 处理，nongstaged loader (named pipe
under unix)不就是你说的挂钩了？
么其他东西来捣乱，乱是乱不了的，就是乱了也不怕，这很容易控制和纠正，
（哪怕是内存文件）中转下。
【在 y****w 的大作中提到】
: loader工具对insert的优势也不在fragment这方面。这里处理大数据就suppose没那么其他东西来捣乱，乱是乱不了的，就是乱了也不怕，这很容易控制和纠正，
: loader的问题是怎么和内存(cursor)挂接起来，没有方便的api。似乎只能通过文件（哪怕是内存文件）中转下。
: 800M是一个极端，就是讲效率必须被重视。
: btw, staging表暂时禁用log也是有价值的。
:
: issue:
: ,
|
y****w
发帖数: 3747 | 8 不太懂TD. loader这方面一定好，毫无疑问。
我现在倾向于还是写文件出来了再调用load api了。也许可以做成几种可选的模式，只在超大表上这么搞。 不是太夸张的碎片大多数还是可以忍受的。
不能直接用load api的原因主要是source和target不同构。
【在 w*r 的大作中提到】
: 其他的我不知道，TD上面就有这个问题，你做很多 parallel insert, 如果target
: table data block 64K, 很容易出现很多small data block, fragment. 做完了，我
: 还得在做一个insert/select..
: 如果loader, 一定木的这个问题
: redo/undo log在loader里面直接disable，如果SQL, 每个trsanction 都在生成redo/
: undo log (journal in teradata).
: 内存挂钩有很多tool , 直接用informatica 处理，nongstaged loader (named pipe
: under unix)不就是你说的挂钩了？
:
: 么其他东西来捣乱，乱是乱不了的，就是乱了也不怕，这很容易控制和纠正，
|
w*r
发帖数: 2421 | 9 市场上成熟的软件（data stage/informatica/abintio)解决这种mapping的问题
都是point/click的mapping editor
call api这些软件也都做到了，
只在超大表上这么搞。 不是太夸张的碎片大多数还是可以忍受的。
【在 y****w 的大作中提到】
: 不太懂TD. loader这方面一定好，毫无疑问。
: 我现在倾向于还是写文件出来了再调用load api了。也许可以做成几种可选的模式，只在超大表上这么搞。 不是太夸张的碎片大多数还是可以忍受的。
: 不能直接用load api的原因主要是source和target不同构。
|
y****w
发帖数: 3747 | 10 1.处于抠门模式的...
2.ETL工具作这块更重视通用性，方便开发，速度说不上多好吧。
现在我想的就是弄个小的，对特定应用优化的冬冬。这些大型工具是不合适的。
【在 w*r 的大作中提到】
: 市场上成熟的软件（data stage/informatica/abintio)解决这种mapping的问题
: 都是point/click的mapping editor
: call api这些软件也都做到了，
:
: 只在超大表上这么搞。 不是太夸张的碎片大多数还是可以忍受的。
|
|
|
g***l
发帖数: 18555 | 11 巨量插入删除还是要ETL的软件，或者BCP,否则光LOG也把数据库搞死了。我觉得自己编
的BATCH软件就是垃圾，就应该全部LOAD进STAGING TABLE，然后用SP去VALIDATE，全通
过的用FAST TABLE LOAD LOAD进去，一边LOAD一边VALIDATE，要猴年马月才能LOAD完啊
。 |
y****w
发帖数: 3747 | 12 那就考虑下etl软件是怎么实现这块的吧，
btw,不用validate，纯数据插入问题。
【在 g***l 的大作中提到】
: 巨量插入删除还是要ETL的软件，或者BCP,否则光LOG也把数据库搞死了。我觉得自己编
: 的BATCH软件就是垃圾，就应该全部LOAD进STAGING TABLE，然后用SP去VALIDATE，全通
: 过的用FAST TABLE LOAD LOAD进去，一边LOAD一边VALIDATE，要猴年马月才能LOAD完啊
: 。
|
g***l
发帖数: 18555 | 13 最快BCP，SSIS有FAST TABLE LOAD，以前有DTS的，基本原则是数据已经VALIDATE了，
不LOG，这样才能快速LOAD进去，DW都是这么LOAD的
【在 y****w 的大作中提到】
: 那就考虑下etl软件是怎么实现这块的吧，
: btw,不用validate，纯数据插入问题。
|
y****w
发帖数: 3747 | 14 ;)好像话题已经引偏太多了。
【在 g***l 的大作中提到】
: 最快BCP，SSIS有FAST TABLE LOAD，以前有DTS的，基本原则是数据已经VALIDATE了，
: 不LOG，这样才能快速LOAD进去，DW都是这么LOAD的
|
g***l
发帖数: 18555 | 15 你说那种小打小闹地INSERT点吧，一行两行的，RECORD多了还是去CALL STORED
PROCEDURE吧，否则慢就一个字。
【在 y****w 的大作中提到】
: ;)好像话题已经引偏太多了。
|
y****w
发帖数: 3747 | 16 我的初始方案就有批处理，或分批load了。还是缺少新idea.
思维先调转90度，把自己放到etl工具厂商的角度去看这个问题。
从我几个地方得到的反馈看，也很难有很创意的idea了。
有些地方只是自己需要打磨把匕首，用不着去花钱买坦克。
【在 g***l 的大作中提到】
: 你说那种小打小闹地INSERT点吧，一行两行的，RECORD多了还是去CALL STORED
: PROCEDURE吧，否则慢就一个字。
|
a***y
发帖数: 2803 | 17 恩,数据量大了就傻眼.想想银行那么多客户.听说过某人帐户里突然出现几万美金的好
事,哎,怎么就轮不到我涅?
高？
【在 y****w 的大作中提到】
: 从jdbc的result set往表中插入记录，假设类型等meta data完全匹配，怎么效率最高？
: 1. 循环里挨条差。小应用无所谓，数据量大了就傻眼。
: 2. 构造insert语句同时插入多条记录，比如100条，这个100可以参数化，可以自动评
: 估，注意避免sql语句的长度limit。
: 3. 生成临时(内存)文件，然后批处理load/bcp等。
: 大家有啥想法？
|
m******y
发帖数: 588 | 18 可以试试把所有要insert/update的record做成xml file, 然后写个stored proc, 用sp
_xml_preparedocument and OPENXML把所有records弄到temp table/table variable去
， 然后做batch update/insert. 当然可以省中间一部，但是records太多可能会引起
blocking. |
g***l
发帖数: 18555 | 19 XML，慢死人的，千万别用XML，FILE直接DTS进TABLE，TABLE之间DTS快的多，DB
PROGRAMMER抢了VB PROGRAMMER的饭碗，VB PROGRAMMER现在基本没饭吃了。
sp
【在 m******y 的大作中提到】
: 可以试试把所有要insert/update的record做成xml file, 然后写个stored proc, 用sp
: _xml_preparedocument and OPENXML把所有records弄到temp table/table variable去
: ， 然后做batch update/insert. 当然可以省中间一部，但是records太多可能会引起
: blocking.
|
m******y
发帖数: 588 | 20 很多时候你没法多DTS的，我们用XML实时处理一些银行的settlement reponse file还
是可以的。
【在 g***l 的大作中提到】
: XML，慢死人的，千万别用XML，FILE直接DTS进TABLE，TABLE之间DTS快的多，DB
: PROGRAMMER抢了VB PROGRAMMER的饭碗，VB PROGRAMMER现在基本没饭吃了。
:
: sp
|
|
|
B*****g
发帖数: 34098 | 21 VB没饭吃了和DB没啥关系吧，GO JAVA!!
【在 g***l 的大作中提到】
: XML，慢死人的，千万别用XML，FILE直接DTS进TABLE，TABLE之间DTS快的多，DB
: PROGRAMMER抢了VB PROGRAMMER的饭碗，VB PROGRAMMER现在基本没饭吃了。
:
: sp
|
g***l
发帖数: 18555 | 22 JAVA编出的东西都跟蜗牛一样，LOL
【在 B*****g 的大作中提到】
: VB没饭吃了和DB没啥关系吧，GO JAVA!!
|
v*****r
发帖数: 1119 | 23 假如后台是 Oracle, client 用 jdbc load data 的话，效率最高的应该是用 jdbc 的
batch operation + bind variable, 基本上能达到 pl/sql 的bulk insert 的
performance。
你说的2 好像是这个意思，但没提到 bind variable，你可以 不用 bind variable 来
batch 100 条 record inserts, the only thing you save comparing with "no
batch" is a little bit less network traffic for sending requests, 不会有什么
performance 提高，只有同时用 bind variable, oracle 才能 bind all 100 input
values，then execute them as one run inside sql engine，. Bulk size 100 有点
低，我一般 500 起。做benchmark 的时候，你应该很容易找到一个最适合你 server
的 bulk size.
对SQLServer 不甚了解，但tsql 的 bulk insert syntax 好像是从file 里load data,
不知道 jdbc for sqlserver 能否 interact with sql engine directly in
sqlserver (like the case of oracle). 如果非要用 data file 的活，oracle 有更
快更方便的方法来 load, jdbc 就没必要了。
高？
【在 y****w 的大作中提到】
: 从jdbc的result set往表中插入记录，假设类型等meta data完全匹配，怎么效率最高？
: 1. 循环里挨条差。小应用无所谓，数据量大了就傻眼。
: 2. 构造insert语句同时插入多条记录，比如100条，这个100可以参数化，可以自动评
: 估，注意避免sql语句的长度limit。
: 3. 生成临时(内存)文件，然后批处理load/bcp等。
: 大家有啥想法？
|
v*****r
发帖数: 1119 | 24 这绝对是误解
【在 g***l 的大作中提到】
: JAVA编出的东西都跟蜗牛一样，LOL
|
B*****g
发帖数: 34098 | 25 java编出来的东西蓝是因为蓝java developer太多了。
【在 v*****r 的大作中提到】
: 这绝对是误解
|
y****w
发帖数: 3747 | 26 good point. 这个我这几天也在考虑，不过没有做实验验证过。毕竟我不是programmer
,这些也就是，思考思考。
argument:
1. executeBatch是成批将sql语句送到dbms执行，节省反复传送大批sql语句的时间，
是否本地执行就可能有比较大区别。
2. dbms这边这些insert还是单行插入的。数据库寻找slot，插入，logging等cost跑不
了，也很零碎。这是自己组装大型sql语句的考虑。与1相比，假如batch size相同，性
能应该更有优势。
3. 将executeBatch与组装大型sql语句结合。这是我目前最倾向的方案，对于中等规模
的数据。应该能够有不错的性能，关键是够简洁，也可配置。
其他可以加进来的是a) 流水。引进一个provider/consumer模式并不难。 b) 很容易扩
展a支持并发。
对大型数据，还是包装loader合适。
btw,我只是想讨论下这块的实现技术。即便说ssis之类，这些工具把数据倒到内村里也要考虑怎么做，所以就假设你自己在实现一个c或者java版本的ssis好了。
input
【在 v*****r 的大作中提到】
: 假如后台是 Oracle, client 用 jdbc load data 的话，效率最高的应该是用 jdbc 的
: batch operation + bind variable, 基本上能达到 pl/sql 的bulk insert 的
: performance。
: 你说的2 好像是这个意思，但没提到 bind variable，你可以 不用 bind variable 来
: batch 100 条 record inserts, the only thing you save comparing with "no
: batch" is a little bit less network traffic for sending requests, 不会有什么
: performance 提高，只有同时用 bind variable, oracle 才能 bind all 100 input
: values，then execute them as one run inside sql engine，. Bulk size 100 有点
: 低，我一般 500 起。做benchmark 的时候，你应该很容易找到一个最适合你 server
: 的 bulk size.
|
y****w
发帖数: 3747 | 27 作为db guy, doubt你这个结论:)
数据库单条插入和分组插入的性能差的不是一点半点。100个prepare包含100行数据的
insert，比10000个数据库插入的额外成本一般情况下要少多了。
来: batch 100 条 record inserts, the only thing you save comparing with "no
【在 v*****r 的大作中提到】
: 这绝对是误解
|
y****w
发帖数: 3747 | 28 现在的java已经很不错了，需要用c/c++来改善性能瓶颈的地方越来越少了。十年前到
现在，我一直算是c/c++的坚定fans，但现在需要做些什么脚本搞不定的东西，还是越
来越多借重Java了。做database，有时候想搞点什么工具类的东西时，c/c++的往往api
要更丰富些。
【在 B*****g 的大作中提到】
: java编出来的东西蓝是因为蓝java developer太多了。
|
g***l
发帖数: 18555 | 29 关键不是这个，是LOG，有LOG就慢，因为要考虑TRANSSACTION失败ROLLBACK，所以不管
你是一个一个的插还是一组一组的插都好不到哪里去。
no
【在 y****w 的大作中提到】
: 作为db guy, doubt你这个结论:)
: 数据库单条插入和分组插入的性能差的不是一点半点。100个prepare包含100行数据的
: insert，比10000个数据库插入的额外成本一般情况下要少多了。
:
: 来: batch 100 条 record inserts, the only thing you save comparing with "no
|
y****w
发帖数: 3747 | 30 人就不兴做几个针对性版本么。再说，不是所有dbms都不能暂时禁用表logging的。
你一直在讲工具。是我没说清楚，我们在讨论的是，假如你在做这个工具，你怎么处理。有多少已知的api可以借用。ssis或者其他什么federation tool是怎么实现的？这些也许有些地方有文档透露些痕迹，有些只能去猜测。
【在 g***l 的大作中提到】
: 关键不是这个，是LOG，有LOG就慢，因为要考虑TRANSSACTION失败ROLLBACK，所以不管
: 你是一个一个的插还是一组一组的插都好不到哪里去。
:
: no
|
|
|
y****w
发帖数: 3747 | 31 insert相对load最慢的地方还不是logging -- 虽然整天有培训师在那么讲"因为没有
logging" -- 而是寻址插入的开销。简单的说，这个数据插入是不是必须经过sql引擎
以及批量大小。
问题是，如果我们需要这种load的机制，如何借用？如何接近？这是真正要思考的问题
。至于用工具，那是系统集成问题，不是我想讨论的东西。
【在 g***l 的大作中提到】
: 关键不是这个，是LOG，有LOG就慢，因为要考虑TRANSSACTION失败ROLLBACK，所以不管
: 你是一个一个的插还是一组一组的插都好不到哪里去。
:
: no
|
g***l
发帖数: 18555 | 32 太高深了，不懂了，撤了。
【在 y****w 的大作中提到】
: insert相对load最慢的地方还不是logging -- 虽然整天有培训师在那么讲"因为没有
: logging" -- 而是寻址插入的开销。简单的说，这个数据插入是不是必须经过sql引擎
: 以及批量大小。
: 问题是，如果我们需要这种load的机制，如何借用？如何接近？这是真正要思考的问题
: 。至于用工具，那是系统集成问题，不是我想讨论的东西。
|
y****w
发帖数: 3747 | 33 是我开始没说清楚，我那两个帖子其实到底真正想搞清楚的是一回事儿，即在公开的编
程接口上，我们能怎样接近厂商的工具，或者厂商给我们提供的接口能提供多高的性能
。 |
