6

SQL Native Client はOLEDB ドライバーよりも高速であると言われています。そこで、この 2 つの間の負荷テストを実行するためのユーティリティをまとめましたが、さまざまな結果が得られています。クエリが何であれ (単純な select、where 句、結合、order by など)、一方が高速な場合もあれば、他方が高速な場合もあります。もちろん、サーバーはワークロードの大部分を処理しますが、データが PC に入ってからアプリ内でデータにアクセスできるようになるまでの時間に興味があります。

負荷テストは、非常に大きなデータセットを返す非常に小さなクエリで構成されています。たとえば、select * from SysTablesこのテーブルには 50,000 件以上のレコードがあります。データを受信した後、結果をループする別の負荷を実行します (while notQ.eof ... Q.next ...などを使用)。また、フィールドのorder by Val場所など、クエリにいくつか追加しようとしました。Valvarchar(100)

これが私の負荷テスターのサンプルです。一番下の数字は平均です...

ここに画像の説明を入力

では、実際には、2つの違いは何ですか? OLE は非常に柔軟で、さまざまなデータベース エンジンをサポートしていますが、Native Client は SQL Server のみに固有のものです。しかし、舞台裏で他に何が起こっているのでしょうか? また、それは Delphi がこれらのドライバを使用する方法にどのように影響しますか?

TADOConnectionこれは特に、コンポーネントを介して ADO を使用しTADOQueryています。

私は必ずしもパフォーマンスを向上させる方法を探したり求めたりしているわけではありません。ドライバー間の違いを知る必要があるだけです。

4

8 に答える 8

7

マイクロソフトが述べたように：

SQL Server Native Client は、SQL Server 2005 で導入された、OLE DB と ODBC の両方に使用されるスタンドアロンのデータ アクセス アプリケーション プログラミング インターフェイス (API) です。SQL Server Native Client は、SQL OLE DB プロバイダーと SQL ODBC ドライバーを組み合わせて、 1 つのネイティブ ダイナミック リンク ライブラリ (DLL)。

私の理解では、ADO は OleDB 上のオブジェクト指向のアプリケーション レベルの DB レイヤーにすぎません。すべての場合に OleDB を使用します。プロバイダーが使用する変更点。プロバイダーを指定するとSQLNCLI10、最新バージョンのプロトコルが使用されます。プロバイダーを指定するとSQLOLEDB、一般的な SQL Server 2000 + プロトコルが使用されます。

そのような：

  ADO -> OleDB -> SQLNCLI10 provider -> MS SQL Server (MSSQL 2000, 2005 or 2008 protocol)
  ADO -> OleDB -> SQLOLEDB provider -> MS SQL Server (MSSQL 2000 protocol)

性能に関しては、大差ないと思います。いつものように、処理されるデータによって異なります。

ただし、データベースに最適なプロバイダーを使用することをお勧めします。ある種のデータ (var(maxchar)や などInt64) は、最適に処理されるように指示されます。そしてSQLNCLI10プロバイダーが更新されたので、より調整されていると思います。

于 2012-01-31T17:31:30.837 に答える
5

私はあなたが最適化に集中するべきだと思います：

  • SQLサーバーエンジンとデータベースの設定
  • あなたのクエリ
  • データスキーマ

接続ライブラリ間の速度の違いはごくわずかであり、ごくわずかであるため、システムの速度が非常にわずかに低下する可能性があり、非常に特殊なシナリオで発生する可能性があります。

于 2012-01-31T16:18:57.467 に答える
5

  1. あなたの質問では、OLE と SQL Native Client を混在させています。おそらく、あなたは同時にいくつかのことを意地悪です：

    • OLE -> OLEDB。これは時代遅れの汎用データ アクセス テクノロジです。
    • OLE -> SQL Server 2000 OLEDB プロバイダーである「SQL Server OLEDB プロバイダー」。
    • SQL Server 2005 以降のクライアント ソフトウェアである SQL Server Native Client。また、ODBC ドライバーとして、OLEDB プロバイダーとして含まれています。

  2. OLEDB プロバイダーとサポートされている SQL Server のバージョンについて話す場合は、次のようにします。

    • "SQL Server OLEDB Provider" (SQLOLEDB) は、SQL Server 2000 プロトコルをサポートします。
    • 「SQL Server Native Client 9」(SQLNCLI) は、SQL Server 2000 および 2005 プロトコルをサポートします。
    • 「SQL Server Native Client 10」は、SQL Server 2000、2005、および 2008 プロトコルをサポートします。

    使用している SQL Server のバージョンについては言及していません。一般に、SQL Server のバージョンに対応する SQL Server OLEDB プロバイダーを使用することをお勧めします。そうしないと、サーバー バージョンとクライアント バージョンの間で非互換性が発生する可能性があります。

  3. 抽象的に比較すると、SQLNCLI と SQLOLEDB の違いについて推測することしかできません。

    • 1 つは、サーバー プロトコルをより正確に使用する方法です。
    • 1 つは、より高度なプロトコル機能を使用することです。
    • より多くの状況を処理するために、より多くの処理を実行します。
    • 1 つは、より一般的/最適化されたデータ表現を使用します。

    適切なベンチマーク アプリケーションと環境がなければ、複数の要因に依存する可能性があるため、比較結果を受け入れるのは困難です。

