Cassandra インデックステクニック

http://www.slideshare.net/edanuff/indexing-in-cassandra



Primary Index は、 row key です。

Users = {
	"foo" : {
		"email": "foo@bar.com"
	}
}

すべてのインデックスは、自身の "hidden" CF としてストアされる。
Nodes は、彼らがストアしている row をインデックスする。
query(問い合わせ)を発行したときに、すべてのノードに送られる。

レンジオペレーションgetは、コーディネータノードによって、メモリ内で、実行される。

いくつかの制限

• 高密度の value は、推奨しない。
• たとえば、 timestamp, 誕生日、キーワードなど
• クエリは、最小の１つの等式にする。
• 未満(less-than)、より大きい(greater-than)、レンジクエリは、優れない。
• ソートされない
• 結果は、token order です。query value order ではない。
• Cassandra がネイティブに理解するデータタイプでの検索は、制限される。

• CF column オペレーションは、とても速い
• Column slices は、レンジで取り出すことができる。常にソートされる。リバースできる。
• target key が TimeUUID の場合、groupingして、タイムスタンプでソートされる。
• inbox, feed, log などに良い(Twissandra)。
• https://github.com/twissandra/twissandra

Indexes = {
	"User_Keys_By_Last_Name" : {
		"foo" : "e1...",
		"bar" : "e2...",
		"hoge" : "e3...", // << 重複は許されない。
		"hoge" : "e4...", // << 重複は許されない。
	}
}

SuperColumn だと

Indexes = {
	"User_Keys_By_Last_Name" : {
		"foo" : {
			"e1..." : null
		},
		"hoge" : {
			"e3...": null,
			"e4...": null
		}
	}
}

注意して利用する

• 公式に非推奨ではないが、推奨しない。
• supercolumn だけソートされ、subcolumn ではない。
• パフォーマンスの問題がある
• もっとネストしたいならば？
• subcolumn は、subcolumn を持てない。
• たくさんのプロジェクトが supercolumn の利用をやめている

Indexes = {
	"User_Keys_By_Last_Name" : {
		{ "foo", 1} : "e1...",
		{ "bar", 1} : "e2...",
		{ "hoge", 1} : "e3...", // << OK!
		{ "hoge", 2} : "e4...", // << OK!
	}
}

Composite COlumn Names
Comparator = "CompositeType" or "DynamicCompositeType"

{ "foo", 1, 1, 1, ... } : "e1..."
1..N Components

Cassandra のサポートする column type (UTF8, IntegerType, UUIDType, など)の１つ以上の "component" values から column name を作る。

{ "foo", 1, 1, 1, ... } : "e1..."
{ "foo", 1, 1, 2, ... } : "e1..."
{ "foo", 1, 2, 1, ... } : "e1..."
{ "foo", 1, 2, 2, ... } : "e1..."

それぞれの component type のソートの順番を使って component value によってソートされます。
普通の column slice テクニックを使って、取得します。

２つの Composites タイプ

- column_familes:
 - name: My_Composite_Indef_CF
 - compare_with:
     CompositeType(UTF8Type, UUIDType)

 - name: My_Dynamic_Composite_Index_CF
 - compare_with:
    DynamicCompositeType (s=>UTF8Type, u=>UUIDType)

index の利用の主な違いは、
CF ごとの index vs row ごとの index ですべて index する。

Static Composites
Dynamic Composites

典型的な Composite Index エントリ

{ <term 1>, ..., <term N>, <key>, <ts> }

term 1...N: query のための term (例: last_name, first_name)
key: ターゲット row key
ts: ユニークなタイムスタンプ、たいてい タイムベースの UUID

どのように機能するか？

• クエリは、簡単になる。
• 一般的な column スライスオペレーション
• 更新が大変になる
• 古いバリューを削除し、新しいバリューを挿入しなければならない。
• write の前に read が必要 ?

---