GridDB | ドキュメンテーション

# リリースノート

# v5.1

# 変更点

GridDB CE V5.1の主な変更点は以下のとおりです。

  • クライアント通信経路設定

    • クライアントを接続する際の通信経路を設定できます。これにより、クライアントをクラスタとは別ネットワークにも配置できるようになり、従来からのクラスタと同じネットワークからのクライアント接続、およびネットワーク的に離れた場所からのクライアント接続を共存して利用できます。 (本機能は、Javaクライアント, JDBCドライバでサポートされます。)

# クライアント通信経路設定

GridDBクラスタはクライアントに対する複数の通信経路を設定することができます。デフォルトのクラスタ-クライアント間の通信経路は、クラスタノード間の通信経路と共通のものとなりますが、複数通信経路設定を行うと、これとは別の通信経路を用いた接続が可能となります。この通信経路を外部通信経路と呼びます。クライアントはどちらの通信経路を利用するかを個別に指定することが可能となります。

※これまでは、サーバ側の設定により内部経路通信もしくは外部通信経路のいずれかの単一通信経路に限定されてしまい、クライアント側でどちらの通信経路を利用するかを個別に選択できませんでした。

# 設定方法

# GridDBクラスタ(サーバ側)の複数通信経路設定

複数通信経路を有効にするには、ノード定義ファイル、クラスタ定義ファイルについて、 外部通信経路のIPアドレスを指定してクラスタを構成します。

クラスタを構成する各ノードにおけるノード定義ファイル(gs_node.json)で 外部通信経路のIPアドレスを指定してクラスタを構成します。

  • /transaction/publicServiceAddress : トランザクションサービスの外部通信経路に対応するIPアドレスを指定します。
  • /sql/publicServiceAddress : SQLサービスの外部通信経路に対応するIPアドレスを指定します。

※ /transaction/localServiceAddress, /sql/localServiceAddressは廃止されました。

設定例は以下のとおりです。

