スポンサーリンク

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, 誕生日、キーワードなど
  • クエリは、最小の1つの等式にする。
    • 未満(less-than)、より大きい(greater-than)、レンジクエリは、優れない。
  • ソートされない
    • 結果は、token order です。query value order ではない。
  • Cassandra がネイティブに理解するデータタイプでの検索は、制限される。
  • CF column オペレーションは、とても速い
  • Column slices は、レンジで取り出すことができる。常にソートされる。リバースできる。
  • target key が TimeUUID の場合、groupingして、タイムスタンプでソートされる。

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, など)の1つ以上の "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 テクニックを使って、取得します。

2つの 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 が必要 ?

スポンサーリンク
スポンサーリンク
 
いつもシェア、ありがとうございます!


もっと情報を探しませんか?

関連記事

最近の記事

人気のページ

はてなの人気のブックマーク

スポンサーリンク
 

過去ログ

2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
2003 : 01 02 03 04 05 06 07 08 09 10 11 12

サイト

Vim入門

C言語入門

C++入門

JavaScript/Node.js入門

Python入門

FreeBSD入門

Ubuntu入門

セキュリティ入門

パソコン自作入門

ブログ

トップ


プライバシーポリシー