最新のリリースで、「パフォーマンスの問題」のためにスーパーカラムは望ましくないことを読みましたが、これはどこに説明されていません。
次に、スーパーカラムを使用して素晴らしいインデックスパターンを提供するこのような記事を読みました。
これにより、Cassandraでインデックス作成を行うための現在の最良の方法がわかりません。
- スーパーカラムのパフォーマンスの問題は何ですか?
- インデックス作成の現在のベストプラクティスはどこにありますか?
最新のリリースで、「パフォーマンスの問題」のためにスーパーカラムは望ましくないことを読みましたが、これはどこに説明されていません。
次に、スーパーカラムを使用して素晴らしいインデックスパターンを提供するこのような記事を読みました。
これにより、Cassandraでインデックス作成を行うための現在の最良の方法がわかりません。
スーパーカラムには多くの問題があります。特に、クエリ時にスーパーカラムのすべてのサブカラムを逆シリアル化する必要があるという問題があります(結果が小さなサブセットしか返さない場合でも)。その結果、パフォーマンスが低下する前に格納できるスーパーカラムあたりのサブカラムの数には実際的な制限があります。
理論的には、これはサブ列に適切なインデックスを付けることでCassandra内で修正できますが、複合列の方が優れたソリューションであり、複雑さを増すことなく機能するというコンセンサスがあります。
コンポジット列を利用する最も簡単な方法は、CQL3が提供する抽象化を利用することです。次のスキーマについて考えてみます。
CREATE TABLE messages(
username text,
sent_at timestamp,
message text,
sender text,
PRIMARY KEY(username, sent_at)
);
ここでのユーザー名は行キーですが、行キーとsent_at列のグループを作成するPRIMARYKEY定義を使用しました。これは、その属性にインデックスを付ける効果があるため、重要です。
INSERT INTO messages (username, sent_at, message, sender) VALUES ('bob', '2012-08-01 11:42:15', 'Hi', 'alice');
INSERT INTO messages (username, sent_at, message, sender) VALUES ('alice', '2012-08-01 11:42:37', 'Hi yourself', 'bob');
INSERT INTO messages (username, sent_at, message, sender) VALUES ('bob', '2012-08-01 11:43:00', 'What are you doing later?', 'alice');
INSERT INTO messages (username, sent_at, message, sender) VALUES ('bob', '2012-08-01 11:47:14', 'Bob?', 'alice');
舞台裏では、Cassandraは上記の挿入されたデータを次のように保存します。
alice: (2012-08-01 11:42:37,message): Hi yourself, (2012-08-01 11:42:37,sender): bob
bob: (2012-08-01 11:42:15,message): Hi, (2012-08-01 11:42:15,sender): alice, (2012-08-01 11:43:00,message): What are you doing later?, (2012-08-01 11:43:00,sender): alice (2012-08-01 11:47:14,message): Bob?, (2012-08-01 11:47:14,sender): alice
ただし、CQL 3を使用すると、sent_at述語を使用して「行」をクエリし、表形式の結果セットを取得できます。
SELECT * FROM messages WHERE username = 'bob' AND sent_at > '2012-08-01';
username | sent_at | message | sender
----------+--------------------------+---------------------------+--------
bob | 2012-08-01 11:43:00+0000 | What are you doing later? | alice
bob | 2012-08-01 11:47:14+0000 | Bob? | alice