はじめに
AerospikeはNoSQLデータベースであり、キーバリュー、ドキュメント、グラフを扱える分散データベースです。
以下に様々な情報を掲載しています。
AerospikeのFAQ（基本編）
Aerospikeの紹介
Aerospikeのアーキテクチャ
Aerospikeは、こちらに記載のように、「Linuxのオンプレのサーバー」「クラウドのインスタンス」「Docker」「Kubernetes」「DBaaS」「Management Service」でご利用いただけます。
ここでは、「Linuxのオンプレのサーバー」「クラウドのインスタンス」の場合のサーバーの構成や設定についてのFAQを記載します。
目次から知りたい情報を探して御覧ください。
サーバー構成
稼働するOSはなんですか？
Aerospikeのバージョンにより、対応するLinuxが変わってきます。
- Version 6.0.0
- Redhat 7, 8
- Ubuntu 18.04, 20.04
- Debian 9, 10, 11
- Version 6.4.0(CPU:x86, arm)
- Redhat 7, 8, 9
- Ubuntu 20.04, 22.04
- Debian 10(x86のみ), 11, 12
- Amazon Linux 2023
- Version 7.0.0, 7.1.0(CPU:x86, arm)
- Redhat 8, 9
- Ubuntu 20.04, 22.04
- Debian 11, 12
- Amazon Linux 2023
- Version 7.2.0(CPU:x86, arm)
- Redhat 8, 9
- Ubuntu 20.04, 22.04, 24.04
- Debian 11, 12
- Amazon Linux 2023
- Version 8.0.0, 8.1.0(CPU:x86, arm)
- Redhat 8, 9
- Ubuntu 20.04, 22.04, 24.04
- Debian 11, 12
- Amazon Linux 2023
サーバーは何台必要ですか？
最低１台から動作しますが、Aerospikeの可用性を活かすためには複数台でのご利用を推奨します。
有償バージョンであるEnterprise Editionについて複数台でご利用いただくには評価ライセンスの取得や有償ライセンスの購入が必要ですが、1台だけであればそれらのライセンスなしでご利用いただけます。
複数の役割のサーバーが必要ですか？
Aerospikeのサーバーはすべて同じ機能を持ち、シェアードナッシングで動作します。
そのためサーバー台数は任意の台数で動作可能で、かつ、ボトルネックや単一障害点がありません。
※この図の[HEARTBEAT]はサーバー間の稼働確認のための通信を行うネットワーク
※[FABRIC]はデータの複製やデータの再配置を行う場合のデータの送受信を行うネットワーク
ストレージの構成はどうすればいいですか？
Aerospikeはインデックスを保存する領域とデータを保存する領域が必要です。
それぞれをどこに保存するかで必要なストレージの構成が変わります。
※ALL FLASHはEnterprise Editionのみ
※「ALL RAM + HDD(永続化用)」のHDDはSSDでも可能
※プライマリ・インデックスは[レコード数]✕[64バイト]が必要
※ユーザによって定義されたセカンダリ・インデックスはプライマリ・インデックスと同じ領域に保存
HYBRID構成
インデックスはRAM、データはSSDに保存します。そのためデータの永続性があります。
データがSSDに保存されるため、ALL RAMに保存する場合とくらべてメモリを減らすことができるためTCOは低くなります。
SSDはデバイスファイル(例：/dev/nvme0n1)を直接指定しRAWデバイスとして使用します。
他にも各種特許を持つ機能によりSSDでもALL RAMに近い性能が出せます。
ただし、性能にはSSDの性能の影響が大きくなります。
開発時など性能を要求しない状況であれば、SSDやHDD上のファイルをデータの保存に使用することもできます。
ALL RAM
インデックスとデータをRAMに保存します。
高性能ではあるものの永続性がなく、かつ、TCOは高くなります。
ALL FLASH(Enterprise Editionのみ)
インデックスもSSDに保存します。
そのため性能が低下しますが、サーバー起動時のインデックスの生成が不要なため、起動が早くなります。
ALL RAM + HDD(永続化用)
ALL RAMの高性能と永続化の両方を実現できます。
ただしTCOが高くなります。
クラウドのインスタンスでHYBRID構成を構築する場合の構成は？
Aerospikeの性能を十分に引き出すためには、高速なディスクを利用できる構成が推奨されます。
AWSのEC2の場合で説明します。
IシリーズのようにインスタンスストアとしてNVMe SSDを使用できるインスタンスをご利用ください。
ただし、インスタンスストアはインスタンスを停止するとクリアされます。そのため、インスタンスストアへの保存時に同時に他のストレージにもデータを保存するシャドウデバイスという機能があります。
このシャドウデバイスとしてEBSを指定することで、インスタンスストアが停止してもデータは永続化できます。
データ分散
サーバー間でデータはどのように分散していますか？
以下のルールに従いデータを分散します。
事前準備
- 複製数(Replication-Factor)の設定
一つデータをいくつのサーバーに複製するかを決めるreplication-factorを決定し事前に設定します。
複製されているサーバー数未満のサーバーが停止してもデータがどこかのサーバーに残っているため、データが無くなることはありません。
自動分散・複製方法
以下のような5台のサーバーで構成され、Replication-Factorが3の場合を例に説明します。
- パーティションIDの決定
レコードのキーをRIPEMD-160 HASHでハッシュ化し20バイトのDIGESTと呼ぶ値を作成する。
このDIGESTの特定の箇所の12ビットを抜き出します。12ビットなので0から4095の値になります。
この値をパーティションIDと呼びます。
以上により、各レコードはどこかのパーティションIDに属します。 - パーティションテーブルの作成
パーティションID(PID)毎にサーバーをユニークに表す値であるノードID(NID)をあわせた値をハッシュ化してソートして、各パーティションIDのサーバーの優先順位を決定します。
これを一覧にした表をパーティションテーブルと呼びます。
- パーティションマップの作成
パーティションテーブルのReplication-Factor分の優先順位の部分だけを取り出したものをパーティションマップと呼びます。
このパーティションマップの各サーバーに各パーティションのレコードが保存されます。
データ書き込み時の動作
クライアントからデータの書き込みがあると、まず、優先順位が1のサーバーに書き込みが実施されます。書き込み成功後、優先順位が2以降のパーティションマップに記載のサーバーに優先順位1のサーバーから書き込み依頼が行われることで複製されます。
サーバー構成が変更された時はどうなりますか？
サーバーに変更が無い場合は、このパーティションマップに従いデータは分散されますが、ノードの停止や追加があると、再度、パーティションマップが作成され、それに従いデータを保持している優先順位が高いサーバーからデータを持たないサーバーに複製されることで、データの再配置(マイグレーション)が行われます。