于 2012-01-31T17:20:13.913 に答える
4

簡単な答え:
関係ありません。

長い回答:
2 つのクライアント ライブラリ間のパフォーマンスの違いは、主に測定しているサーバー実行 + ネットワーク データ転送と比較して比較的無視できるため、決定的なテスト データではありません。とにかく、両方のケースで同じ低レベルのレイヤーを使用する可能性が十分にありますが、その上の間接的な違いはわずかです。

実際のところ、テストで目に見える違いが見られない場合は、遅さがクライアント ライブラリの選択に関係していないことを証明しているだけであり、最適化は他の場所で検索する必要があります。

現在のテストでは、SQL プロファイラーを使用して、テストを実行すると同時にサーバーでのクエリの実行時間を測定する必要があります。それらもかなり異なることがわかります。テストの最終結果からこれらの数値を差し引くと、バンドル クライアント時間 + ネットワーク転送のタイミングが得られます。

ネットワーク パフォーマンスは非常に変動しやすく、予想以上にテストに影響を与えます。テストを実行すると同時に誰かにビデオをストリーミングしてみてください.

于 2012-01-31T19:36:46.703 に答える
3

それは確かにデータベース側にある可能性がありますが、システム全体 (少なくともテスト システム) には見るべきことがたくさんあると思います。一般に、データベースに要求している作業が全体の作業に比べて非常に小さい場合、タイミングを取るのは困難です。一般に、データベース タスクは大きな仕事なのか、それとも単に 1 つのデータ項目を取得するだけなのか? ストアド プロシージャまたは単純なクエリを使用していますか? テストを実行する前に、テストでストアド プロシージャを準備していますか? テストを連続して実行するたびに、一貫した時間が得られますか?

于 2012-01-31T16:56:16.947 に答える
1
  • クエリの実行時間は、データベース エンジン (およびスキーマ/クエリの最適化) がどの程度うまく機能しているかを示します。ここでは何を使うかは問題ではありません。ODBC/OLEDB/ネイティブ クエリをデータベースに渡すだけで、そこで実行されます
  • 最初のレコードから最後のレコードまで読み取るのにかかる時間は、データ アクセス レイヤーとネットワークのパフォーマンスを示します。ここでは、データが返されてクライアントに「キャッシュ」されるまでの時間を計測します。データによっては、ネットワーク設定が重要な場合があります。たとえば、テーブルが「大きな」レコードを使用している場合、MTU が大きいほど、クライアントに送信するのに必要なパケット (およびラウンドトリップ) が少なくなる可能性があります。

とにかく、解決策を探す前に、問題を特定する必要があります。クライアント側とサーバー側の両方でアプリケーションをプロファイリングし (SQL Server にはそのための優れたツールがあります)、正確に何が遅くなっているのかを見つけます。そうして初めて、正しい解決策を探すことができます。たぶん、データ アクセス層は問題ではありません。現在、20,000 レコードは小さなデータセットであり、大きなデータセットではありません。

于 2012-01-31T19:19:45.507 に答える
1

ネイティブクライアントを ADO でそのまま使用することはできません。

XMLADO はSQL Serverのデータ型を認識しません。フィールド タイプ:

field: ADOField;

field := recordset.Fields.Items["SomeXmlColumn"];

アクセスしようとすると、次のものfield.ValueがスローされEOleExceptionます。

  • ソース: Microsoft カーソル エンジン
  • エラーコード: 0x80040E21 (E_ITF_0E21)
  • メッセージ:複数ステップの操作でエラーが発生しました。各ステータス値を確認する

ネイティブクライアント ドライバ (例: SQLNCLI、) は、データ型を ADO に次のように提示SQLNCLI10します。SQLNCLI11Xml

field.Type_ = 141

レガシSQLOLEDBドライバーはXmlデータ型をadLongVarWCharとして ADO に提示しますが、Unicode 文字列は次のようになります。

field.Type_ = 203 //adLongVarWChar

そしてVARIANT含まれてfield.Valueいるのは a WideString(技術的には a として知られていますBSTR)です:

TVarData(field.Value).vtype = 8 //VT_BSTR

Microsoftが指摘した解決策：

SQL Server Native Client での ADO の使用

既存の ADO アプリケーションは、SQLOLEDB プロバイダーを使用して、XML、UDT、大きな値のテキストおよびバイナリ フィールド値にアクセスして更新できます。新しいより大きなvarchar(max)、nvarchar(max)、およびvarbinary(max)データ型は、それぞれ ADO 型adLongVarChar、adLongVarWChar、およびadLongVarBinaryとして返されます。XML 列はadLongVarCharとして返され、UDT 列はadVarBinaryとして返されます。ただし、SQLOLEDB の代わりに SQL Server Native Client OLE DB プロバイダー (SQLNCLI11) を使用する場合は、 DataTypeCompatibilityを設定する必要があります。新しいデータ型が ADO​​ データ型に正しくマップされるように、キーワードを "80" に変更します。

彼らはまた、次のように述べています。

SQL Server 2005 で導入された新機能を使用する必要がない場合は、SQL Server Native Client OLE DB プロバイダーを使用する必要はありません。現在のデータ アクセス プロバイダー (通常は SQLOLEDB) を引き続き使用できます。

于 2013-10-02T13:55:28.737 に答える