こんにちは。髙岡です。
弊社では、OSS Cassandraの商用版である米Datastaxのライセンス販売及び導入サポートサービスを提供しております。
この度、サービス体制強化の一環として、Datastax社のCassandra認定資格を取得しました。
- The Administrator Certification
- The Developer Certification
今後は、Cassandraの面白い機能や特徴を少しずつ紹介してきたいと思います。
尚、Cassandraは、RDBMSと同じ設計思想で構築してしまうとその特徴を活かすことができません。
そのため、RDBMSと同じ設計思想だと失敗しそうな点に注意して説明していきたいと思います。
今後説明するテーマの候補
＊ 諸事情により予告なく変更される場合があります。
- 分散型データベースとしての特徴
- wirteの一貫性
- readの一貫性 その１
→ 今回説明するテーマ
- readの一貫性 その２
- Primary Keyの考え方
- UPSERTについて
- クラスタのノードの拡張
- 複数データセンター構成
- バックアップ・リカバリ
- 大量データのロード方法
- トランザクション
- アプリケーションドライバからの接続方法
今回は、readの一貫性をご紹介いたします。
同じデータを別のノードに複製しても大丈夫？
同じデータを複数ノードに複製して配置する場合、以下のような素朴な疑問が思い浮かぶのではないでしょうか。
- データが更新された時に複製ノードに障害が発生して書き込みできなかったらどうなるのか？
- 複数ノードへ同じデータが複製されることを保証してくれる仕組みは無いと困るが大丈夫か？
- 他のノードに複製されたデータが何らかの理由でread時に更新されていなかった場合でも、最新データが返ってくるのか？
前回は1.と2.の疑問に答えるためにwriteの一貫性について説明しました。
今回は、3.の疑問に答えるためにreadの一貫性を説明いたします。
readのシーケンス
まず最初に、readのシーケンスを説明してみます。
ここでの例では、データの複製数は3で設定していると仮定します。（RF=3）
わかりやすさのために、read時には、全ノードが応答を返すことをクライアントへ結果を返す条件、すなわち、readの一貫性をallで設定していると仮定します。（CL=ALL）
全ノードのデータが一致しているケース
まずは、ノード1、2、3のデータが最新であり、一致しているケースを説明します。
①クライアントが指定したノードがcoordinator nodeとなり、readリクエストを受信する。
②～③coordinator nodeは、要求されたデータが存在するノードを知っている。その中で、最も反応がよいノードにreadしたいデータを要求する。
④coordinator nodeは要求したデータを取得する。
⑤coordinator nodeは、ノード2とノード3からは、要求されたデータのチェックサムを送ってもらう。
実データよりもチェックサムを送ってもらうほうがが早いからです。
⑥coordinator nodeがノード1、2、3のハッシュ値を比較した結果、一致していることがわかった。
⑦coordinator nodeは､クライアントに要求されたデータを返す。
全ノードのデータが一致していないケース
それでは、何らの原因で全てのノードに更新が反映されなかったため、ノード1、2、3のデータが一致しないケースの挙動はどうなるのでしょうか。
この場合、Read repairという仕組みが働き、最新の更新データで古いデータを持っているノードのデータを更新した後で、最新のデータをクライアントに返します。
①~⑤までは先程説明した一致しているケースと同じなので、⑥以降の挙動を説明します。
⑥coordinator nodeがノード1、2、3のハッシュ値を比較した結果、一致していないことがわかった。
⑦~⑧coordinator nodeがノード2、3のハッシュ値でなく実データを取得する。
⑨coordinator nodeがtimestampを比較して最新データを判別する。
⑩~⑫coordinator nodeが、ノード1とノード3のデータをtimestampが最新のデータでアップデートする。
⑬coordinator nodeが、最新のデータをクライアントに返す。
coordinator nodeは忙しいのです。
readの一貫性all（CL=ALL）の問題点
全ノードが応答を返すことをもってread完了とする条件（CL=ALL）としてしまうと、
後半の例のように、クライアントに応答を返すまでの処理が増えてしまい、応答性能が悪くなることが懸念されます。
また、ネットワークに障害が発生してノード間の通信が遮断された場合、クライアントはデータを取得できなくなり、サービスを継続できなくなってしまいます。
下記例の通り、coordinator nodeはノード3からデータを取得できませんので、クライアントはデータを取得できなくなってしまいます。
CAP定理で表現すると、一貫性 (Consistency)と可用性 (Availability)は満たされるが、分断耐性 (Partition-tolerance)が満たされない状態です。
Cassandraでは、一貫性 (Consistency)が完全に満たされることを犠牲にして、可用性 (Availability)と分断耐性 (Partition-tolerance)が満たされるように、一貫性 (Consistency)を緩めに調整することができます。
全ノードが応答を返すことをもってread完了とする条件（CL=ALL）とするのではなく、一部のノードが応答を返すことをもってread完了とする条件に調整することができるのです。
一貫性 (Consistency)を緩めに調整した場合の挙動の説明と実機検証については、次回のブログで説明したいと思います。
