Comments
Description
Transcript
Cassandra の概要
KIM ROSS Kim Ross：ス ケーラビリティ の課題がある サーバーサイ ドの Java アプ リケーションを 専門とする開発 者。テクノロジー に情熱を注ぎ、 業界の最新の開 発手法の調査に 熱心。 2002 年より Java による開発 に関わり、フロ ントエンド・シ ステムとバック エンド・システ ムの両面におい て豊富な開発経 験を持つ。 Big Data and Java A pache Cassandra は、デー タ分散機能を備え、線形ス ケーラビリティがあり、一貫性レ ベルを調整できる NoSQL 永続化 ソリューションです。高可用性と 大容量への対が求められるアプ リケーションに非常に適していま す。Cassandra は Facebook によっ て開発され、2008 年にオープン ソース化されたのですが、元々 は Bigtable および Dynamo に関 するホワイト・ペーパーの影響を 受けています。Cassandra のパー ティションとレプリケーションの考 え方は Dynamo を参考としてい ます。一方、Cassandra のログ構 造型の「カラム・ファミリ」デー タ・モデルは Bigtable とよく似 ています。このデータ・モデルで は、スキーマは使用せずに、デー タとそのデータに関連するキー が保存されます。Cassandra は、 Netflix、eBay、Twitter、reddit など、オンライン業界における多 数の有力企業によって使用されて います。 利点 Cassandra をストレージ・ソリュー ションとして選択することには多 くの利点がありますが、そのうち 特に魅力的なのが実行速度です。 著者の Kim Ross が、ソーシャル・ゲームの新興企 業における特定のユースケースで Cassandra が適し ていた理由について説明します。 ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014 Cassandra は、書込み速度が非 常に優れていることで知られてい ますが、読込みの速さも他に負 けません。さらに、高可用性も持 ち合わせています。非集中型の ピアツーピア・アーキテクチャを 採用し、シングル・ポイント障害 となり得るマスター・コンポーネ ントは存在しません。そのため、 特に複数のデータセンターにわ たってノードを配置する場合に、 フォルト・トレランスが非常に高 くなります。 また、Cassandra は停止時間 なく線形的にスケーリングします。 つまり、x 台のノードが y 個のリ クエストに対して必要な場合に は、2x 台のノードで 2y 個のリク エストに対応できます。バージョ ン 1.2 での仮想ノードの導入によ り、容量増加時に通常起こる負 荷増大はすべてのノードに分散さ れ、負荷が高い状態でのスケーリ ングは問題となりません。スケー ルアップもスケールダウンも非常 に簡単です。 ほかにも、柔軟性という利点が あります。この柔軟性は、アプリ ケーションのニーズに応じて各リ クエストの一貫性レベルを調整で きることから実現されます。 Cassandra には、Netflix や Twitter といった有力企業を含む 活発なコミュニティがあり、この コミュニティによりオープンソー ス・ライブラリが提供されていま す。Cassandra は現在も活発に開 発が進められているため、更新 は頻繁に行われ、多くの改善が 実施されています。 欠点 適切なユースケースに対して使用 する場合、Cassandra は非常に効 果的で多くの利点をもたらします が、万能薬ではありません。 リレーショナル・データベース 関連の経歴を持つ開発者にとって 最大の課題となるのが、特にトラ ンザクションにおいて、ACID 特性 （原子性、一貫性、独立性、永 続性）が欠如していることです。 ACID 特性は、これまで多くの開 発者が頼ってきた考え方であるか らです。このような ACID 特性の 欠如は Cassandra 特有の問題で はなく、分散データ・ストア共通 の副作用となっています。開発 者が効果的なデータ・モデルを 設計するためには、保存される JAVA TECH Cassandra をストレージ・ソリューションとして選択することで得られる多くの利点について ABOUT US Cassandra の概要 JAVA IN ACTION COMMUNITY //java architect / blog 34 ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014 Keyspace row key 2 Column name value time stamp name value time stamp Column Column name value time stamp name value time stamp ... ... ... JAVA TECH row key 1 Column JAVA IN ACTION Column Family 図1 NetworkTopologyStrategy では、デー タセンターごとにレプリケーション・ファ クタを指定します。そのため、複数の データセンターにわたってデータがレプ リケートされ、1 つのデータセンター全 体が停止したとしても可用性を確保でき ます。 データ構造 キースペースとは、カラム・ファミリが 定義される名前空間のことであり、概念 的にはデータベースに相当します（図 1）。レプリケーション・ファクタおよび レプリケーション戦略はキースペース・ レベルで定義されます。 カラム・ファミリは複数の行で構成さ れます。各行には行キーによるインデッ クスが付けられ、各行はカラムのコレク ションで構成されます。各カラムは、カ ラム名、値、タイムスタンプで構成され ます。ここで注意すべき点として、各行 に格納できるのは、完全に一意のカラ ムのコレクションです。 1 行におけるカラムの順序は重要で す。最適なパフォーマンスを実現するた めには、互いに近くにあるカラムを一緒 に読み取ってディスクのシーク時間を最 小限に抑える必要があります。カラムの 順序と各カラム名のデータ型は、コンパ レータによって指定します。また、各カ ラムの値のデータ型はバリデータによっ て指定します。カラムが自動的に有効 期限切れになるように、カラムに有効 期限（TTL）を設定することも可能です。 TTL の期間が過ぎた後のカラムは自動 的に削除されます。 また、特殊なカラム型やカラム・ファ ミリ型がいくつかあります。「Counter」 ABOUT US データの内容だけではなく、そのデー また、Cassandra では、運用のため タの発生頻度やアクセス・パターンに の管理作業は少なく、1 週間に 1 回程度、 ついても慎重に検討する必要がありま リペアを確実に実行するだけで済みま す。データ・アクセスを効率化するため す。リペアによって、該当するすべての に、通常は、読取り方法に準じて複数 ノードで、すべてのデータが確実に同 のカラム・ファミリにデータを書き込み 期されます。 ます。このような非正規化は、パフォー マンス向上の目的でよく利用される一方 構造 で、該当するすべての場所にあるデー 次に、Cassandra の構造について確認 タを確実に更新するという新たな責任 します。データは複数のノード内に保 を開発者に課すことになります。デー 存され、複数のノードにレプリケートさ タ・モデルの考察が足りず、アクセスの れます。ノードという言葉は、かつて 仕方が悪い場合は、実行速度が非常に は Cassandra インスタンスをホストする 低下します。必要なデータ・アクセス方 サーバーを指していました。しかし、仮 法（たとえば分析システムの場合に、ど 想ノードの導入により、現在は 1 台の のような状況で古いデータに関する新 サーバーに複数の（仮想）ノードが搭 しいビューが必要になるか）がわから 載されます。また、データを重複して保 ない場合は、Cassandra を Hadoop な 存するノードの個数は、レプリケーショ どの MapReduce テクノロジーと組み ン・ファクタと呼ばれます。ノードは 1 合わせる必要があります。 つのトークン・リングに沿っ Cassandra は、既知のキー て分散され、トークン・リ 大容量に対応 を使用して特定のデータに ング上のどのノードにデー Cassandra は、データ アクセスするという状況に タを保存するかは、キー 分散機能を備え、線形 もっとも適しています。 のハッシュによって決定さ スケーラビリテ ィがあ Cassandra は比較的新し れます。 いテクノロジーであり、非 Cassandra ではさまざ り、一貫性レベルを調 常に安定してはいるものの まなレプリケーション戦 整できる NoSQL 永続化 未熟であるため、経験豊 略を使用できます。レプ 富な人材を見つけることが リケーション戦略とスニッ ソリューションです。高 困難です。しかし、情報は チの組み合わせによって、 可用性と大容量への対 豊富にあり、各種カンファ データのレプリケート先が 応が求められるアプリ レンスのビデオがオンライ 決定されます。スニッチ ンで公開されているため、 は、ノードに関する情報 ケーションに非常に適 Cassandra のスキルは容易 を調査します。その後、こ しています。 かつ迅速に習得できます。 の情報をレプリケーション そのため、未熟であるとい 戦略が利用して、データ う理由でやる気を失うこと を適切なノードにレプリ はありません。 ケートします。たとえば、 COMMUNITY //java architect / blog 35 row key 1 Super 2 Subcolumn 1 Subcolumn 2 Sub 1 Sub 2 Sub 3 value value value value value ... ... JAVA IN ACTION Supercolumn name 1 home Person 2 street city postcode Baker Street London EC1 4GA ... JAVA TECH ... 図2 name1part1:part2 name2part1:part2 ... row key 1 value value home:street home:city home:postcode ... Person 2 Baker Street London EC1 4GA ABOUT US カラム・ファミリはカウンタ・カラムの ポジット・カラムを使用すれば、カラム みで構成されます。カウンタとは 64 ビッ を任意の深さにまでネストできます。こ トの符号付き整数であり、原子的なイ の任意の深さへのネスト機能があるこ ンクリメント操作やデクリメント操作を と、および Cassandra の初期バージョ 実行できるため便利です。カウンタ・カ ンではスーパーカラムよりもコンポジッ ラムに対して実行できる操作はほかに、 ト・カラムの方がパフォーマンスに優れ 読取りと削除しかありません。カウンタ・ ていたことから、現在はスーパーカラム カラムは、カラムのデータに対して原子 ではなくコンポジット・カラムが、ネス 的な操作を実行できる唯一のカラム型 トされたデータの標準形式となっていま です。そのため、データが一貫性レベル す。 「ONE」で書き込まれない限り、カウン タ・カラムのインクリメントには通常の 削除操作の分散 カラムの更新よりも時間がかかります。 削除操作の分散には難しい問題が伴い スーパーカラム・ファミリに格納でき ます。仮に、Cassandra がデータを単 るのはスーパーカラムのみです。スー 純に削除するとすれば、削除操作がす パーカラムとはカラムのカラムのことで べてのノードに伝播されない可能性が す。ネストされたデータを格納できま あります（停止中のノードがある場合な す（図 2）。たとえば、「home」スー ど）。その場合にリペアを実行すれば、 パーカラムであれば、「street」、「city」、 削除されなかったデータが最新のデー 「postcode」などのカラムで構成され タと見なされ、該当するノードに再度レ るでしょう。スーパーカラムには、ネス プリケートされるため、削除されたデー ト可能なレベルが 1 つの タが復活してしまいます。 線形スケーラビリテ ィ みという制限があります。 そのため、Cassandra Cassandra は、スケーラ さらに動的なネストが必要 では、データを削除する な場合は、コンポジット・ のではなく、 トゥームストー ブルかつ大容量のデー カラムを使用する必要が ンによりマークします。リ タ・ス トアが必要な場合 あります。 ペアを実行すると、トゥー コンポジット・カラムと ムストーンでマークされた に使用できる優れたツー は、カラム名が重複のな データが最新のデータと ルです。ほとんど負荷の い複数のコンポーネントで 見なされます。そのため、 コストをかけずに線形ス 構成される通常のカラム 削除操作の実行時に停止 のことです（図 3）。これ していたノードに対して、 ケーラビリティを確保で らの名前に対して部分一 そのトゥームストーンがレ きるため、トラフィック 致の問合せを実行できま プリケートされます。 す。順序を保証するため トゥームストーンとその が急増したときにも問題 に、コンパレータのコンパ 関連データは、デフォル なく対応できます。 レータを使用します。コン トでは 10 日後、コンパク COMMUNITY //java architect / ... 図3 ション処理中に削除されます。したがっ て、リペア（手動プロセス）の実行頻 度をコンパクション処理（通常は週に 1 回）よりも高くして、トゥームストーンが クリーンアップされる前に、該当するす べてのノードにレプリケートされるよう にすることが重要です。 一貫性 Cassandra は一貫性レベルを調整でき るにもかかわらず、よく「結果整合性を 持つデータ・ストア」と表現されます。 データベースは、読取り操作により確実 に最新のデータが返される場合に一貫 性があると見なされます。 注：Cassandra を使用する際に重要 になるのが、CAP 定理を理解すること です。CAP 定理にあるとおり、一貫性、 可用性、分断耐性の 3 つの要素のうち、 同時に実現できるのは最大 2 つです。 blog 36 ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014 ORACLE.COM/JAVAMAGAZINE ///////////////////// JANUARY/FEBRUARY 2014 まとめ Cassandra は、スケーラブルかつ大容 量のデータ・ストアが必要な場合に使 用できる優れたツールです。ほとんど 負荷のコストをかけずに線形スケーラビ リティを確保できるため、トラフィック が急増したときにも問題なく対応できま す。 短期間で稼働状態まで設定することも 比較的簡単ですが、データを適切にモ デリングできるように、アクセス・パター ンを把握する時間をかける必要がありま す。Cassandra には、詳細調査を行う 十分な価値があります。そうすることで、 最適な利用パターンについて良い情報 が得られるためです。今日の増え続ける データの要件を考慮すれば、Cassandra はあらゆる開発者がツールキットに加え JAVA IN ACTION るべき価値あるツールと言えます。</ article> JAVA TECH インタフェースを使用して、データ・ス トアに直接アクセスできます。cqlsh で は、SQL と非常によく似た CQL 言語に よるコマンドを実行できます。しかし、 構文上似ているからと言って、バックグ ラウンドの処理も同じであると思い込ま ないようにしてください。 Java（およびその他の言語）から Cassandra にアクセスするための各種 ライブラリが存在します。たとえば、 Datastax が開発した、CQL を受け入れ る Java ドライバがあります。このドライ バの開発以前は、Thrift API を経由する しか Java から Cassandra にアクセスす る方法はありませんでした。Thrift API をサポートするライブラリは数多くあり、 Hector、Astyanax がその一部です。現 在は、Thrift API と Java ドライバの両方 がサポートされます。 MORE ON TOPIC: Big Data and Java LEARN MORE •『Cassandra Data Modeling Best Practices, Part 1』 ABOUT US データの書込みまたは読取りの際に のデータをノード B とノード C から読み は、データ・リクエストのたびに一貫 取るとします。この場合、Cassandra は 性レベルを設定できます。一貫性レ データに関連付けられたタイムスタンプ ベルには、「ONE」、「TWO」、「ALL」、 を利用して、最新のデータがノード B に 「QUORUM」などがあります。 あると判断し、そのデータを返します。 ここで、レプリケーション・ファクタが 一貫性レベル「QUORUM」では一貫性 3 の例を考えます。一貫性レベル「ONE」 が確保されるのに加え、1 つのノードが で書込みや読取りを行う場 停止状態になってもリクエ 合は、読取りを行うノード ストには影響を及ぼしませ 卓越した速度 が、それまでに発生してい ん。 Cassandra をスト た書込み操作による更新が 一貫性レベルが「ALL」 レージ・ソリ ュー 行われておらず、古いデー の場合、読取りと書込み タが読み取られる可能性が の一貫性は確保されます ションとして選択す あります。レベル「ONE」 が、1 つのノードが停止状 ることには多くの利 で書き込む場合、データ 態に陥った状況を処理で 点がありますが、そ きません。また、覚えて が 1 つのノードにのみ書 き込まれるという意味では おくべきこととして、指定 のうち特に魅力的 ないことに注意してくださ した一貫性レベルを達成 なのが実行速度で い。Cassandra は常に、該 するためにアクセスする必 当するすべてのノードへの す。Cassandra は、 要のあるノード数が増える 書込みを試みます。レベル ほど、Cassandra の処理 書込み速度が非常 「ONE」が意味することは、 速度は低下します。レプリ 1 つのノードへの書込みが に優れていることで ケーション・ファクタを 3 と 成功した直後に、操作の制 した場合に、一貫性レベ 知られていますが、 御が返されるということで ル「QUORUM」で読取り 読込みの速さも他 す。 を行うと、実行速度は最速 一貫性レベル から 2 番目のノードと同一 に負けません。 「QUORUM」は、 レプリケー になります。一方、一貫性 ション・ファクタの 2 分の レベル「ALL」の場合は、 1 に 1 を加算したレベルで 実行速度が一番遅いノード す。たとえば、レプリケー の応答を待つ必要がありま ション・ファクタが 3 の場合、 す。そのため、ユースケー QUORUM は 2 になります。 スの一部で古いデータを許容できるか 一貫性レベル「QUORUM」で読取り を検討する価値があります。 や書込みを行った場合は、データ一貫 性が保証されます。たとえば、データが Cassandra へのアクセス ノード A とノード B に書き込まれ、ノー Cassandra には cqlsh というコマンドラ ド C には書き込めなかった場合に、そ イン・インタフェースがあります。この COMMUNITY //java architect / •『Cassandra Data Modeling Best Practices, Part 2』 •『Virtual Nodes in Cassandra 1.2』 blog 37