3

Access 2007 を SQL Server 2008 のフロント エンドとして使用しているときに、シーケンシャル GUID を使用する場合に SQL Server のパフォーマンスを向上させる方法を知りたいです (これが唯一のコンテキストであることに注意してください)。

私はいくつかのテストを行いました (そして、特にシーケンシャルGUID を使用する場合の SQL Server から、いくつかのかなり驚くべき結果を得ました: 挿入のパフォーマンスは非常に急速に低下し、私にはそれほど早く低下するのは正しくないようです.

基本的に、テストは次のとおりです。

Access フロントエンドから、VBA のみを使用して、100,000 レコードを 1000 のバッチで順番に挿入します。

  • ID とシーケンシャル GUID の両方を PK として試してみました。
  • 私はSQL Server 2008 Standard（デフォルトのインストールだけで特別な調整はありません）とAccess 2007データベースをバックエンドとして試しました。フロントエンドにリンクされたすべてのテーブル。

結果の一部 (さらに、テストに関する私のブログ エントリで生データを入手できます):

データベースが大きくなるにつれて、挿入のパフォーマンスが低下することは明らかですが、ここでは SQL Server のパフォーマンスがまったく良くありません。

http://blog.nkadesign.com/wp-content/uploads/2009/04/chart02.png

SQL Server の結果の拡大表示: http://blog.nkadesign.com/wp-content/uploads/2009/04/chart03.png

2009 年 4 月 13 日編集

サーバー構成に問題があることがわかり、ブログのテストを更新しました。
皆さんの回答に感謝します。彼らは私を大いに助けてくれました。

4

5 に答える 5

4

ここでは 2 つのことが行われます。最初に、SQL は、特定のユース ケースでは、そのままでは必ずしもうまく機能するとは限らないことを指摘することが重要です。それは、彼らが何をしているかを知っている人によって調整されるように設計されたプロの製品です.

比較すると、Access は、構成を行わなくても、ほとんどのユース ケースで非常にうまく機能するように設計されています。このトレードオフの欠点は、2 番目のポイントで説明されています。

SQL Server はスケーラビリティを考慮して設計されています。Access がわずか 100,000 レコードで大幅に低下していることに注目してください。おそらく、100 万を超える前に、SQL のラインを大幅に下回ります。比較すると、SQL サーバーはほぼ完全に安定しており、変動は約 45,000 レコード後に安定し、何百万レコードでも保持され続けます。

編集ここでは、私たちが見ていない何か他のものがあるかもしれないと思います. あなたの SQL の数字は見栄えが悪いと思ったので、独自のテストを実行しました。Windows Vista 3.6 GHz と 2 GB の RAM を実行しているデスクトップで、SQL Server で順次 GUID を使用して挿入を実行しました。

  • 0 レコードで 1 秒あたり平均 1382 挿入

  • 500k レコードで 1 秒あたり平均 1426 回の挿入

  • 0 から 500k まで 1 秒あたり平均 1609.6 挿入、平均フロアは 992 挿入/秒、平均上限は 1989 挿入/秒。

したがって、これを使用中のデスクトップで実行することによって発生する通常の差異を考慮すると、SQL Server の挿入は基本的に 0 レコードから 50 万レコードまで直線的にスケーリングすると言えます。専用の調整されたサーバーでは、さらに一貫性が期待されます (パフォーマンスがはるかに優れていることは言うまでもありません)。

Excel グラフ、1 秒あたりの挿入数 http://img24.imageshack.us/img24/9485/insertspersecond.jpg

于 2009-04-09T02:10:45.000 に答える
2

どこからデータを取得していますか？

ループで一度に記録するのではなく、[エクスポートにアクセス]メニューオプションを使用すると、数値が変わりますか？

VBAは接続パラメータにも非常に敏感であり、必ずしも直感的ではないオプションがたくさんあります。

ID列が受け入れられる場合、なぜシーケンシャルGUIDを検討しているのですか（これは、最後にチェックしたMSSQLの機能の一部です）。

編集：コードを見て、MSDNのRecordsetドキュメントを簡単に確認すると、より効率的なパラメーターを使用できる可能性があります。たとえば、dbSeeChangesとdbOpenDynasetは、他のユーザーが同じ行をいじることを許可しようとしている場合（または、挿入されたIDENTITY値またはおそらくGUIDを取り戻す必要がある場合）に適していますが、これらは必要ないと思います。基本的に、すべてのINSERTまたはUPDATEの後に、データベースからVBAにレコードを読み戻します。これらの接続構成設定を注意深く読んだら、もっと満足のいくものが見つかると思います。

于 2009-04-09T03:05:11.313 に答える
2

私の質問は、テストのセットアップがアプリケーションの現実を表しているかどうかです。要するに、正しいことをテストしていますか?

あなたのアプリは一度に 1 つずつ多数のレコードを追加する予定ですか?

それとも、SQL SELECT に基づいてレコードのバッチを追加する予定ですか?

後者の場合、特に SELECT 内のソース テーブルがサーバー上にある場合は、すべてサーバー側で実行しようとする可能性があります。ODBC では、バッチ追加がすべての行に対して 1 回の挿入として SQL Server に送信されることを認識することが重要です (すべて、テスト コードのレコードセット ベースのアプローチと同様です)。同じプロセスを完全にサーバー側に移動すると、バッチ操作として実行できます。

また、DAO の代わりに ADO を使用して再度テストする必要があります。操作をまったく異なる方法で最適化する場合があります。

最後に、先週、Andy Baron による次の興味深い記事を誰かが私に教えてくれました。

SQL Server にリンクされた Microsoft Office Access アプリケーションの最適化

この非常に有用な記事の内容を今でも吸収しています。この記事では、プロセスを最適化して最大の効率を得るのに役立つ、GUID 固有ではないトピックに関するいくつかの問題について説明しています。

于 2009-04-09T22:21:54.737 に答える
2

パフォーマンスの低下の少なくとも一部はログがいっぱいになっていること、そして GUID id が int よりも 40 バイト長いことに気付きましたか?

しかし、私は口論していません。手を振るだけでなく、実際の測定基準を取っている人を見るのは良いことです。モッドアップ。

于 2009-04-09T02:09:48.513 に答える
1

最後にそのようなもの (GUID PK の挿入が非常に遅い) を見たのは、ログ ファイルがいっぱいになったことが原因でした。挿入パフォーマンスは石のようにかなり急速に低下していました (厳密な測定ではありません。実際のトレースを見るだけですが、確かに対数的であるように見えました)。これは履歴データのプリロードでした。ID PK に移行し、実際にログ ファイルをクリーンアップする処理を行いました。その後、すべてが大幅に改善されました (最初のバージョンでは数時間かかり、完了していませんでしたが、数時間かかりました)。

また、ちょっと考えただけですが、関係する取引はありますか？おそらく、SQL Server トランザクションは、アクセスにはない大きなパフォーマンス ヒットを作成します (アクセスが実際には同時アクセスに対応していないことを考えると)。

于 2009-04-09T03:26:54.507 に答える