データ構造について

内部向け資料で、採用しようとしているアプリケーションに対して使えそうかの感想なので、参考程度に。

Namespaceの説明あたりはこちらの方がちゃんとわかりやすい図付きでまとめていらっしゃいます

Namespace

いわゆるデータベース名みたいなもん
設定ファイルで追加し、再起動が必要となるので気軽に追加はできないのかな？

インメモリやDisk等のデータの保存先や、クラスタ内でのデータレプリケーション数、全体のデフォルトTTL等をネームスペースレベルで設定できる。

Sets

Key+Valueの集合
だいたいテーブルと同じイメージだけど、事前の定義は不要で自動で作られる
1023 Sets / namespace の制限

Record

Key + Binの集合

Key

説明不要
ハッシュ化されて扱われるため、ハッシュ元のKey自体は別のBinとして保存する必要がある

Bin

カラム後述のデータ型を格納できる。スキーマレスで、一部のBinのみUpdateを行うことも可能

Binとして扱えるデータ型

基本データ型

integer
- (8Byte)
- (SecondaryIndex)
string
- (128kByte)
- (SecondaryIndex)
bytes
double
- (8Byte)

複雑なデータ型

list

aql> select * from test.demo where PK='key'
+-----------+
| bin       |
+-----------+
| [1, 2, 3] |
+-----------+

map

aql> select * from test.demo where PK='key'
+--------------------------+
| bin                      |
+--------------------------+
| ["str1", "str2", "str3"] |
+--------------------------+

aql> select * from test.demo where PK='key'
+-------------------------------------------------------------------------+
| bin                                                                     |
+-------------------------------------------------------------------------+
| ["string", 10, ["list", "of", "strings"], {"items":3, "of":2, "map":1}] |
+-------------------------------------------------------------------------+

GeoJSON
地理空間データフォーマットらしい。知識不足でよくしらない。
native-language serialized (blobs)
特に説明要らないと思うし、あんまり使わないと思う

超でかいデータを扱う

Large Lists (LLIST)

無限にデータを格納でき、かつ高速に参照、Scanが可能
Listの各要素を別のレコードとして管理しているイメージ。
LListの各要素にTTLを設定することはできない。アプリケーションとしてScanUDFを使って実装する必要がある。
LListの各要素は特定のキーでソートされている

aerospike 3.5 くらいまで LargeMap, LargeStack, LargeSet があったけど、いつの間にかLarge List に統合されたらしい。

Large List 詳細

続く