Close現在JavaScriptが無効になっています。すべての機能は利用できません。Edition(以降、これらの製品を指す場合GridDBと記載します)のリリース情報を記述したものです。製品を使用する際の動作環境や参照すべきマニュアルなどについて記載しています。ご使用の前に必ずご一読されますようお願いします。本説明書には、以下の情報を記載しています。製品の概要GridDBは、膨大なデータを、高速かつ安全に蓄積し検索するキー・バリュー型データベースです。以下のような特長があります。インメモリ処理によるデータ管理の高速化スケールアウトによる大容量化ディスクへのデータ保存による永続化、データのレプリケーション、さらにトランザクション機能による高信頼化クラスタへのノードの追加・削除の自律管理による運用の容易化JDBC/ODBCインターフェイスにてSQLを用いてデータベースにアクセス可能GridDBはV4.5より、以下のシンプルな製品体系となりました。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。クイックスタートガイド』(GridDB_QuickStartGuide.html)を参照ください。バグフィックス等の修正記録は、インストールメディア内のFixlist.pdfをご覧下さい。概要は以下の通りです。障害が発生した場合、蓄積されている一部データのレプリカが利用できなくなる場合があります。この場合、GridDBはデータのレプリカを再作成して、全てのレプリカデータを揃え、データベースを正常な状態に復元します。データの規模が大きくなると、レプリカ再作成の所要時間が長くなる傾向があります。今回、このレプリカ再作成の処理の高速化をはかり、レプリカ再作成時間を短縮しました。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。障害が発生した場合、GridDBは自動的に障害発生したノードを切り離し、正常なノードだけでクラスタを再構成してサービスを継続します。クラスタを統括するマスタノードに障害が発生した場合には、マスタノード以外のノード(フォロワノード)に障害が発生した場合と比較して、クラスタの再構成時間が長くなっていました。今回、クラスタ再構成処理の最適化をはかることにより、このような状況でのクラスタ再構成時間を短縮しました。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。定義したレプリカ数以上のノードに同時に障害が発生した場合、データを利用できなくなるためクラスタはサービスを停止します。従来、サービスの再開には、データベース運用者が状況を確認し、クラスタを再構成する必要がありました。今回、データベース運用者の手を介さずに、自動で状況確認とクラスタ再構成を行うツールを提供しました。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。障害が発生した場合でも、それまでに登録されたデータを復元するために、GridDBはリカバリ処理を実行します。この処理を並列実行できるように機能強化しました。これにより従来よりもリカバリ時間が短縮され、大規模なデータに対して高速にノードが起動できるようになりました。機能リファレンス』(GridDB_Web_API_Reference.html)を参照ください。SQLメモリ使用量監視機能SQLを実行する際、GridDBは各種演算や処理のために作業領域用メモリを使用します。この作業用メモリの使用量を監視し、GridDBの安定稼働を妨げるほど過剰にメモリを必要とした場合にはSQLを自動的に停止させ、そのSQLをログに出力します。データベース管理者ガイド』(GridDB_AdministratorsGuide.html)を参照ください。従来、WebAPIでは、データ登録、検索等の一部データ操作のみをサポートしていました。今回、DDL、DMLの機能を追加し、WebAPIのみで一通りのデータ操作ができるようになりました。APIリファレンス』(GridDB_Web_API_Reference.html)を参照ください。APIのみを提供していました。今回、OSSを利用してGridDBのSQLを利用するためのガイドを提供しました。API(SQL)ガイド』(GridDB_Python_API_SQL_Guide.html)を参照ください。<その他>OSの対応バージョンを追加しました。24.04Pythonの対応バージョンを追加しました。3.7/3.8/3.9/3.10/3.11/3.12Javaの対応バージョンを追加しました。support)のリビジョンのみをサポートします。過去バージョンの変更点については、過去バージョンの変更履歴をご参照ください。EEの機能の一覧です。サーバとクライアントによって異なります。通信の暗号化はサポートされません。サーバは以下に示すスペック以上を推奨します。32GBLDAP認証を行う場合、サポートするLDAPサーバは以下です。2016)SSL通信を行う場合、必要なソフトウエアは以下です。3.6/3.7/3.8/3.9/3.10/3.11/3.12SSL通信を行う場合、SSLモジュールが必要です。3.6/3.7/3.8/3.9/3.10/3.11/3.12SSL通信を行う場合、SSLモジュールが必要です。パッケージとインストールについてGridDBには9つのパッケージがあります。GridDBのサーバモジュールとサーバ起動、バックアップ・リストア用の運用コマンドなどを含みます。サーバ起動、バックアップ・リストアをのぞく運用コマンド、エクスポート・インポートツール、クラスタ運用管理コマンド・インタプリタ(gs_sh)を含みます。統合運用管理GUI(gs_admin)を含みます。Cのヘッダファイル(/usr/include/gridstore.h)とライブラリ(/usr/lib64/libgridstore.so,•libgridstore_advanced.so,)を含みます。•gridstore-jdbc.jar)を含みます。Pythonのパッケージ(griddb_python)を含みます。Node.jsのモジュール(griddb_node)を含みます。Goのパッケージ(griddb/go_client)を含みます。クイックスタートガイド』(GridDB_QuickStartGuide.html)をご参照ください。GridDBのマニュアルGridDBには以下のマニュアルがあります。製品概要やGridDBを簡単に利用する手順を説明したマニュアルです。データベースの物理設計や運用などについて説明したマニュアルです。JavaやC言語のAPIの使用方法や、データ登録や検索などのプログラム例を説明したマニュアルです。SQLのチューニング手順やSQL最適化のルールについて説明したマニュアルです。災害に備えたディザスタリカバリの設定方法について説明したマニュアルです。時系列データを自動集計する機能をETLを用いて実現する方法について説明したマニュアルです。リファレンスインフラ設計者/運用管理者/アプリケーション開発者の方が対象です。GridDBの機能全般について説明したマニュアルです。起動コマンドやエクスポート・インポートツールなどの運用ツールの使用方法を説明したマニュアルです。GridDBのエラーコード、および原因や対処方法の一覧です。GridDBの監視を行うためのZabbix向けの設定やテンプレートの利用方法を説明したマニュアルです。Dockerfileサンプルの利用方法を説明したマニュアルです。Ansibleを用いて、GridDBの構築を支援するテンプレートの利用方法を説明したマニュアルです。アプリケーション開発のためのAPIやクエリ言語のリファレンスです。エラーコード』(GridDB_ErrorCodes.html)を参照ください。V4以前で作成したデータベースファイルは利用できません。V4データベースの場合、変換ツールでV5データベース形式へ変換してください。V3以前のデータベースファイルの場合は、エクスポート、インポートツールによるデータの移行が必要です。移行に関しましてはサポート窓口にご相談ください。クラスタは同一メジャーバージョンのノードのみで構成できます。ネットワークに異なるメジャーバージョンのノードが混在しないよう注意してください。V2.7以前のエクスポート機能で出力するZipファイルは、V2.7以降では利用できません。SQLインターフェイスでは、NoSQLインターフェイス固有の以下のデータ型をテーブルのカラムの型として使用できません。問い合わせでのデータ型やシーケンスを柔軟に処理するため、SQLエラーとならない場合があります。クラスタのノードのバージョン互換性V4からV5の移行でローリングアップグレード機能を利用することはできません。APIとクラスタのバージョンの互換性V4のAPIを利用してV5クラスタを操作可能です。廃止機能を使った場合はクラスタ側でエラーとなります。V3以前のAPIによるV5クラスタの操作はできません。与えるロウ数を10万ロウ程度以内に抑えて使用して下さい。これ以上の件数のロウを登録する場合には、multiPutに一括でまとめて与えることは避けて、件数を小分けに分割して繰り返し登録して下さい。行われず、作成時の文字列を指定する必要があります。データベース"dbTest"を作成後、"DBTEST"、"dbtest"などは作成できない。⇒作成時は大文字小文字を同一視するため、大文字小文字が異なる同名のデータベースは、同じものとして扱う。データベース"dbTest"を作成後、"DBTEST"や"dbtest"の指定で削除はできず、作成時の"dbTest"を指定する必要がある。⇒削除時は大文字小文字を同一視しないため、大文字小文字が異なる同名のデータベースは、異なるものとして扱う。ノードアフィニティとパーティショニングを同時に指定してテーブル作成を行うことはできません。V4.0.3までは空値を設定していました。将来のバージョンで、空値/NULL値を選べるように対応する予定です。データベース障害等で一部のパーティションが参照できなくなった場合、gs_adminではコンテナ情報を取得できません。一部パーティションが参照できない場合でも、gs_shでは、正常なパーティション上のコンテナ情報は取得できます。'=')を含むクラスタ・データベース・コンテナに対する操作は実行できません。一度でもカラムを追加すると、そのテーブルのカラム名は変更できません。変更した場合には、そのテーブルのロウ参照でエラーになります。次バージョンで修正予定です。概要は以下の通りです。<運用強化>サイト間データベースレプリケーション稼働中のGridDBクラスタから、別サイトにあるスタンバイ系のGridDBクラスタに常時データレプリケーションする運用が可能になりました。大規模障害等により稼働中クラスタが停止しても、スタンバイ系クラスタへの切り替えを短時間で行えるようになります。今回追加した運用コマンドを利用することで、ユーザの環境・要件に合わせたデータレプリケーションを実現できます。これにより、万が一大規模な障害が発生しても、スタンバイ系のクラスタに切り替えることでユーザシステムの継続稼働が可能になります。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。<データベース機能>クラスタパーティション配置の強化GridDB内部ではクラスタパーティションと呼ばれる単位にデータを分割し、クラスタの各ノードへの割当てを自動計算することで障害時の可用性を担保しています。今回、この自動計算のアルゴリズムとして、各ノードに順番にクラスタパーティションに割り当てるラウンドロビン方式の割当てを追加し、ユーザが指定できるようになりました。これにより、ユーザがデータ配置を理解しやすくなります。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。データベース圧縮アルゴリズムの追加これまでデータベース圧縮機能を提供していましたが、今回、データベース圧縮に利用できる圧縮アルゴリズムを追加しました。性能やサイズなど要件に応じて選択できるようになります。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。<SQLの強化>テーブルパーティショニングの強化SQLのテーブルパーティショニング機能を用いて、日々増加する大規模なテーブルのデータを一定の時間間隔で分割し、GridDB内部で小分けして管理できます(インターバルパーティショニングとインターバルハッシュパーティショニング)。小分けにすることで、大規模なテーブルのデータをクラスタの各ノードやスレッドにデータを分散配置できるようになり、分散並列に処理できるようになります。これまでは最小の分割単位は1日(DAY)でしたが、今回、1時間(HOUR)単位でテーブル分割できるようになりました。SQLリファレンス』(GridDB_SQL_Reference.html)を参照ください。min/maxの高速化SQLのmin/maxの演算を行う際、可能な限り索引を利用して高速化できるようになりました。チューニングガイド』(GridDB_SQL_TuningGuide.html)を参照ください。蓄積された大量の時系列データを自動的に集計して集計結果を蓄積しておくことで、ユーザが集計結果を取得する際に、処理時間を短縮できるようになります。V5.5ではETLで実現するガイドを提供しましたが、今回、GridDBコマンドシェル(gs_sh)を使って実現できるようになりました。そのためのGridDBコマンドシェル(gs_sh)の機能追加を行いました。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。V5.5以前のV5系のバージョンで作成されたデータベースでも読込み、起動が行えます。V5.6で追加された圧縮設定(COMPRESSION_ZSTD)にして起動すると、それ以降はV5.5以前のバージョンでは読込み、起動ができなくなります。バージョンアップ後、設定を変更する前にはデータベースのバックアップをとることを推奨します。用語の統一のため、運用コマンドのgs_rollingupgradeをgs_rollingupdateに名称変更しました。以下のOSバージョンに対応しました。概要は以下の通りです。検索を実行する際のジョイン順序の最適化を強化しました。従来のSQLプランは、ユーザから与えられたSELECT文の記述内容や記述順に従い、ルールを用いて生成されていました。そのため、ユーザはルールを理解したうえで、テーブル規模や絞込み条件に合わせて、好ましいプランが生成されるようにSELECT文を記述する必要がありました。今回の強化では、検索実行の過程で求められるロウ数(テーブル規模や絞込み条件等を勘案して概算)をコストとして計算し、複数テーブルの最適なジョイン順序を決定してプランを生成できるようになりました。チューニングガイド』(GridDB_SQL_TuningGuide.html)を参照ください。パーティショニングテーブルに関する索引ジョインの最適化パーティショニングテーブルを含む場合でも、可能な限り索引ジョインを実行するように強化しました。従来は、対象のテーブルに索引が付与されている場合でも、GridDB内部の制約により索引ジョインを行えないケース(テーブルの分割数が大きすぎる場合など)があり、テーブルスキャンを行うことがありました。今回の強化では、内部の詳細な条件(テーブル分割数、分割種別や索引種別)によらず、可能な場合には索引ジョインを行うプランを生成、実行できるようになりました。SQLのバッチ更新のサポートバッチ更新を行うJDBCメソッドを新たにサポートしました(PreparedStatementの場合にのみ対応)。JDBCドライバ説明書』(GridDB_JDBC_Driver_UserGuide.html)を参照ください。<運用機能>ローリングアップグレード支援コマンドの追加ローリングアップグレードの実行手順を簡単にする支援する運用コマンドを新たに追加しました。従来からローリングアップグレードは可能でしたが、ユーザの実行手順が多く操作が煩雑でした。この手順が削減され実行が容易になります。運用ツールリファレンス』(GridDB_OperationToolsReference.html)を参照ください。クラスタ運用管理コマンド・インタプリタ(gs_sh)の検索結果の標準出力にTABLE形式を追加クラスタ運用管理コマンド・インタプリタ(gs_sh)の検索結果の標準出力にTABLE形式を新たに追加しました。準出力でしたが、TABLE形式での標準出力が可能になりました。運用ツールリファレンス』(GridDB_OperationToolsReference.html)を参照ください。蓄積された大量の時系列データを自動的に集計して集計結果を蓄積しておくことで、ユーザが集計結果を取得する際に、処理時間を短縮できるようになります。この時系列データの自動的な集計をETLを用いて実現するガイドを提供します。自動集計ガイド』(GridDB_ETL_Auto_Aggregation_Guide.html)を参照ください。以下のOSバージョンに対応しました。22.04以下のOSバージョンには非対応となりました。8.4/8.5クライアントライブラリについては、上記に加え以下のOSバージョンに対応しました。V5.4の変更点V5.4では、メタテーブルでデータベース毎の統計値を参照できるようになりました。インターバルパーティショニングテーブルの場合にデータパーティションをどうGridDB内で配置するかをヒントで指定できるようになりました。APIおよびODBCが利用するOpenSSLのバージョンを変更し、通信の暗号化機能のサポートOSを変更しました。概要は以下の通りです。データベース統計機能GridDBの統計値は、SQLを用いてメタテーブルを検索することで取得できます。従来、GridDBの統計値としては、クラスタ全体の値(複数のデータベースが存在する場合はそれらの合計)が取得されていました。今回、この統計値を強化し、データベース毎の統計値(#database_stats)を取得できるようになりました。従来からある統計値(#sqls等)については、そのユーザが接続しているデータベースのみの値を取得できるようになりました。(管理者(GridDBのadmin)の場合は、従来通りクラスタ全体の統計値が取得できます。SQLリファレンス』(GridDB_SQL_Reference.html)を参照ください。ユーザ指定データパーティション配置機能インターバルパーティショニングテーブルのデータは、テーブル作成時に指定された日付区間毎に複数のデータパーティションに分割されます。従来、各データパーティションは、GridDBが配置を決定して、処理を担当するいずれかのスレッドやノードに割り当てられます。今回、GridDB内部で自動で決定していたデータパーティションの配置について、ユーザがヒントを指定できるようになりました。これにより、アプリケーションの登録や参照の処理パタンに応じたデータパーティションの配置を指定できるようになりました。機能リファレンス』(GridDB_FeaturesReference.html)を参照ください。1.1.1は2023/9にサポートが終了するため、OpenSSL3.0への変更を行いました。APIおよびODBCが利用するOpenSSLのバージョンを変更しています。通信の暗号化機能を利用する場合には、OpenSSL3.0.7以上が必要となります。通信の暗号化(SSL接続)機能のサポートOSの変更OpenSSL3.0への変更にともない、通信の暗号化(SSL接続)機能のサポートOSを変更します。