冒頭の質問
ODBCは時々速度の悪いラップを取得します…しかし、それはすべきですか?オンラインで投稿された内容から、ODBCは本質的に遅いと思うでしょう:
SQLServerの場合はMicrosoftは同意しません。 MicrosoftSQLServerでのODBCの使用 、AmrishKumarとAlanBrewerは、ODBCはネイティブと同じくらい優れていると述べています:
ODBCに関する根強い噂の1つは、ネイティブのDBMSAPIよりも本質的に遅いということです。この推論は、ODBCドライバーをネイティブDBMS API上の追加レイヤーとして実装し、アプリケーションからのODBCステートメントをネイティブDBMSAPI関数とSQL構文に変換する必要があるという前提に基づいています。この変換作業により、アプリケーションがネイティブAPIを直接呼び出す場合と比較して、余分な処理が追加されます。この仮定は、ネイティブDBMS APIを介して実装された一部のODBCドライバーに当てはまりますが、Microsoft SQLServerODBCドライバーはこの方法で実装されていません。 …Microsoftのテストでは、ODBCベースとDBライブラリベースのSQLServerアプリケーションのパフォーマンスはほぼ同等であることが示されています。
Oracleによると、彼らのODBCドライバーは、平均して、ネイティブのOracleアクセスよりも約3%遅いだけです。ただし、それらのODBCドライバーはあなたのものではない可能性があり、マイレージは異なります。
ユーザーは、次のような非常に大規模なデータベース(VLDB)の操作中に、ODBCまたはオフラインのフラットファイルアプローチを使用してデータ処理を行う方がよいかどうかをよく尋ねます。これはIRIで最もよく知られています。
- ETL(抽出、変換、読み込み)
- オフライン再編成
- 移行とレプリケーション
- データマスキング
- テストデータの生成/作成
私たちの一般的な答えは、データ量がデータ移動パラダイムを決定する必要があるということです。単純なデータベース母集団(読み込み)ベンチマークを使用して、そのアドバイスをテストすることに着手しました。
2つのパラダイムの比較
ここでは、ODBCとバルクのファイルベースのデータ移動のみを確認しており、JDBCやHadoopなどの他のデータ配布手段は確認していません。また、NoSQLなどのデータ取得や、TeradataFastLoadなどの配信を改善するために宣伝されている他の手段も考慮していません。
ODBC(オープンデータベースコネクティビティ)
ODBCは、クライアントプログラムがODBCと互換性のあるさまざまなデータベースやデータソースに便利にアクセスするための方法を提供します。
ODBCは、アプリケーションとDBMS間の変換レイヤーとしてODBCドライバーを使用することにより、DBMSの独立性を実現します。アプリケーションは、リンクされているODBCドライバーマネージャーを介してODBC関数を使用し、ドライバーはクエリまたは更新コマンドをDBMSに渡します。
CoSort SortCLプログラムなどのIRIソフトウェアでODBCを介してテーブルにデータを入力するには、出力プロセスタイプをODBCとして指定します。ファイルやプロシージャではなく、テーブルの列を対象とするサンプルスクリプトには、次のレイアウトが含まれている可能性があります。
/OUTFILE="QA.MILLION_TEST_NEW_ROW;DSN=OracleTwisterQA" /PROCESS=ODBC /ALIAS=QA_MILLION_TEST_NEW_ROW /FIELD=(ACCTNUM, POSITION=1, SEPARATOR="|", TYPE=ASCII) /FIELD=(DEPTNO, POSITION=2, SEPARATOR="|", TYPE=ASCII) /FIELD=(QUANTITY, POSITION=3, SEPARATOR="|", TYPE=NUMERIC) /FIELD=(TRANSTYPE, POSITION=4, SEPARATOR="|", TYPE=ASCII) /FIELD=(TRANSDATE, POSITION=5, SEPARATOR="|", TYPE=ISODATE) /FIELD=(NAME, POSITION=6, SEPARATOR="|", TYPE=ASCII) /FIELD=(STREETADDRESS, POSITION=7, SEPARATOR="|", TYPE=ASCII) /FIELD=(STATE, POSITION=8, SEPARATOR="|", TYPE=ASCII) /FIELD=(CITY, POSITION=9, SEPARATOR="|", TYPE=ASCII)
次のジョブ内のSortCLでのデフォルトのODBCポピュレーション動作:IRI CoSort(バルク変換とプリロードソート)、IRI NextForm(DB移行とレプリケーション)、IRI FieldShield(DBデータマスキングと暗号化)、IRI RowGen(DBテストデータ生成) 、またはIRI Voracity(上記のすべて)は/ APPENDであり、既存のテーブルに行を追加します。追加のオプションは、切り捨ておよび完全挿入の場合は/ CREATE、選択挿入の場合は/UPDATEです。
SQL * Loader
SQL * Loaderは、外部(フラット)ファイルから同じシステムまたはネットワークを介して既存のテーブルにデータをロードするOracleデータベースユーティリティです。 SQL * Loaderは、さまざまなターゲットテーブル形式をサポートしており、選択的なテーブルの読み込みと複数のテーブルの読み込みの両方を処理できます。
データは任意のテキストファイルからロードしてデータベースに挿入できます。 sqlldr(一部のプラットフォームではsqlload)コマンドを使用して、シェルからテーブルを一括ロードできます。引数なしで実行して、使用可能なパラメータのリストを取得します。
フラットファイルデータがターゲットテーブルの最長のインデックスキーで事前に並べ替えられるIRIETLおよびreorgシナリオでは、loadコマンドの構文は次のとおりです。
C:\IRI\CoSort10>sqlldr scott/tiger control=ODBC_ONEMILLION_TEST.ctl DIRECT=TRUE
.ctlローダー制御ファイルに含まれる場所:
INFILE 'C:\IRI\CoSort10\workbench\workspace\CM\twofiftym ilfinalcm.out' APPEND INTO TABLE ODBC_ONEMILLION_TEST REENABLE FIELDS TERMINATED BY "|" ( ACCTNUM NULLIF(ACCTNUM="{NULL}") , DEPTNO NULLIF(DEPTNO="{NULL}") , QUANTITY NULLIF(QUANTITY="{NULL}") , TRANSTYPE NULLIF(TRANSTYPE="{NULL}") , TRANSDATE NULLIF(TRANSDATE="{NULL}") , NAME NULLIF(NAME="{NULL}") , STREETADDRESS NULLIF(STREETADDRESS="{NULL}") , STATE NULLIF(STATE="{NULL}") , CITY NULLIF(CITY="{NULL}")
次のグラフは、Windowsサーバー上のOracle XE 11gR2に、ODBC挿入とSQL*Loaderの両方を使用して事前に並べ替えられた5つの異なるファイルが入力されるまでにかかった平均時間を比較しています。
レコード数 | SQL*Loaderを介したDBポピュレーション | ODBCを介したDBポピュレーション |
250万 | 10.25秒 | 58.25秒 |
200万 | 6.25秒 | 24.25秒 |
100万 | 5.25秒 | 11.5秒 |
50万 | 4秒 | 5.5秒 |
1/4百万 | 2.75秒 | 4.25秒 |
IRIユーザー向けの結論
IRI FieldShieldユーザーは、100万行未満のテーブルの動的データマスキングと静的データマスキングに十分便利で高速であるため、通常はODBCで問題ないことがわかりました。 IRICoSortまたはIRINextFormでの、巨大ではないデータマッピング、フェデレーション、またはレポート操作についても同じことが言えます。
ただし、IRI Voracityでの一括ETLおよび再編成操作の場合、引き続き最適に機能するのは、サポートされている次のコンポーネントです。
- OCIなどのネイティブドライバーを使用したアンロード用のIRIFACT(高速抽出)
- ビッグデータ変換とプリロードソート用のIRICoSort[または、ソートされた、参照的に正しいテストデータ生成用のIRIRowGen]
- バルクのダイレクトパスロード用のDBロードユーティリティ
そのため、NoSQLやHadoopのような複雑でコストのかかるパラダイムは恥ずかしがり屋です。信頼できるフラットファイル方式は、今でも道のりです。