GridDBは、高性能アプリケーションのためのビッグデータ構造の保存を目指す企業やビジネス向けの革新的な時系列データベースソリューションです。このデータベースは革新的な企業が望む最も望ましい特性のいくつかを可能にします。第一にGridDBはKey-Valueペアのセットアップにより高いパフォーマンスを提供します。第二にGridDBはユースケースやビジネスニーズに応じてより多くの顧客やクライアントにサービスを提供するための高いスケーラビリティを提供します。GridDBは高可用性を提供し、耐障害性を高める永続的な制御クラスタ・インフラストラクチャを可能にします。本記事では、GridDBデータベースをファインチューニングする主要なテクニックを紹介します。データベースのファインチューニングとは、DBの最適化を行い、その総容量で運用することを可能にするテクニックです。このテクニックにより、リソースを節約しつつ、高いパフォーマンスを発揮することができます。手始めに、GridDBアーキテクチャと対話するための環境を構築します。次に、微調整用パラメータを設定し、その使用方法を説明します。最後に、これらのパラメータを使用して、パフォーマンスと可用性をアップグレードします。
環境を整える
GridDBデータベースで実行される操作をうまくファインチューニングするために、事前にツールと依存関係のリストをインストールし、設定する必要があります。
- Anaconda - Jupyter
- Python 3.8 - GridDB Python クライアント 0.8.3
- Swig 4.0.2 - Swig インストール
ここでは、command-line interface（CLI）を使用して、ファインチューニングを行うことにします。つまり、これらの変更や設定を行うために特定のオペレーティングシステムは必要ないのです。編集に関しては、JSON（JavaScript Object Notation）ファイルリーダーを使用して、微調整のための設定ファイルを書き込むことが可能です。
チューニングパラメータの設定
チューニングの対象となるのは、パフォーマンス、可用性、および信頼性です。これらのパラメータは、データベース管理者がデータベースクラスタを選択する際に重視する属性のほとんどを包含しています。 GridDB では、これらのチューニング用パラメータに直接アクセスすることができ、GridDB の設定オブジェクトの値を編集することで変更できるノード定義ファイルを使用します。ファインチューニングが可能な属性は以下の通りです。
-
/dataStore/persistencyMode: 永続性モードの設定に使用される 列 パラメータ。 -
/dataStore/logWriteMode: ログの書き込みモードを設定するための整数個のパラメータ。 -
/transaction/replicationMode: レプリケーションモードの設定に使用する 整数 のパラメータ。 -
/dataStore/storeWarmStart: 開始処理モードを設定するために使用する ブーリアン パラメータ。 -
/dataStore/dbPath: データベースファイルのディレクトリを設定するための 列 パラメータ。 -
/dataStore/backupPath: バックアップファイルのディレクトリを設定するための 列 パラメータ。 -
/dataStore/storeMemoryLimit: メモリバッファサイズを設定するための 列 パラメータ。 -
/dataStore/concurrency: 処理の並列化モードを設定するための整数個のパラメータ。 -
/dataStore/affinityGroupSize: データアフィニティグループの数を設定する 整数 のパラメータ。 -
/checkpoint/checkpointInterval: チェックポイントの実行間隔を秒単位で設定する 整数 のパラメータ。 -
/system/eventLogPath: イベントログファイルの出力ディレクトリを設定するための 列 パラメータ。 -
/transaction/connectionLimit: 接続数の上限値を設定する 整数 のパラメータ。 -
/trace/category: イベントログの出力レベルを設定するための 列 パラメータ。
GridDBデータベースを細かく設定するために、GridDB設定ファイルを編集する必要があります。この作業は、ファイルエディタを使ってファイルを開き、以下のセクションで説明するオプションに応じて値を変更することで行うことができます。
パフォーマンスの更新
GridDBデータベースのパフォーマンスを更新する前に、gsadmコマンドを使用してデータベースを起動する必要があります。このコマンドを実行すると、GridDB のユーザーを使って DB の設定ファイルを編集することが出来ます。この作業は以下のコマンドで実現します。
sudo su - gsadm
設定ファイルを編集するには、ファイルエディタを使用する必要があります。この例では、vimというテキストエディタを使用します。しかし、confディレクトリを使用してファイルの場所を特定することが重要です。この作業は次のコマンドで行います。
vim conf/gs_cluster.json
もし、データベースの同期処理を遅らせることが目的であれば、logWriteMode の値を 1 に変更する必要があります。さらに、このコマンドは persistencyMode を NORMAL に設定すると完璧に動作します。 この値は、設定した遅延タイムラインに基づいてデータを更新します。言い換えれば、あなたのデータは、あなたが選択し、設定した事前定義された時間に基づいてのみ更新されます。このオプションにより、リソースを効率的に使用し、計算能力を他のアプリケーション領域に集中させることが出来ます。このタスクは、以下のようにして実現されます。
"dataStore":{
"logWriteMode":1,
"persistencyMode":"NORMAL",
}
もし同期処理を一貫して行うことが目的であれば、logWriteMode の値を 0 に変更する必要があります。さらに、このコマンドは persistencyMode が KEEP_ALL_LOGS に設定されている場合に完全に動作します。この値はデータベースで実行されたすべての操作を保存するローカルファイルにすべてのトランザクションを保存します。このタスクはメモリを大量に消費しますが、データベース操作を追跡するのに役立ちます。このタスクは以下のようにして実現されます。
"dataStore":{
"logWriteMode":0,
"persistencyMode":"KEEP_ALL_LOGS",
}
性能と可用性
GridDBは高性能かつ高可用性のデータベースとして知られています。この機能はGridDBに格納されたデータを追加ノードに複製するためリソースを消費します。しかし、replicationModeキーにより、これらの機能を制御することが出来ます。言い換えれば、このレプリケーションがいつ行われるかを選択することが可能です。もしフォールトトレランスが必須であるような高データ可用性のアプリケーションを構築する場合は、この値を 0 に設定すべきです。説明すると、この値を 0 に設定することで、レプリケーションの利点をフルに活用することを意味します。 つまり、設定ファイルのデフォルト値である完全な 非同期レプリケーション に設定します。このタスクは次のように行います。
"transaction":{
"replicationMode":0
}
最初の選択とは別の選択肢として、パフォーマンスが最優先されるアプリケーションを作成することも出来ます。トランザクションベースのアプリケーションを構築する場合、スピードは必須であり、これはキー replicationMode に値 1 を設定することで実現できます。 これはデータベースを「準同期レプリケーション」にすることでリソースを節約しパフォーマンスを向上させるものです。このタスクは以下のように行われます。
"transaction":{
"replicationMode":1
}
ファインチューニングの使用例
Pythonを使ってデータセットをロードし、実世界の例を使って微調整の結果をテストします。データセットがロードされると、それは我々のGridDBデータベースに追加されます。 パフォーマンスの変化をテストするために、SELECTコマンドを使用してデータセットの読み込み操作をテストしてみましょう。 このテストにより、微調整前と微調整後のデータベースを比較することが出来ます。
まず最初に、read_csv関数を使ってデータセットを読み込むことにします。言い換えれば、データセットをデータフレームとして読み込み 、そしてそれをデータベースにロードします。このタスクを実行するために、以下のPythonコマンドを実行します。
df = pd.read_csv("iris.csv")このユースケースの第二段階はカラムのデータ型を抽出することです。これはカラムのデータ型を定義してデータベースを作成する際に非常に役に立ちます。このタスクを実行するために、dtypesコマンドを実行します。
df.dtypes
dtypes メソッドの出力は以下の通りです。
s_length float64
s_width float64
p_length float64
p_width float64
variety object
dtype: object
データフレームを GridDB データベースに正しくロードするために、ContainerInfo メソッドを使用する必要があります。この関数は属性の名前を受け取り、そのデータ型を定義します。 今回のコードのフォーマットは、key value paidとして記述します。言い換えれば、キーはカラムの名前を表し、値はデータ型として定義されます。この作業は、以下のPythonのコード行で実現されます。
conInfo = griddb.ContainerInfo("column1",
[["s_length", griddb.Type.FLOAT],
["s_width", griddb.Type.FLOAT],
["p_length", griddb.Type.FLOAT],
["p_width", griddb.Type.FLOAT],
["variety", griddb.Type.STRING]],
griddb.ContainerType.COLLECTION, True)
ループ処理により、CSV ファイルのデータを変換し、GridDB データベースにロードします。これにより、データフレームの各行を読み込み、その値を新しく作成した GridDB データベースに書き込むことができます。これは以下の Python コードで実現されます。
filename = 'iris.csv'
with open(filename, 'r') as csvfile:
datareader = csv.reader(csvfile)
for row in datareader:
toGriddb = col.put(row)
col.commit();
細かい設定オプションを使ってパフォーマンスの変化をテストするために、Python を使って SELECT 操作の速度をテストします。このテストは、データベースの読み取り操作の実行にかかる時間を計算することで実施することが出来ます。 このテストは %%time コマンドで実行することが可能です。以下のコードは、ファインチューニング前に実行されたPythonのコードです。
%%time
# Run query before fine-tuning
query = col.query("select * where variety = 'Iris-versicolor'")
SELECT クエリの実行に使用した Python コードは、実行に 1.3ms かかっています。以下は、上記で説明したPythonコードの出力です。
CPU times: user 1.47 ms, sys: 0 ns, total: 1.47 ms
Wall time: 1.3 ms
クエリの速度を上げるには、トランザクションキー replicationMode の値を1 に設定します。これにより、データベースが 準同期レプリケーション に設定され、よりよいパフォーマンスが得られます。このタスクは以下のように行います。
"transaction":{
"replicationMode":1
}
今回の GridDB の高速化をテストするために、同じ SELECT クエリを実行して実行速度を測定してみます。以下のコードは、ファインチューニング後に実行されたPythonのコードです。
%%time
# Run query after fine-tuning
query = col.query("select * where variety = 'Iris-versicolor'")
SELECT クエリを実行する Python コードの実行には、309 µs かかりました。以下は、上記で説明したPythonコードの出力です。
CPU times: user 305 µs, sys: 0 ns, total: 305 µs
Wall time: 309 µs
今回のテストに基づき、ユースケース・アプリケーションに応じてデータベースを微調整すると、スピードとパフォーマンスに大きな差が出ることが分かりました。 この為、さまざまな構成を実験・検証し、開発フレームワークに適した最適な組み合わせを効率的に開発し、ユーザーに最高の体験を提供するための扉を開くことができます。
結論
今回はGridDBデータベースの様々な設定方法について見てきました。最初に作業用の設定ファイルを構成しファインチューニング用のパラメータを追加しました。今回取り上げたのは、パフォーマンスと可用性の2つの分野です。 最初の領域は、persistencyModeの異なる設定をテストすることによって微調整されました。次に、データベースの可用性とパフォーマンスのパラメータを改善するために、replicationMode パラメータを変更しました。 これらの変更は、あくまでデータベースのユースケースに依存することを理解することが重要です。つまり、開発するアプリケーションとデータの仕分けによって、GridDBデータベースの構成設定が決まるはずです。