HANAはクライアント/サーバー型のソフトウェアですので、そのサービスを利用するためにはクライアントからネットワーク経由で接続する必要があります。JDBC、ODBCなど業界標準の技術仕様はもちろんサポートしていますが、知っていると役にたつ独自の仕様があるのも確かです。いったノウハウは、複数のマニュアルや様々な文書に散在していることが多い為、この文書で、HANA固有の機能のメカニズムやそれを利用するための接続文字列について1つにまとめてみたいと思います。HANAへの接続は、サーバー側のトポロジーにより機能やメカニズムが変わる場合がありますので以下の4形態に分けて説明します。URLについて示し、必要に応じてその使用方法を示します。シングルテナント/非スケールアウト非スケールアウト構成のシングルテナントはHANAのトポロジーの内最もシンプルな形態で、1つのインスタンスで1つのデータベースを運用するものです。マルチテナントのsystemdbやテナントDBといった概念はなく外観的にはすべての情報が1つのデータベースで管理されます。この場合、indexserverのSQLポート(デフォルトでは、3xx15。xxはインスタンス番号ですが以降00を仮定します。)に接続することによりHANAのサービスを利用できます。この場合、接続文字列は複数の接続先を;(セミコロン)で区切り列挙する形になります。hdbsqlの場合SQLポート番号がデフォルトのままの場合、3xx15(xxはシステム番号。host1の後の:30015は記述する必要がないことはご存知の通りです。いう使い方になります。URLjdbc:sap://host1:30015/?user=myuser&password=mypass以上が、基本形であるシングルテナント/非スケールアウトの場合の接続方法です。基本的には、ただ1つのindexserverのSQLポート30015を目指せば良いわけですが、HANA側のトポロジーが変わると、メカニズムや接続文字列が微妙に変わってきます。接続上留意する点は、以下の3つです。host1、host2の両方にわたって作成パーティションp1はhost1上に割り当てパーティションp2はhost1上に割り当てクライアントは、接続するノードに関係なくすべてのテーブル、パーティションから結果セットを得られる例:host1に接続しても、t2から結果セットを得ることができる例:host1に接続しても、テーブルt1のパーティションp2から結果セットを得ることができるこの場合、接続文字列を、複数の接続先を;(セミコロン)で区切り列挙することにより、接続確立の際に先頭から順番にトライします。上図の場合は、host1:30015;host2:30015という書き方になります。スケールアウト構成の場合はスタンバイノードを持つ場合があり、フェールオーバーしたときに接続先がアプリケーションにとって透過的であるか、可能な限り自動で再接続できる方が望まれます。上図は、1+1の構成です、フェールオーバ後host2がサービスを引き継ぐことを示しています。この場合も、host:portを列挙して、host1:30015;host2:30015と記述すると、フェールオーバー後の接続は2度目のトライで確立されることになります。以上より、シングルコンテナー/スケールアウトの時の接続文字列は、wroker_host1:port;worker_host2:port;,,,,standby_host1:port;standby_host2:port;,,,,,という記述になります。URLの場合jdbc:sap://host1:30015;host:30015;host3:30015/?user=system&password=mypassといったような記述になります。ステートメント・ルーティング接続確立の過程では、前述のように接続文字列に記述されたhost:portのいづれかに接続先が決まりますが、SQLの送信から結果セットの受け取りまで見ると、クライアント-HANA間の接続が他のノードに変わる場合があります。これは、ステートメント・ルーティングという、SQL文(ステートメント)がアクセスすべきテーブルまたはパーティションが存在するノードに、接続先が変わる(ルーティング)というもので、スケールアウト構成のデフォルトの動きです。これは、データの在り処とSQL文を意識して接続先を判断することにより、ノード間のデータ転送が発生する頻度を下げることを目的としています。上図は、一旦接続が確立した後のステートメント・ルーティングの動作を説明するものです。クライアントがhost1に接続しテーブルt2にアクセスする場合、以下のような動作が想定されます。Prepareを要求する(上図1)ルーティング先の候補host2の情報がクライアントに送られる(上図2)クライアントはhost2に接続しSQL文を実行する(上図3)ステートメント・ルーティングについては以下を参照してください。Modeマルチテナント/非スケールアウトマルチテナント(MDC)は、1つのHANAインスタンスが複数のテナントDBをホストする方式です。同じ数のデータベースを運用するときに、シングルテナントよりもハードウェアリソースの使用効率を高めることができるため、プライベート/パブリックを問わずクラウド基盤で運用されるときの主流となる使い方と期待されています。接続上のポイントは、テナントDBごとに専用のindexserverが起動され、専用のSQLポートに対してリスニングSQLポート番号は3xx15ではない。3xx47といった具合に+3の値が割り当てられる(デフォルト)コンテナー(indexserver)間の通信は原則的には無し。mypass-dでデータベース名を指定する方法もあります。DSNの場合[HANADB1]Driver=/hana/shared/HDB/hdbclient/libodbcHDB.soServerNode=host1:30041[HANADB2]Driver=/hana/shared/HDB/hdbclient/libodbcHDB.soServerNode=host1:30044ODBCの場合、DATBASENAME=db1というようにDB名を記述するプロパティがありますが、SERVERNODEプロパティでポート番号を指定した時点でテナントDBが確定してしまうため必要性がありません。DATABASENAMEプロパティの指定が生きてくる接続方法については後述します。URLの場合jdbc:sap://host1:30041/?user=system&password=mypassjdbc:sap://host1:30044/?user=system&password=mypassデータベース名でNameserverに接続先を問い合わせる方法MDC環境の場合、テナントDB名を指定しながらマスターNameserverに接続すると、そのテナントDBに自動的に接続されるという便利な機能があります。30013)を接続文字列に記述することになります。Scaleoutです。HANAインスタンスが複数ノードから構成され、テナントDBは1つまたは複数のノードに配置されます。接続については、すでに説明したシングルテナント/スケールアウトとマルチテナント/非スケールアウトの組み合わせにすぎません。考え方としては、1つのテナントDBに注目し他のDBを無視すると、複数のシングルテナント/スケールアウト構成とみなすことができます。DB1、DB2それぞれに注目すると、2+1のシングルテナント/スケールアウト3+1のシングルテナント/スケールアウトデータベースを2つのスレーブノードに配置と見做すことができ、DB1への接続文字列は、host1:30013/databasename=db1;host4:30013/databasename=db1host1:30041;host2:3041;host4:30041DB2への接続文字列は、host1:30013/databasename=db2;host4:30013/databasename=db2host1:30044;host2:3044;host4:30044と考えることができます。(hdbsql/ODBC/JDBCによる記述の違いはこれまでの説明を参照してください。)セキュアユーザーストアを使った接続セキュアユーザーストアは、接続文字列を構成する情報の扱いをセキュアな方法で行うための機能です。Clientのライブラリが接続情報を読みだして使ってくれる、という仕組みです。セキュアユーザーストアについては、以下を参照してください。OSレベルのコマンドhdbuserstoreで行います。mypass以上の登録は、いづれの場合もキーワード”MyKey”を接続文字列に与えるだけで接続が可能になります。すると次に、キーワードをどのようにして接続文字列に記述すればいいのか、という疑問が出てくると思いますが、以下のようになります。セキュアユーザーストアを使用した接続セキュアユーザーストアを使って接続する場合は以下のようになります。パスの検討これまでの説明からわかる通り、マルチテナント/スケールアウト構成の場合には、以下の2通りの接続方法があります。データベース名でマスターNameserverに問い合わせる方法host1:30013@db1host1:30013:host4:30013@db1直接indexserverに接続する方法host1:30041host1:30041;host2:30041;host4:300411.の方法は、ホスト名:ポート番号が変わらず、データベースを変更するだけでターゲットのテナントDBに接続できます。したがって、データベースの配置(どのノード上でホスティングされるか)が変わる可能性がある場合に便利な方法です。一方で、1組のホストポートにアクセスが集中するために、同ノードで行われるSQL処理の負荷が接続処理を圧迫しないように配慮する必要があります。一般に接続処理は比較的にメモリ消費が少なく、同時実行が起きやすく、短時間で処理されますから、これを円滑に実行するためには、OLTPのように実行に長時間を要する処理をマスターノード以外で処理することを検討します。そのため、OLAPで使用するデータベースをマスターノード以外に配置することを設計当初及び運用中に検討すべきです。2.の方法は、データベースの移動を行わない場合や、移動時にクライアント側の設定や社内ネットのネームサーバー設定の変更作業が運用上許される場合には適用可能です。クラウド基盤として使用時にセキュリティ上の理由からデータベースごとにSQLポートのネットワークセグメントを分けたい場合にはこちらの方法による場合があるかもしれません。SPS12を基に記述しています。item.Cancel。