UD Day 22 DB仕様1 Cassandraの構造

Cassandra(及び同じ仕様に基づくScyllaDB)のテーブル構造は、通常のRDBと異なります。データが複数のノードに分散することを前提とした構造となっているためです。複数のノードにまたがるクエリーを実行する必要がある分散DBにおいては、結合のように、通常のRDBと同じクエリーをそのまま行おうとすると、ノード間を行ったり来たりする事態が発生し、過剰にオーバーヘッドが生じることになります。このような状態を回避するために、基本的にはRDBで言うPrimary Key的なものでクエリーを行うことになります。その結果として、クエリーから設計し、クエリーに応じたテーブル設計を行うという順番の設計になります。
以降では、Cassandraのデータ構造を見てみます。

クラスター、キースペース、テーブルの関係性

上記の図は、Cassandraの全体の構造を表します。それぞれの構成要素は、複数のノードにまたがっています。Clusterはシステム全体(Keyspace、Tableが属する全体の論理的な単位だと思えば良いと思います)、KeyspaceはRDBでいうDBの単位、Tableがテーブルと捉えると的確だと思います。

テーブル構造

それでは、テーブルの中の構造はどうなっているかと言うと、上記のようになっています。

RDBでいうPrimary Keyは、Composite Keyと呼ばれ、これは、Partition KeyとオプションであるClustering column(key)で構成されます。
また、static columnというpartition keyに対して紐づくデータを持つこともできます(Partition Keyに直接紐づく情報)。
データの分散(ノードへの分散)は、Partition keyによって行われます(*)。Partitionの中で特定の値にアクセスする場合に、さらに、Clustering Keyを指定する、という形で動きます。
(*)…Partition Keyのハッシュ値を計算し、その値に応じて、実際のノードを決めています(Cassandraのシステム内)。逆に言えば、Partition KeyをWHERE句に指定すれば、対象のノードだけを読みに行く、ということになります。

補足)RDBでいうところの行は、Clustering Keyのすぐ外の四角と同じであると考えられます。これらの行のいくつかをグループとしてまとめて、それに対してIDをふって、グループ単位でのアクセスをしやすくしているのがPartition Keyの含まれる四角と考えるとわかりやすいと思います。Partion Keyのすぐ外の四角を”Wide Row”と呼びますが、この名前もこの考えから、通常のRowとは異なるという意味の呼称と推測できます。ただし、これは、データをwide modelで作った場合であり、RDB的なものにもできます(skinny model と呼ばれます)。
Partition Key、Clustering Keyの例)UDの場合、ウェブページに対してコメント(複数も可)が記載されるシステムなので、Partition KeyはURL(もしくはURLを加工したID)、Clustering Key各コメントが持つコメントIDが該当します。

以上、Cassandraのデータモデルの説明でした。この構造を踏まえて、クエリーの定義、テーブルの定義を行っていくことになります。(続く)