Cassandraの構造Cassandra(及び同じ仕様に基づくScyllaDB)のテーブル構造は、通常のRDBと異なります。データが複数のノードに分散することを前提とした構造となっているためです。複数のノードにまたがるクエリーを実行する必要がある分散DBにおいては、結合のように、通常のRDBと同じクエリーをそのまま行おうとすると、ノード間を行ったり来たりする事態が発生し、過剰にオーバーヘッドが生じることになります。Key的なものでクエリーを行うことになります。その結果として、クエリーから設計し、クエリーに応じたテーブル設計を行うという順番の設計になります。以降では、Cassandraのデータ構造を見てみます。上記の図は、Cassandraの全体の構造を表します。それぞれの構成要素は、複数のノードにまたがっています。Clusterはシステム全体(Keyspace、Tableが属する全体の論理的な単位だと思えば良いと思います)、KeyspaceはRDBでいうDBの単位、Tableがテーブルと捉えると的確だと思います。テーブル構造それでは、テーブルの中の構造はどうなっているかと言うと、上記のようになっています。column(key)で構成されます。Keyに直接紐づく情報)。keyによって行われます(*)。Keyを指定する、という形で動きます。Keyのハッシュ値を計算し、その値に応じて、実際のノードを決めています(Cassandraのシステム内)。KeyをWHERE句に指定すれば、対象のノードだけを読みに行く、ということになります。Keyのすぐ外の四角と同じであると考えられます。Keyの含まれる四角と考えるとわかりやすいと思います。Row”と呼びますが、この名前もこの考えから、通常のRowとは異なるという意味の呼称と推測できます。Key各コメントが持つコメントIDが該当します。以上、Cassandraのデータモデルの説明でした。この構造を踏まえて、クエリーの定義、テーブルの定義を行っていくことになります。コメントをキャンセルメールアドレスが公開されることはありません。inc.の会社ホームページです。inc.の会社ホームページです。