SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

特集記事

実用段階に入ったNoSQLをおさらい
「Cassandra」の概要と導入手順・基本設定

サーバ(ノード)構成

 RDBタイプの分散処理環境MySQL Clusterと比較しながらサーバ構成の違いを説明します。MySQL Clusterは、異なる3つのノード(サービス)が存在します。データノードは、データを分散して格納します。データノード4台でレプリケーションが2の場合、4つのフラグメントが分散配置され、複製(セカンダリ)が他のデータノードに配置されます。フラグメントのプライマリとセカンダリのいずれかが生きていれば処理を行えます。SQLノードは、SQLステートメントを受け取りデータノードに渡す役割です。管理ノードは、MySQL Cluster全体を調整する役割を担います。MySQL Clusterは、データノードとSQLノードで役割を分担することで、高度な分散処理を実現しています。

図4:MySQL Clusterのノード構成とフラグメントの分散
図4 MySQL Clusterのノード構成とフラグメントの分散

 Cassandraは、機能別の役割はありません。すべてのノードが同じ機能を持っています。ノードは、理論上のリング構造に配置されます。データは、Keyspaceごとに全ノードに分割して格納します。さらに障害に備えて、レプリカ(複製)を別のノードに配置できます。レプリカが3の場合、リングの左となり2つのノードにレプリカが設けられます。そのため、同一ノード情報を持っているノードが2台ダウンしても処理を継続できます。

図5:Cassandraのノード構成とレプリカの配置
図5 Cassandraのノード構成とレプリカの配置

 Cassandraでは、すべてのノードがリクエストを受けられます。リクエストを受け取ったノードがデータを持っているノードと通信を行い必要なデータを取得してリクエスト元に返します。

 Cassandraは、各ノードが独自に処理を行います。レプリカが3の場合、3ノードがデータを保持しています。これらのレプリカ同士で、データに差が発生することを前提に複数数ノードでのデータの整合性チェック機構が備わっています。このような仕組みは、ACIDが前提となっているRDBでは見られません。ぜひ知っていただきたい仕組みです。

ConsistencyLevelによる動作の違い(書き込み処理)

 Cassandraでは、書き込み時に指定するConsistencyLevelによって、書き込み処理の動作が異なります。

図6:書き込み処理の概要
図6 書き込み処理の概要

 リクエストを受け取ったノードは、該当(N3)するノードのいずれかに書き込みを実施します。もし、該当するノード稼働していない場合は、リクエストを受けたノードに書き込みを実施します。さらに何ノードに書き込みが行えたか確認する数を指定できます。

表3:書き込み処理のConsistencyLevel
ConsistencyLevel  内容
ANY 書き込みがHintedHandoffを含む少なくとも1ノードに書かれたことを保証
ONE 書き込みが少なくとも1つのノードに書かれたことを保証
TWO 書き込みが少なくとも2つのノードに書かれたことを保証
THREE 書き込みが少なくとも3つのノードに書かれたことを保証
QUORUM 書き込みが少なくともN/2+1個(過半数)のノードに書かれたことを保証
LOCAL_QUORUM ローカルのデータセンター内のレプリカ数/2+1個のノードに書かれたことを保証
EACH_QUORUM リモートのデータセンター内のレプリカ数/2+1個のノードに書かれたことを保証
ALL 書き込みがすべてのノードに書かれたことを保証

 もちろん、書き込み対象の台数が多いほど処理時間がかかります。そのため、安全性を期待してALLを指定するのは避けるべきです。

ConsistencyLevelによる動作の違い(読み込み処理)

 読み込み処理は、書き込み処理よりも複雑です。なぜなら、どのノードのデータが正しいか判断する必要があるからです。

図7 読み込み処理の概要
図7 読み込み処理の概要

 このように分散して格納しているデータが異なっていることを前提に(タイムスタンプの)最も新しいデータを返します。

表4:読み込み処理のConsistencyLevel
ConsistencyLevel 内容
ONE 最初にリターンのあったレコードをそのまま返答
TWO 最初にリターンのあった2つのレコードのタイムスタンプを比較し
もっとも新しいレコードを返答
THREE 最初にリターンのあった3つのレコードのタイムスタンプを比較し
もっとも新しいレコードを返答
QUORUM 最初にリターンのあったレプリカ数/2+1つ(過半数)の
レコードのタイムスタンプを比較し、もっとも新しいレコードを返答
LOCAL_QUORUM ローカルのデータセンター内のレプリカ数/2+1個のノードから返答があった
レコードのタイムスタンプを比較し、もっとも新しいレコードを返答
EACH_QUORUM リモートのデータセンター内のレプリカ数/2+1個のノードから返答があった
レコードのタイムスタンプを比較し、もっとも新しいレコードを返答
ALL すべてのノードからリターンを待ちレコードのタイムスタンプを比較し、
もっとも新しいレコードを返答

 後処理として、データに差異があった場合には、タイムスタンプの新しいデータに書き換えます。

次のページ
Cassandraのインストールから基本設定まで

この記事は参考になりましたか?

特集記事連載記事一覧

もっと読む

この記事の著者

佐藤 栄一(コネクト株式会社)(サトウ エイイチ(コネクトカブシキガイシャ))

PHPによるWebシステム構築をプロダクトとサポートサービスで支援するコネクト株式会社(創業時はゼンド・ジャパン株式会社)の創立メンバー。主要事業の一つであるMySQLの技術担当(Oracle Certified Expert,MySQL 5.1 Cluster Database Administrator)。ビックデータで注目を集めるCassandraも合わせて担当する。http://www.konekto.jp/

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/7548 2014/01/08 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー