Flexible Data Model

柔軟なデータモデル

Aerospikeの構造化されているもののスキーマレスの柔軟なデータモデルは、複数言語において、強く型指定されたデータもサポートしています。レコードは、文字列、整数、blob、リスト、マップ等をセルに格納できます。


Aerospikeは、基本的には、キー・バリュー・ストアであり、データの値(非構造化バイナリ・オブジェクトとして保存)はプライマリ・キーに紐づいて読み出すことができます。最上位レベルから見ると、データは、Namespaceと呼ばれるポリシー・コンテナ内に保持されます。このNamespaceは、RDBMSで言うデータベースと同様の位置づけです。このNamespaceは、クラスタ起動時に構成され、その内部のデータ群に対して、データの寿命、レプリケーション、ストレージの設定等を管理します。例えば、より多くのレプリカを持つようにすると、ストレージの容量が必要となりますが、それにより、想定外のハードウエアの不具合の際に、より多くのノードの障害に対して可用性を高めることができます。

Namespace内では、データはさらにテーブルと同様の概念のSet、行と同様の概念のレコードにと分類されます。各レコードは、ユニークなインデックスされたキーと、いくつかの名前付きのBin(列と同様の概念)で構成され、Binには、そのレコードに付随する値を保持できます。その値は強く型指定され、文字列、整数、バイナリに加え、言語特有のblobを自動的にシリアライズ・デシリアライズして保管します。Binの中に保持される値は型指定されていますが、Binそのものはそうではありません。つまり、同じBinに保持される値は、異なるレコードでは、異なる型かもしれません。各レコードは、システム用のフィールドを持っており、それらには、ジェネレーションや寿命(TTL: time-to-life)等があり、システムがCAS(check-and-set)やデータの寿命管理を効率的に行えるようにしています。

これらの構造は、慣れ親しんだRDMBSと似ているように思えるかもしれませんが、異なるポイントがあります。最も重要なのは、Aerospikeでは、完全にスキーマレスであることです。つまり、SetやBin等は、予め定義しておく必要はなく、動作時に追加することができるため、アプリケーション開発時の融通性が非常に高いことになります。任意のスキーマを持つということは、インデックス管理のためのオーバーヘッドを必要としますが、Aerospikeでは、利用方法に応じた最適化を図っています。例えば、Binが一つしか無いようなレコードを保持するNamespaceでは、ストレージとパフォーマンスの両面で最適化が行われており、実システムで幅広く利用されています。

X