こんにちは、株式会社D2C 技術開発部の二瓶（にへい）です。
前回(http://qiita.com/d-tech/items/53e57c8cc425530d6e28 )に続いて、今回はAerospikeのデータモデルなどのお話しです。
KVS(Key-Value Store)なのでRDBより覚えることは少ないです。
Aerospikeシステム構成について
データモデル(Data Model)
簡単に言うとデータ管理方式の概念です。
RDBではお馴染みのテーブル、レコードみたいなところですね。
Namespaces
データを入れる一番大きい管理単位です。
RDBでいうところの狭義の「データベース」に近いものと思ってください。
"データベース名"とかで使う時のアレです。
こんな感じの図の赤い部分のイメージです。
Sets
Namespacesの中に作成します。データを保持する"表"ですね。
RDBでいうところの「テーブル」です。
こんな感じの図の赤い部分のイメージです。
Records
Setsの中に作成します。データを保持する"行"ですね。
RDBでいうところでも「レコード」ですね。
こんな感じの図の赤い部分のイメージです。
key
この辺からRDBの概念から外れてきます。
プログラムのハッシュテーブルのキー(KEY)に近いものです。
RDBで無理やり例えると、プライマリキーが指定されたカラムですかね。違う部分もありますが。
Bins
プログラムのハッシュテーブルの値(VALUE)に近いものです。
ここでも無理やりRDBで例えると、値が入ってるカラムですかね。これも違う部分ありますが。
こんな感じの図の赤い部分のイメージです。
Metadata
Recordsの属性情報ですね。以下を保持してます。
・generation・・・(更新の)世代
・TTL(time-to-live)・・・生存時間（削除までの秒数）
データモデルまとめ
4.データ型について
新しいKVSだけあってRDB並みのデータ型が用意されています。
バイナリデータやコレクション型もあるので、プログラム側でゴニョゴニョやる作業が減らせます。
「NativeFormats」を使えば自作クラスをリスト変換とかもしなくていいみたいです。
今回はここまでになります。
では、また次回。