このページは、以下の英語ページの抄訳です。最新の情報については、
英語ページを参照してください。
この記事のオリジナルは、Glenn Paulley が sybase.com に 2009 年 10 月に掲載したもので、この中で Glenn は jConnect と SQL Anywhere JDBC ドライバーの違いについて述べています。
パート 1 のブログ記事でも追記しましたが、versions 12 と 16 の SQL Anywhere JDBC ドライバーでは、 JDBC 4.0 をサポートしています。
また、最新の jConnect のバージョンは 7.07 で、こちらも JDBC 4.0 をサポートしています。
パート1 のブログ記事では、SQL Anywhere で使用する場合の jConnect JDBC ドライバーと iAnywhere (現SQL Anywhere) JDBC ドライバーの違いを簡単に述べました。
また、
ホワイトペーパーでは、この 2 つのドライバーのアーキテクチャー的な違いについてまとめています。
jConnect も、iAnywhere (現SQL Anywhere) JDBC ドライバーも JDBC 3.0 をサポートしています。
jConnect は、「pure Java」のソリューション (Type 4 JDBC ドライバー）で、iAnywhere (現SQL Anywhere) JDBC ドライバーは、Type 1 ドライバーです。
これは、iAnywhere (現SQL Anywhere) JDBC ドライバーが SQL Anywhere ODBC ドライバーに依存しているからで、SQL Anywhere ODBC ドライバーが適切にインストールされている必要があります。
「pure Java」のソリューションの方が、良い/速い/より堅牢であると言われることもあることから、 jConnect の方が iAnywhere (現SQL Anywhere) Type 1 ドライバーよりも良いように思われますが、深く知るにつれて、2つのソリューションの間に (1) メモリーの管理、(2) TDS ワイヤプロトコルの使用、(3) セマンティクスが違う、という大きな違いがあることを認識されると思います。
ここでは、それらについて説明します。
メモリー管理
pure Java ソリューションでは、
- 全てのオブジェクトは、Java 仮想マシンが管理します。
- Java ガベージコレクションは、自動的にクリーニングを実施するので、アプリケーションプログラマーは、不明瞭なオブジェクト、メモリーリーク、使用中のオブジェクトの消失、などについて悩む必要はありません。
残念ながら、pure Java のソリューションの弱点は、結局同じで、メモリー管理です。
アプリケーションプログラマーは、オブジェクトのライフスパンに対して、ほとんど、あるいは全くコントロールすることができません。
さらに、プログラマーは、ガーベージコレクションも、効果的にコントロールすることができません。ガーベージコレクションは、重要な時でも Kick inすることができてしまうため、再現不可能なパフォーマンス問題がランダムに発生してしまいます。
そのため、iAnywhere (現SQL Anywhere) JDBC ドライバーのようなハイブリッドのソリューションにおける最も重要な利点は、
メモリー管理です。
- プログラマーは、non-Java のオブジェクトに対してフルにコントロールを維持できます。
- ガーベージコレクションは、Java オブジェクトへの non-Java リファレンスによって妨げるあるいは延期することが可能です。
しかしながら、pure Java であるがゆえ、ハイブリッドのソリューションで最も不利な点は、ご想像のとおり、
これもまた、メモリー管理です。ハイブリッドのソリューションでは、non-Java オブジェクトは、明示的に管理する必要があります。
プログラムエラーは、良くてもメモリーリーク、メモリー破損、最悪の場合には、GPF になります。
もし Java オブジェクトリファレンスが、あまりにも長く保持される場合には、Java ガーベージコレクションは Kick in しません。
CMDSEQ v.s. TDS
jConnect は、Sybase (現SAP) ASE のネイティブのワイヤプロトコル、Tabular Data Stream (TDS) プロトコルを使用します。
一方、iAnywhere (現SQL Anywhere) JDBC ドライバーが使用する iAnywhere プロトコルは、SQL Anywhere のネイティブのワイヤプロトコルで、Command Sequence (CMDSEQ) と呼ばれています。
これら 2 つの間には、セマンティックとパフォーマンスの両方に違いがあります。
それぞれにプラス面とマイナス面がありますが、TDS の利点は、「fire hose (消化ホース)」カーソルをサポートしていることです。
つまり、TDS 言語の一つのコマンドトークンで、サーバーに対してステートメントを実行して全結果セットを記述し、全結果をまとめてクライアントに返すよう指示できます。アプリケーションが結果セットの全ローを要求する状況では、fire hose カーソルは、ワイヤ上の往復トラフィック量を減らすことでパフォーマンス上のメリットを提供しますが、これには、マイナスもあります。
結果セットをキャッシュする責任を持つのはクライアントであり、カーソルのスクロールを実装しなければならないのはクライアントです。
TDS クライアントは、Java アプリケーションがスクロールできる -- 前後のどちらも-- 結果セット内のローの "window" をサポートします。
しかしながら、この window 外のローの範囲を超えるスクロールが発生する場合には、サーバーに対して全リクエストを再発行します。--- "window" 外の以前のローは消失してしまっているため、必ず必要です。
そのため、このスクロール可能なカーソルのモデルでは、カーソルセンシティビティーセマンティクスを保証することは不可能です。
さらに、とても大きな結果セットでは、クライアントが返されたローを高速で処理できない場合、通信ストリームはブロックされてしまい、サーバーをブロックすることになります。
fire hose カーソルは、正しい周辺環境下であれば、 jConnect 接続におけるメリットを提供できますが、最近追加された CMDSEQ における adaptive prefetching (下参照) のサポートを考えると、このメリットも色あせて見えます。
また、最近 jConnect を超える優れた機能が iAnywhere (現SQL Anywhere) JDBC でサポートされるようになっています。
いくつかを下に挙げます。
- TDS は、ローカル接続でも TCP/IP に限定されます。一方、iAnywhere (現SQL Anywhere) JDBC ドライバーは、TCP/IP でも、シェアードメモリーでも使うことが可能です。jConnect アプリケーションを使用している場合、ローカルデータベースを自動的にスタートしてストップすることはできません。なぜならば、このローカルデータベースの自動スタートとストップは、シェアードメモリー接続でのみサポートされているからです。
- RSA、RSA-FIPS暗号化テクノロジーなどの強力な暗号化をサポート。
- サーバーサイドのカーソルを完全にサポート。jConnect はサーバーサイドのカーソルはサポートしていません。クライアントが、その結果セットから少しのローしか使用しない場合でも、全体結果セットをネットワーク越しに retrieve することでクライアントサイドのカーソルを実装します。jConnect アプリケーションを使用する場合には、アプリケーションプログラマーは、SQL クエリーを注意深く書き、最初の数ローをFETCHing するのみに頼らず最小の結果セットを返す必要があります。なぜならば、全結果セットは、各SQL リクエストでクライアントに送られるからです。
- AppInfo の完全なサポート。jConnect は、AppInfo の詳細を truncate します。
- Windows プラットフォームの統合ログイン。
- よりリッチなバッチ SQL 文のサポート - 例えば、ワイド (バッチ) インサートやワイドフェッチ。SQL Anywhere では、jConnect はワイドフェッチのみ完全にサポートしています。jConnect は、アプリケーションからのワイドインサートをサポートしており、ネットワークのトラフィックを削減しますが、サーバーでは、TDS ワイドのインサートがシミュレートされ、各ローが異なる
INSERT 文を開始します。反対に、iAnywhere (現SQL Anywhere) JDBC ドライバーでは、ワイドインサートとワイドフェッチの両方を効率的にサポートします。
CMDSEQ における Adaptive prefetching
SQL Anywhere version 11 では、CMDSEQ 接続におけるプリフェッチの動作のバリアントとして、
adaptive prefetch が導入されました。
プリフェッチは、クライアントへのローのセットを
FETCHrequest に先行して変換することによってクライアント・サーバー型の環境における通信を削減するよう設計されており、これがデフォルトで有効になっています。
プリフェッチは、DisableMultiRowFetch 接続パラメーターを特定することによって、または、プリフェッチ接続オプションを OFF に設定することで無効にすることも可能です。
プリフェッチは、センシティブな値のセマンティクスで宣言されたカーソルに対してOFF にします。
adaptive prefetching では、SQL Anywhere CMDSEQ クライアントは、アプリケーションの動きによって、プリフェッチされたローの数を自動的に - 増加または減少 -調整します。
プリフェッチされるローの最大数のハードリミットは、1000です。
Adaptive prefetching はまた、1 経過秒でアプリケーションが
FETCH できるローの数によってコントロールされます。Adaptive prefetching では、以下のカーソルは有効になっています。
- ODBC および OLE DB:
FORWARD ONLY, READ ONLY (デフォルト) カーソルタイプ; ESQL: DYNAMIC SCROLL (デフォルト), NO SCROLL および INSENSITIVE カーソルタイプ; 全 ADO.Net カーソル
FETCH NEXT オペレーションのみ done (絶対的ではなく、相対的、または backwards フェッチング)。
- アプリケーションは、フェッチ間のホスト変数タイプを変更せず、
GET DATA を使用して、チャンクになったカラムデータを入手することはありません。 (しかし、GET DATA を1つ使用して、値が良いかどうかリトリーブします。）
jConnect セマンティクス
以前のブログ記事で述べた jConnect で接続した際のASE 相当の接続オプションの自動設定に加えて、jConnect には、他にもセマンティクスの違いがあります。
いくつか挙げると、
- TDS プロトコロは、1753 年 1月 1日より前の日付やタイムスタンプはサポートしていません。
- 固定長の
CHAR や BINARY 値は、空白埋めのデータベースからのリトリーバル時に自動的にパッドされます。
- jConnect の古いバージョンでは、空の文字列の値 -- 長さゼロの文字列 -- は、単一の空白が入った文字列としてアプリケーションに戻されます。これは、TDS の前のバージョンでは、空白の文字列とNULL の値を区別しなかったことによります。
もし JDBC アプリケーションで、jConnect を使用したいものの Sybase ASE ライクの動作は求めていない場合、アプリケーションは以下である必要があります。
- これらのオプションを接続後テンポラリーで即座に設定することにより、sp_tsql_environment() システムプロシージャーが発行した接続オプション設定をリバート
- 接続オプション
RETURN_DATE_TIME_AS_STRING を ON に設定し、SQL Anywhere にいつも DATE/TIME/TIMESTAMP 値を文字列として返させる。これにより、TDS が 1753 年 1 月 1 日よりも前の日付を扱えないことを解決します。
- jConnect オプション "dynamic prepare" を TRUE に設定し、準備したステートメントが使用されるたびに再準備されないようにする。
- 各ステートメント毎のカーソル名を設定し、 jConnect が fire-hose カーソルではなく TDS カーソルを使用するように強制する。SQL Anywhere では、 jConnect は、どのカーソルタイプが使用されるにかかわらず、クライアントに結果セットをキャッシュすることに注意してください。
- ステートメント毎にフェッチサイズを明示的に設定し、jConnect が CMDSEQ プリフェッチの動作を疑似するようにする。
- jConnect の古いバージョンでは、
- 'single-blank string' は、empty 文字列として扱う。
- 古い jConnect のリリースでは、サインされていない値はサポートされていないため、使用されていないデータタイプは使用しない。
続くブログで、jConnect と iAnywhere (現SQL Anywhere) JDBC ドライバー間のパフォーマンスの違いの概要について述べる予定です。
時にアプリケーションの性格とアプリケーションが発行する JDBC API の正確な呼び出しという2つの要因に依存することはありますが、私たちのお客様のアプリケーションでの経験では、ほとんどのお客様が iAnywhere (現SQL Anywhere) JDBC ドライバーに切り換えたことでパフォーマンスを大幅に向上しています。
この記事のバックグラウンドを提供してくれた同僚の Karim Khamis に感謝します。
過去のブログ記事より
