はじめに

Cassandra Dayについて

今年、2023年６月１日に、Cassandra Dayが日本でも開催されます。
Cassandra Dayは、昨年、ベルリン、ロンドン、アムステルダム、ハノイ、ジャカルタ、ヒューストン、サンタクララ、シアトル、シンガポールでも開催されました。

今回の東京での開催に向けて、Apache Cassandraに関する記事を発表していきます。

Apache Cassandraについて

Apache Cassandraとは、一言でいうなら、オープンソースの分散データベース管理システムです。

他の分散データベース管理システム同様、複数の汎用サーバーを用いて、ひとつのデータベースを構築します（開発などの目的のため、一つのサーバーのみで構成することも可能です）。

ここでは、詳しい説明は割愛し、興味のある方へのご紹介の役割は、公式サイトやWikipediaに譲ります。

データベースの分類について

ここでは、まず一旦Cassandraという固有名詞から離れます。
データベースを分類する方法には、いくつかありますが、その中から一つを取り上げます。

列指向データベースと行指向データベース

一般的な見方

データベースの分類方法として、列指向データベースと行指向データベースという、分け方があります。

行指向データベースとしてのRDBに対して、いくつかのNoSQLデータベースに対して区別なしに、列指向データベースという呼ばれ方がされることがあります。

実際のところ、一緒くたに「列指向データベース」と呼ばれたりもするデータベースには、大きく二つの種類があります。

ちなみに、日本語のWikipediaでは、この二つの違いに注意を促していますが、「列指向データベース管理システム」に対して、「カラム指向データモデル」という言葉が使われています。
日本語の「列」と外来語をカタカナ表記した「カラム」という言葉の使い分けも恣意的かつ日本国内でしか成立しない不十分な表現と思えますし、そこでの「データモデルを表しており、DBMS内部のデータ格納方式を表しているわけではない」という区別も正確ではないと思えるので、その点も踏まえて、整理していきたいと思います。

列（カラム）指向の二つの意味

まず、「列（カラム）指向」という言葉の指すところを、普遍化して整理してみると、こんなところになるかと思います。

データの編成に列が重要な意味をもつ

これはさらに、以下の二つの特徴に分解できます。

列が「物理配置」に関係している
列単位でのデータ「アクセス」（データの「集約」と呼ばれることも）に優れる

ここまで普遍化した表現に置き換えれば、「列」と関連づけて説明される多くのデータベースに当てはまるといえます。しかし、そこには実態の大きく異なる二つの種類があります。

物理配置上の違い

物理配置においては、以下の二つの種類があります。

A：各行毎に異なるファイルに格納されている。
B：特定の項目（列）の値（とその並び順）によって、レコード（行）が、物理的に分割されている。

データアクセス上の違い

得意とするデータアクセス方式においては、以下の二つの種類があります。

A：特定の列の値の「集計」
B：特定の列の値による「レコード抽出」、「検索（とソート）」

ここで、若干事態をややこしくしているかもしれないのが、「集約」という言葉で、Bの意味を説明されて場合があることです（日本語として不自然ではありませんが、「集約」という言葉で「集計」の意味を連想される方もいらっしゃるのではないでしょうか？強いて英語との対応関係を探るのであれば、「集計(aggregation)」「集約(consolidation)」といったところでしょうか）。

カラムナーとワイドカラム

ここまでの説明は、容易に誤解を招く部分を解きほぐすという意図によって行われましたが、（特に既に理解されている方にとっては）まどろこしいものと見えたかもしれません。

一般に浸透している別の言葉で言い換えれば、つまりは以下の通りです。

A = カラムナー
B = ワイドカラム

それぞれについて、以下に箇条書きで整理してみます。

ここで、これまで、どんなアクセス方法に優れているか、という表現で説明してきた要素は、そのデータベースが設計された目的（オブジェクティブ）と捉えることができます。

カラムナー

オブジェクティブ：特定の列の値の「集計」
- 「天文学的（ヒューマン・リーダブルでない）」量のビッグデータを、人間にとって意味のある値に「集約」（和・平均・最大値などいわゆる集約関数の範疇）
行追加は高コスト（複数ファイルへの書き込み）
データは論理的に「過去」データ
代表的なデータベース（ストレージ）：Google Bigquery、Amazon Athena、Cloudera Impala (Apache Avro, Apache Parquet, Apache ORC)

ワイドカラム

オブジェクティブ：特定の行の値による「検索（とソート）」
- 「無限にスケール（成長）」するデータの分散配置＝探索経路最適化
行追加にコスト最適化（ソート順に追加書き込み）
「リアルタイム」データの扱いに優れる
代表的なデータベース：HBase、Cassandra

まとめ

最後にやっと、「Cassandra」に辿り着きました。
ともすれば同じ「列指向」という言葉で名指されることもあるデータベースだとしても、カラムナーとワイドカラムとでは、全く異なる目的のもとに設計されていることを伝えることができたようであれば幸いです。

自分のこれまでの経験を振り返ると、よくある先入観として、「NoSQL」＝「ビッグデータ」＝「データ分析」＝「情報系システム」という等式があるように感じます（等式がどこまで繋がるかの度合いには、人と場合によって差があるかと思いますが）。これにさらに付け加えるなら、「情報系システム」＝「Nice to have」という式を加えることもできるかと思います。これは、上に整理したワイドカラムの目的とは非常に異なっています。では、ワイドカラム・データベースは、より具体的にどのような場面で利用されているのか?これについては、また機会があれば発表したいと思います。