{
                 :
                 :
    "transaction":{
        "serviceAddress":"172.17.0.44",
        "publicServiceAddress":"10.45.1.10",        
        "servicePort":10001
    },      
    "sql":{
      "serviceAddress":"172.17.0.44",
      "publicServiceAddress":"10.45.1.10",      
      "servicePort":20001
    },
                 :
                 :

また、クラスタ定義ファイル(gs_cluster.json)では 固定リスト方式の設定(/cluster/notificatioMember)に 外部通信経路のIPアドレスとポート番号を指定してクラスタを構成します。

  • /transactionPublic : 外部通信経路となるトランザクションサービス通信用のIPアドレス、ポート番号を指定します。
  • /sqlPublic : 外部通信経路となるSQLサービス通信用のIPアドレス、ポート番号を指定します。

設定例は以下のとおりです。

{
                             :
                             :
    "cluster":{
        "clusterName":"yourClusterName",
        "replicationNum":2,
        "heartbeatInterval":"5s",
        "loadbalanceCheckInterval":"180s",
        "notificationMember": [
            {
                "cluster": {"address":"172.17.0.44", "port":10010},
                "sync": {"address":"172.17.0.44", "port":10020},
                "system": {"address":"172.17.0.44", "port":10040},
                "transaction": {"address":"172.17.0.44", "port":10001},
                "sql": {"address":"172.17.0.44", "port":20001},
                "transactionPublic": {"address":"10.45.1.10", "port":10001},
                "sqlPublic": {"address":"10.45.1.10", "port":20001}
            }
        ]
    },
                             :
                             :
}

# クライアント側の使い方

GridDBクラスタ(サーバ側)が複数通信経路設定がなされている場合に通信経路を選択可能です。

  • 外部通信経路を選択する場合 : connectionRouteプロパティに"PUBLIC"を指定してください。
  • 内部通信経路を選択する場合 : デフォルトで利用可能です。

プロパティの設定例は以下のとおりです。

(Javaクライアント)

Properies prop = new Properties();
props.setProperty("notificationMember", "10.45.1.10:10001");
props.setProperty("connectionRoute", "PUBLIC");
...
GridStore store = GridStoreFactory.getInstance().getGridStore(prop);

(JDBCドライバ)

url = "jdbc:gs:///yourClusterName/?notificationMember=10.45.1.10:20001&connectionRoute=PUBLIC"

# v5.0

# 主な変更点

GridDB CE V5.0の主な変更点は以下のとおりです。

# データ管理部を刷新。大規模データに対する性能強化

ロウ指向ストアだけでなく、カラム指向ストアやオブジェクトストアなど、様々なタイプのストアに将来対応可能にするためにデータ管理部を刷新しました。また、大規模データに対する以下の性能強化を行いました。

  1. コアスケール対応
    • これまで並列実行数(ノード定義ファイルの/dataStore/concurrency)を変更するにはDBの再構築が必要でした。今回、ノード定義ファイルの設定変更とノード再起動により並列実行数が変更可能になりました。
  2. スキャン、データ削除高速化
    • データアフィニティのヒント情報として、文字列 #unique を設定することで、コンテナ(テーブル)単位にブロックを占有してデータを配置することが可能になりました。これにより、スキャンやテーブル削除が高速になりました。
  3. チェックポイント実行時のディスクI/O負荷低減
    • チェックポイント時のログ書き込みを分割で実行することが可能になりました。分割数は、ノード定義ファイルの/checkpoint/particalCheckpointIntervalで調整できます。デフォルトは5です。設定値を大きくすることで、チェックポイントログファイルへの1回の書き込み量を減少させることができますが、起動時のリカバリ時間が増える可能性があります。

# サーバ機能と運用ツールの追加

  1. SQLによるカラム名変更

    • 以下のSQLに対応しました。

    ALTER TABLE テーブル名 RENAME COLUMN 変更前カラム名 TO 変更後カラム名;

  2. GridDBサービス機能

    • OS起動/停止時にGridDBサーバの起動・停止が可能になりました。利用方法はGridDB_Service_ja.mdを参照してください。

  3. エクスポート・インポートツール (opens new window)

    • GridDBのデータのエクスポート/インポートを行うツールを提供します。

# 仕様の変更点

# データベースファイルの配置

従来はdataフォルダにチェックポイントファイルとトランザクションログファイルを配置していました。

V5では以下の配置となります。

  • 従来のチェックポイントファイルは、データが書き込まれるデータファイル(拡張子:"dat")とブロック管理情報を格納するチェックポイントログファイル(拡張子:"cplog")の2つに分かれます。
  • dataフォルダにデータファイルとチェックポイントログファイル、txnlogフォルダにトランザクションログファイル(拡張子:"xlog")を配置します。
  • 更に、data、txnlogの下にパーティション単位でフォルダを作り、その下に各パーティションのファイルを配置します。

# コンフィグの追加

ノード定義ファイル(gs_node.json)に以下のコンフィグを追加します。

  • /dataStore/transactionLogPath : トランザクションログファイルのトップディレクトリ(デフォルト:”txnlog”)
  • /checkpoint/partialCheckpointInterval : チェックポイント時のログ書き込みの分割数。このチェックポイント回数で全ブロックの管理情報を記録

# 注意点

  • 過去のバージョンのDBとの互換性はありません。V4のDBのデータを利用したい場合は、エクスポート・インポートツールを使用してデータを取り出し、V5のDBにデータを登録してください。
  • ハッシュ索引、ロウ期限解放、時系列圧縮、トリガ機能はV5で廃止となりました。ハッシュ索引、期限解放、圧縮の機能については、ツリー索引、パーティション期限解放、ブロック圧縮で代用してください。

# v4.6

# SQLの機能強化と性能強化

  • WINDOW関数、DISTINCT指定の集計に対応しました。
  • LONG型、文字列型以外の様々なデータ型についてもSQL処理を高速化しました。

# コマンド・インタプリタ(gs_sh)

  • GridDBクラスタの運用管理、およびデータ操作を行うことができるコマンドライン・インターフェースツールを提供します。

# v4.5

GridDB CE V4.5の主な変更点は以下のとおりです。

# NoSQLとSQLのデュアルインターフェイスの提供

  1. SQLインタフェース
    • 従来のNoSQLインタフェースに加え、JDBCドライバにてSQLを用いてデータベースにアクセス可能になりました。
    • Group Byや異なるテーブル間のJoinなどSQL92準拠です。
  2. テーブルパーティショニング
    • データ登録数が多い巨大なテーブルのデータを分散配置することで、プロセッサの並列実行を可能とし、巨大テーブルのアクセスを高速化するための機能です。

なお、複数ノードによるクラスタ構成は1台ノードによるクラスタ構成の「シングル構成のみ」に変更しました。

# v4.3

GridDB CE V4.3の主な変更点は以下のとおりです。

# スケールアップ強化

  1. ブロックサイズ拡大
    • データベース初期作成時に選択できるブロックサイズを最大32MBまで拡張しました。ブロックサイズを大きく設定することで、ノード1台当たりで管理可能なデータ量が増加します。また、大量データのスキャンの性能改善が期待できます。
  2. チェックポイントファイルの分割配置
    • チェックポイントファイルを分割し、複数ディレクトリへ分散配置できます。分散配置することでノード1台当たりで管理可能なデータ量が増加します。また、ディスク負荷の分散により、性能改善が期待できます。
  3. 外部と内部の通信を分離するネットワーク構成
    • クライアント-ノード間の外部通信とノード間の内部通信にそれぞれ異なるネットワークインタフェースを割り当てることで、外部と内部の通信を分離できます。ネットワーク負荷の分散が可能になります。

# 性能向上

  1. 複合索引
    • 複数カラムを指定して索引を作成できます。複数カラムの値を組み合わせると選択性が高くなる場合に用いると性能改善が期待できます。

# 開発機能

  1. 複合ロウキー
    • 複数カラムを指定してロウキーを設定できます。複数カラムの値を組み合わせると値が一意になる場合に設定します。サロゲートキー(代替キー)が不要となるため、データ設計が容易になります。
  2. タイムゾーン指定
    • 時刻文字列に「±hh:mm」形式でタイムゾーンを指定できます。

# 1. ブロックサイズ拡大

ブロックのサイズは64KB、1MB、4MB、8MB、16MB、32MBから選択可能になりました。デフォルトは64KBで、通常はデフォルト値のままで変更不要です。

ブロックのサイズは、クラスタ定義ファイル(gs_cluster.json)のパラメータ /dataStore/storeBlockSizeで設定します。

# 2. チェックポイントファイルの分割配置

チェックポイントファイルを分割し、複数ディレクトリへ分散配置できます。

ノード定義ファイル(gs_node.json)のパラメータで分割数と分割されたファイルの配置ディレクトリを設定します。

  • /dataStore/dbFileSplitCount：分割数
  • /dataStore/dbFilePathList：チェックポイントファイル分割時の分割チェックポイントファイルの配置ディレクトリリスト

設定例

```    
"dataStore":{
    "dbFileSplitCount": 2,
    "dbFilePathList": ["/stg01", "/stg02"],
```

# 3. 外部と内部の通信を分離するネットワーク構成

GridDBノードが行う通信のうち、トランザクション処理の通信は、クライアント-ノード間のクライアント通信(外部通信)と、ノード間のクラスタ内部通信、の2種類の通信経路を持ちます。

これまで、その2つは同じネットワークインタフェースを介して通信を行っていましたが、今回2つのネットワークを分離することが可能になりました。

ノード定義ファイル(gs_node.json)のパラメータで設定します。

  • /transaction/serviceAddress: クライアント通信向けトランザクション処理用のアドレス
  • /transaction/localServiceAddress(新規): クラスタ内部通信向けトランザクション処理用のアドレス

ノード定義ファイルの設定例は以下のとおりです。

```    
"cluster":{
    "serviceAddress":"192.168.10.11",
    "servicePort":10010
},
"sync":{
    "serviceAddress":"192.168.10.11",
    "servicePort":10020
},
"system":{
    "serviceAddress":"192.168.10.11",
    "servicePort":10040,
          :
},
"transaction":{
    "serviceAddress":"172.17.0.11",
    "localServiceAddress":"192.168.10.11",
    "servicePort":10001,
          :
},
```

# 4. 複合索引

ツリー索引について、複数のカラムを指定した索引を作成できます。これを複合索引と呼びます。

Javaクライアントを使う場合、IndexInfoクラスの以下のメソッドを使って、カラム名一覧（もしくはカラム番号一覧）を設定・取得します。

  • void setColumnName(java.lang.String columnName)
  • void setColumnList(java.util.List<java.lang.Integer> columns)
  • java.util.List<java.lang.String> getColumnNameList()
  • java.util.List<java.lang.Integer> getColumnList()

サンプルプログラムCreateIndex.java (opens new window)の(3)をご参照ください。

なお、Cクライアントを使う場合は、サンプルプログラムCreateIndex.c (opens new window)のcompositeInfo部分をご参照ください。

# 5. 複合ロウキー

コンテナタイプがコレクションの場合、ROWKEY(PRIMARY KEY)は先頭カラムより連続した複数のカラムに設定できます。ロウキーを複数のカラムに設定した場合は、複合ロウキーと呼びます。

Javaクライアントを使う場合、ContainerInfoクラスの以下のメソッドを使って、複合ロウキーを設定します。

  • void setRowKeyColumnList(java.util.List<java.lang.Integer> rowKeyColumnList)

例：
containerInfo.setRowKeyColumnList(Arrays.asList(0, 1));

サンプルプログラムCompositeKeyMultiGet.java (opens new window)のbuildContainerInfo()部分をご参照ください。

なお、Cクライアントを使う場合は、サンプルプログラムCompositeKeyMultiGet.c (opens new window)のrowKeyColumnList部分をご参照ください。

# 6. タイムゾーン指定

時刻文字列に「±hh:mm」形式でタイムゾーンを指定できます。

また、JavaクライアントのTimestampUtilsのメソッドにタイムゾーンの引数を追加します。

  • add(timestamp, amount, timeUnit, zone)
  • format(timestamp, zone)
  • getFormat(zone)

# v4.2

GridDB CE V4.2の主な変更点は以下のとおりです。

# Windows版のCクライアント

Windows環境で動作するCクライアントライブラリを提供します。

# 障害解析機能の強化

接続プロパティにアプリケーション名(applicationName)を追加しました。指定された名前は、イベントログ等に出力され、問題のあるアプリケーションを特定するのに役立ちます。

# 検索用バッファ制御

クエリのジョブ単位でスワップリード量を監視し、使用するバッファ量を制御することで、クエリによるスワップアウトが原因で登録処理の性能低下が発生することを減らします。

# v4.1

GridDB CE V4.1の主な変更点は以下のとおりです。

  1. オンライン増設

    • 稼働中のクラスタに対して、無停止でノード増設やノード切り離しを行うことができます。

  2. 空間型

    • データ型として空間型が追加されました。また空間索引も利用できます。

  3. 時系列圧縮

    • 時系列データに適した圧縮を時系列コンテナで利用できます。

  4. カラム数の上限値の拡大

    • コンテナで扱えるカラム数の上限値を拡大しました。従来はカラム数の上限値は1024まででしたが、V4.1からは上限値は1024～32,000個になります。(ブロックサイズの設定やコンテナのカラム型による)

  5. 動的なスキーマ変更(カラム追加)の改善

    • コンテナの末尾へのカラム追加において、カラム追加処理中のコンテナへの同時アクセスが可能になります。V4.1より前のバージョンではコンテナのスキーマ変更処理中に、他から同じコンテナにはアクセスできませんでした。また、末尾へのカラム追加の処理を高速化しました。

# オンライン増設

クラスタ運用中にメンテナンス等のために、オンラインでノード切り離したり、メンテナンス完了後に組込む操作ができます。さらには、システムを増強するためにノードを追加することもオンラインでできます。

運用コマンドのgs_appendclusterやgs_leaveclusterなどを使って操作を行います。

# 空間(GEOMETRY)型

空間型のデータは地図情報システムなどでよく利用されています。

GEOMETRY型には、WKT（Well-known text）を用いてデータを記述します。WKTは、地理空間に関する情報の標準化などを推進している非営利団体OGC(Open Geospatial Consortium)にて策定されています。GridDBでは、コンテナのカラムをGEOMETRY型に設定することで、WKTで記述された空間情報をカラムに格納できます。

GEOMETRY型には以下のWKT形式のデータを登録できます。

  • POINT
    • 2次元または3次元の座標により生成される点。
    • 記述例： POINT(0 10 10)
  • LINESTRING
    • 2つ以上の点により表現される、2次元または3次元空間上の直線の集合。
    • 記述例： LINESTRING(0 10 10, 10 10 10, 10 10 0)
  • POLYGON
    • 直線の集合により表現される、2次元または3次元空間上の閉じた領域。POLYGONの頂点は反時計回りに指定します。POLYGON内に島をつくる場合、内部の点は時計回りで指定します。
    • 記述例： POLYGON((0 0,10 0,10 10,0 10,0 0))、POLYGON ((35 10, 45 45, 15 40, 10 20, 35 10),(20 30, 35 35, 30 20, 20 30))
  • POLYHEDRALSURFACE
    • 2次元または3次元の座標により生成される点
    • 記述例： POLYHEDRALSURFACE (((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 0 1 0, 0 1 1, 0 0 1, 0 0 0)),((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 1, 1 0 1, 0 0 1, 0 1 1, 1 1 1)),((1 1 1, 1 0 1, 1 0 0, 1 1 0, 1 1 1)),((1 1 1, 1 1 0, 0 1 0, 0 1 1, 1 1 1)) )

GEOMETRY型を利用した演算は、APIやTQLで実行できます。

TQLでは2次元、3次元の空間を定義する空間生成関数と空間型データ間での演算の関数を提供します。TQLではコンテナ内のGEOMETRY型のカラムと指定した空間データで演算を行いその結果を以下のようにして得ることができます。

SELECT * WHERE ST_MBRIntersects(geom, ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'))

# 時系列圧縮

時系列コンテナは、データを圧縮して保持することができます。圧縮オプションの指定は時系列コンテナ作成時に指定します。データを圧縮することでメモリ使用効率を上げることができます。

圧縮オプションには次の指定ができます。

  • HI ：誤差あり間引き圧縮方式
  • SS ：誤差なし間引き圧縮方式
  • NO ：無圧縮

ただし、圧縮オプションが設定されている時系列コンテナに対しては、以下に示すロウ操作を行えません。

  • 指定ロウの更新
  • 指定ロウの削除
  • 指定時刻より新しい時刻のロウが存在する場合の、ロウの新規作成

# v4.0

柔軟性と利便性の強化

GridDB CE V4.0は、IoTにおける時系列データを高速に処理する"分散データベース"として、その柔軟性と利便性を強化しました。

  1. 大規模データ管理強化
    • 従来のスケールアウト型の分散データベースは1ノード当たり数TBですが、1ノード当たり50TBまでの幅を持たせて、より少ないノード台数で柔軟に効率よく対応するための強化・改善を行いました。
  2. 検索結果取得時の分割処理への対応
    • バッファのサイズなどに収まるよう、内部で自動的に分割し処理することで、大量の検索結果が取得可能になりました。
  3. コンテナ名などの名前に使用できる文字の拡張
    • 他のデータベースとの連携を容易にするためにコンテナ名などに使用できる文字を拡張しました。
  4. データベースファイルのサイズ縮小機能
    • データベースファイルのサイズ(実ディスク割当量)を縮小することが可能になりました。
  5. Cクライアントのライセンス変更
    • AGPL V3からApache V2に変更しました。

# 大規模データ管理強化

従来のスケールアウト型の分散データベースは1ノード当たり数TBですが、1ノード当たり50TBまでの幅を持たせて、頻繁にアクセスされるホットデータはメモリに配置するなどにより、性能劣化を防ぎながらより少ないノード台数で柔軟に効率よく対応するための強化・改善を行いました。

具体的には次のような改善をしました。

  • データブロック未使用領域解放
  • データベースファイルのメタ情報のサイズ削減
  • コンテナ削除など重い機能ををバックグラウンド処理化し応答性を改善
  • バッファコントロール改善による登録・更新性能の向上

# 検索結果取得時の分割処理への対応

検索結果サイズが大きい場合に、「部分実行モード」を使うことで、クエリの結果送受信に用いるバッファのサイズなどがなるべく一定の範囲に収まるよう、必要に応じて実行対象のデータ範囲を分割して処理することが可能になります。

Javaクライアントを使う場合、QueryクラスのsetFetchOption()メソッドを使って、部分実行モード(PARTIAL_EXECUTION)を設定します。 例： query.setFetchOption(FetchOption.PARTIAL_EXECUTION, true);

部分実行モードは、現バージョンでは次の条件すべてを満たすクエリに使用できます。また、LIMITオプションと併用することができます。条件を満たさない場合でも、各種フェッチオプションの設定時点ではエラーを検知しない場合があります。

  • TQL文からなるクエリであること
  • TQL文において、選択式が「*」のみからなり、ORDER BY節を含まないこと
  • 対応するContainerが個々の部分的なクエリ実行時点において常に自動コミットモードに設定されていること

# コンテナ名などの名前に使用できる文字の拡張

クラスタやコンテナなどの名前に使用できる文字を拡張しました。
従来の文字に加え、記号(ハイフン '-'、ドット '.'、スラッシュ '/'、イコール '=')が使用可能になります。

使える文字が増えたことにより、他のNoSQLデータベースと連携する際にオブジェクトの名前を変更することなくそのまま利用できるケースが増え、連携がより容易になります。

# データベースファイルのサイズ縮小機能(データブロック未使用領域解放機能)

データベースファイル（チェックポイントファイル）の使用されていないブロック領域に対して、Linuxのファイルブロック割り当て解除処理を行い、データベースファイルのサイズ(実ディスク割当量)を縮小することができる機能です。

以下のようなケースにおいて、ディスク使用量を削減したい場合にご利用ください。

  • データを大量に削除した場合
  • 今後データ更新の予定が無く、DBを長期保存するような場合
  • データ更新時にディスクフルになり、回避する暫定手段としてDBサイズ縮小が必要な場合

GridDBノード起動時に、gs_startnodeコマンドでデータブロック未使用領域解放オプション(--releaseUnusedFileBlocks)を指定します。

GridDBノード起動時に、データベースファイル（チェックポイントファイル）の未使用領域を解放します。解放された領域は、新たなデータ更新が発生しない限りディスク領域は割り当てられません。

サポート環境は、データブロック圧縮機能と同じです。

# Cクライアントのライセンス変更

これまで、GridDBにはライセンスがAGPL V3のクライアントとApache V2のクライアントがありました。

今回、CクライアントのライセンスをAGPL V3からApache V2に変更することで、すべてのクライアントのライセンスがApache License, version 2.0に統一されました。

# v3.0

  1. 新クラスタ構成方式（固定リスト方式、プロバイダ方式）を追加しました
  2. データブロック圧縮機能を追加しました

# 新クラスタ構成方式（固定リスト方式、プロバイダ方式）

2つの新しいクラスタ構成方式を提供します。環境や利用ケースによってクラスタ構成方式を使い分けることができます。クラスタ構成方式によって、クライアントや運用ツールの接続方式も異なります。

固定リスト方式かプロバイダ方式を用いることで、マルチキャストが利用不可能な環境でのクラスタ構成、クライアント接続が可能になります。

  • マルチキャスト方式
    マルチキャストでノードのディスカバリを行い、アドレスリストを自動構成します。

  • 固定リスト方式
    クラスタ定義ファイルに固定のアドレスリストを与えて起動することで、そのリストを利用します。起動時に全ノードに同一のアドレスリストを設定します。

  • プロバイダ方式
    アドレスプロバイダが提供するアドレスリストを取得して利用します。 アドレスプロバイダはWebサービスとして構成するか、静的コンテンツとして構成することができます。 ノード追加のためのクラスタ再起動不要です。サイズが見積もれない場合に利用します。アドレスプロバイダの可用性の確保が必要です。

# 設定方法

クラスタ定義ファイル（gs_cluster.json）に設定し、同じ内容を全GridDBノードに適用します。

  • 固定リスト方式の場合
    固定のアドレスリストを与えてノードを起動することで、そのリストを利用してクラスタを構成します。 固定リスト方式でクラスタを構成する場合は、クラスタ定義ファイルのパラメータを設定します。

    /cluster/notificationMember (String) : クラスタ構成方式を固定リスト方式にする際に、アドレスリストを文字列で指定します。

    クラスタ定義ファイルの設定例は以下のとおりです。

    {
                             :
                             :
  "cluster":{
    "clusterName":"yourClusterName",
    "replicationNum":2,
    "heartbeatInterval":"5s",
    "loadbalanceCheckInterval":"180s",
    "notificationMember": [
     {
        "cluster": {"address":"172.17.0.44", "port":10010},
        "sync": {"address":"172.17.0.44", "port":10020},
        "system": {"address":"172.17.0.44", "port":10040},
        "transaction": {"address":"172.17.0.44", "port":10001}
     },
     {
        "cluster": {"address":"172.17.0.45", "port":10010},
        "sync": {"address":"172.17.0.45", "port":10020},
        "system": {"address":"172.17.0.45", "port":10040},
        "transaction": {"address":"172.17.0.45", "port":10001}
     },
     {
        "cluster": {"address":"172.17.0.46", "port":10010},
        "sync": {"address":"172.17.0.46", "port":10020},
        "system": {"address":"172.17.0.46", "port":10040},
        "transaction": {"address":"172.17.0.46", "port":10001}
      }
    ]
  },
                             :
                             :
}

  • プロバイダ方式の場合
    アドレスプロバイダが提供するアドレスリストを取得してクラスタ構成を行います。 プロバイダ方式でクラスタを構成する場合は、クラスタ定義ファイルのパラメータを設定します。
    /cluster/notificationProvider/url (String) : クラスタ構成方式をプロバイダ方式にする際に、アドレスプロバイダのURLを文字列で指定します。
    /cluster/notificationProvider/updateInterval (String) : アドレスプロバイダからリストを取得する間隔を指定します。1s以上、2^31s未満の値を文字列で指定します。

    クラスタ定義ファイルの設定例は以下のとおりです。

    {
                             :
                             :
  "cluster":{
    "clusterName":"yourClusterName",
    "replicationNum":2,
    "heartbeatInterval":"5s",
    "loadbalanceCheckInterval":"180s",
    "notificationProvider":{
      "url":"http://example.com/notification/provider",
      "updateInterval":"30s"
    }
  },
                             :
                             :
}

    アドレスプロバイダはWebサービスとして構成するか、静的コンテンツとして構成することができます。以下の仕様を満たす必要があります。

    • GETメソッドに対応。
    • URLにアクセスすると、そのURLが書かれたクラスタ定義ファイルを持つクラスタのノードのアドレスリストをレスポンスとして返す。
      • レスポンスボディ：固定リスト方式において指定するノードリストの内容と同等のJSON
      • レスポンスヘッダ：Content-Type:application/jsonを含む

    アドレスプロバイダからのレスポンスの例は以下のとおりです。

    $ curl http://example.com/notification/provider
[
  {
    "cluster": {"address":"172.17.0.44", "port":10010},
    "sync": {"address":"172.17.0.44", "port":10020},
    "system": {"address":"172.17.0.44", "port":10040},
    "transaction": {"address":"172.17.0.44", "port":10001}
  },
  {
    "cluster": {"address":"172.17.0.45", "port":10010},
    "sync": {"address":"172.17.0.45", "port":10020},
    "system": {"address":"172.17.0.45", "port":10040},
    "transaction": {"address":"172.17.0.45", "port":10001}
  },
  {
    "cluster": {"address":"172.17.0.46", "port":10010},
    "sync": {"address":"172.17.0.46", "port":10020},
    "system": {"address":"172.17.0.46", "port":10040},
    "transaction": {"address":"172.17.0.46", "port":10001}
  }
]

[メモ]

  • 各アドレスおよびポートはノード定義ファイルのserviceAddressおよびservicePortをモジュール(cluster,syncなど)ごとに指定します。
  • クラスタ定義ファイルの/cluster/notificationAddress、/cluster/notificationMember、/cluster/notificationProviderは、使用するクラスタ構成方式に合わせていずれか1つを設定してください。

# クライアントからの接続方法

クライアントのGridStoreFactoryパラメータを設定します。

  • 固定リスト方式の場合
    notificationMember : 固定リスト方式を使用して構成されたクラスタに接続する場合に、クラスタノードのアドレス・ポートのリストを次のように指定します。
    (アドレス1):(ポート1),(アドレス2):(ポート2),...
    notificationAddressおよびnotificationProviderと同時に指定することはできません。

  • プロバイダ方式の場合
    notificationProvider : プロバイダ方式を使用して構成されたクラスタに接続する場合に、アドレスプロバイダのURLを指定します。 notificationAddressおよびnotificationMemberと同時に指定することはできません。

# データブロック圧縮機能

GridDBは、メモリ上のデータをデータベースファイルに書き込むことで、メモリサイズに依存しない大容量化を実現できますが、ストレージのコストは増加します。データブロック圧縮機能は、データベースファイル（チェックポイントファイル）を圧縮することで、データ量に伴って増加するストレージコストの削減を支援する機能です。特に、HDDと比べ容量単価が高いフラッシュメモリをより効率的に活用できます。

# 圧縮方法

メモリ上のデータをデータベースファイル（チェックポイントファイル）に書き出す際に、GridDBの書き出し単位であるブロック毎に圧縮操作を行います。圧縮により空いた領域は、Linuxのファイルブロック割り当て解除処理を行うため、ディスク使用量を削減できます。

# 設定方法

GridDBノードごとに圧縮機能を設定します。

ノード定義ファイル(gs_node.json)の/datastore/storeCompressionModeに以下の文字列を設定します。

  • 圧縮機能を無効にする場合：NO_COMPRESSION（既定値）
  • 圧縮機能を有効にする場合：COMPRESSION

GridDBノード起動時（再起動時）に設定を適用します。 GridDBノードを再起動することで、圧縮機能の動作を有効/無効に変更することができます。

注意点は以下です。

  • データブロック圧縮の対象は、チェックポイントファイルのみです。トランザクションログファイル、バックアップファイル、およびGridDBのメモリ上のデータは圧縮しません。
  • データブロック圧縮により、チェックポイントファイルはスパースファイルになります。
  • 圧縮機能を有効に変更しても、すでにチェックポイントファイルに書き込み済みのデータは圧縮できません。

# 動作確認環境

データブロック圧縮はLinuxの機能を利用しているため、Linuxカーネルバージョンとファイルシステムに依存します。以下の環境で動作確認済みです。

  • OS: CentOS 7.2
  • ファイルシステム：XFS
  • ファイルシステムのブロックサイズ：4KB

← FAQ →