データ構造について
内部向け資料で、採用しようとしているアプリケーションに対して使えそうかの感想なので、参考程度に。
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 に統合されたらしい。
続く