2011/10/07

Questions from the Tokyo Cassandra conference (The Japanese Translation Part 1)

10月5日のCassandra Conference in Tokyoの翌日、10月6日にジェミナイ・モバイル・テクノロジーズに、Apache Cassandraプロジェクトのチェアマンであり、DataStaxの共同設立者であるJonathan Ellisが来訪し、Cassandra Talk Sessionを開催する予定でした。

会議室の関係で参加人数が限定されてはいましたが、参加予定の皆様には、Cassandraに関する質問を事前準備いただいていました。残念ながら、急遽、来日が中止となったことから、以下のブログで質問に対する回答を公開してくれました。

http://www.datastax.com/dev/blog/questions-from-the-tokyo-cassandra-conference#comment-17013

多少長いので、今回は前半部分を日本語訳で紹介いたします。

(以下、翻訳:Followings are the Japanese translations)

Tokyo Cassandra Conferenceに際し、私のほうから事前に質問をお願いしたところ、お蔭様でとても良い質問の数々を受け取ることができました--コンファレンスの枠内だけでは応えきれないほど多くの質問を頂いています。そのため、それらの質問に関する回答を公開しておきます。

How is Cassandra different from other NoSQL databases?
Cassandraは他のNOSQLデータベースとどう違うのですか? 
Cassandraは、性能、拡張性、高可能性における最良の組み合わせを提供します。他の選択肢ではこれらの軸の少なくともひとつは欠けています。

完全分散で単一障害点が無いことによる拡張性と高可用性は、極めて簡単に理解されます。しかし、性能については、もう少し詳細に説明をしたいと思います。

あまり評価されていないCassandraがもつ能力の特徴として、カラムファミリーのデータモデルで、動的なカラムを使えることから、そうでなければJoin(結合)が必要となるような複雑なクエリをさせるためのマテリアライズド・ビューを事前に計算できるという点です。

How does Cassandra deal with network and hardware failure?
Cassandraはネットワークやハードウェア障害にどのように対処しますか? 
Cassandraは、2つの方法で障害に対処します。

まず、そのFAILURE DETECTOR(障害検知)により、ピア・ノードがダウンや接続不可といった障害を検知します。

次に、DYNAMIC SNITCHが、実際にはより難しいタスク(たとえば、ディスク障害のために)性能が劣化しているノード検知した時に他のレプリカにクエリ要求のルーティングを実行します。

Cassandraの堅牢な部分は、マスターも特別なノードも無く、普通に障害に対処します。


What is the roadmap for future Cassandra releases?
将来のCassandraリリースのロードマップは? 
私見ですが、Cassandraのコア部分は現在たいへん優れており、これからは使 い勝手の向上に注力していく時期だと思います。これは、運用面での向上とい うよりも、Cassandra上でアプリケーションをより容易に開発できることを指し ます。

DataStaxが準備を進めているのは、 CQL enhancements、 triggers、entity groups、smarter range queries です。


What important performance considerations are there when deploying across multiple data centers?

複数のデータセンターに展開する際、性能面で考えるべき重要な点は何でしょうか?
重要なことは(データセンターが地理的に離れているとの前提で)、QuorumConsistencyLevel は良いオプションでは無いということです。なぜならば、少なくとも1つのコーディネーターと全てのデータセンターは、クライアントリクエストを取り扱うために他のデータセンターとの間の往復遅延を待たねばならないことが良くあるからです。

妥協点として、CassandraはLOCAL_QUORUMにより同じデータセンター内で他のクライアント との強い整合性を保証できるようにしています。そして、当然のことながら、 ConsistencyLevel.ONE でほぼ十分ではないでしょうか:私はアプリケーション の約60%はもっぱらONEを使うと見込んでいます。

What are your thoughts on strong consistency via R/W=One/All?
R/W=One/Allにおける強い整合性に対しては、どのように考えていますか? 
厳密に言うと:この質問は、読み出しConsistencyLevelをONE、書き込みをALL に設定して如何に強い整合性を得られるか解釈できます。

 私は、これは汎用的な設定として良いとは思いません。なぜなら、いくつかのノードが落ちるとクラスターが書き込み不能になるからです。そのことが、強い整合性が必要な際には、読み出しと書き込みを両方Quorumで実行させる理由です。しかし、それが適切な場合のシナリオも想像できます。たとえば、書き込みは定期的にバルクで書き込み、それ以外のワークロードは読み出しだけという場合です。

Is it possible to use journaling filesystems like XFS or Btrfs? Can you mix different filesystems across different machines in a cluster?
XFSやBtrfsのようなジャーナリングファイルシステムを使うことは可能ですか? クラスター内で異なるマシーンをまたがり、異なるファイルシステムを混在できますか? 
イエス、イエスです。最近、DataStaxはCassandraにXFSを推奨しています。ついでながら、私はBtrfsの性能改善の報告を聞いていますが、それがもう少し安定するまで、Btrfsの商用利用は慎重に考えたいと思います。

ファイルシステムの選択はマシン固有です。言うならば、クラスターの他のマシンが何のファイルシステムか判りませんし、何であろうと構いません。Cassandraはひとつのクラスターで異なるオペレーティングシステムの混在はサポートしません。たとえば、WindowsクラスターやLinuxクラスターはできますが、Windows/Linuxクラスターはできません。

私は、試験環境で異なるファイルシステムをテストすることは良いですが、商用環境におけるベストプラクティスは、異常を調べる際に、トラブルシュートが必要なところを絞り込むために、できるだけ物事を同一にしておくことに気を配ります。


Does Cassandra support multiple storage devices per server?

Cassandraは、サーバー毎に複数のストレージデバイスをサポートしますか? 
はい。Cassandraは、cassandra.yamlに複数のdata_file_directories を指定できます。
しかし、JBODコンフィグレーションよりも、RAID0 かRAID10 が推奨されます。

Can you give an example of troubleshooting a Cassandra cluster?
Cassandraクラスターをトラブルシューティングする事例紹介をお願いできますか? 
数ヶ月前、あるお客様で、ディスクスペースが一杯になってしまった1つのCassandraのノードがありました。ファイルシステムを調べると、スペースの大部分がcommitlogセグメントにより占められていることがわかりました。

私たちには、調べることが2点ありました。何故、このノードは、クラスターの他よりも高いレベルの書き込み量を扱っていたのか?、そして、何故、期待されているようにcommitlogセグメントは消去されなかったのか?

最初に私達が行ったことは、Cassandraのlogファイルの確認です。それは、予想外に高い書き込みデータ量がありましたが、それ以外に異常はありませんでした。クラスターの他のノードのログを観ると、それらの多くで、書き込み量が最高に到達する前に、hinted handoffを実行し始めていることが疑わしく見えました。

お客様に確認すると、この前の間に、そのノードはダウンしていました。クラスターの他に対して高い書き込み負荷を続けており、ノード復旧の際に送られてくる大量のヒント(hints)があるということは、納得できます。

しかし、commitlogセグメントが消去されないのは何故でしょうか? 私たちは、お客様にcommitLogクラスのデバッグロギングを有効にしてもらいました。そこで、memtableがフラッシュするに充分な大きさが無い、セグメント毎にわずかな書き込みだけを受け付けた少量のカラムファミリーがあったことが分かりました。フラッシュされないデータが残っていることで、commitlogセグメントは消去されなかったのです。

私たちは、お客様に対して、より頻繁にそれらをフラッシュするように、memtable_flush_after_mins設定 を少量のカラムファミリーにすることを推奨しました。また、ヒント(hints)リプレイが過剰にならないようにmax_hint_window_in_ms設定を減らすことを推奨しました。

最終的に、私達は、将来、この問題を容易に回避できるよう、memtable_flush_after_minsをcommitlog_total_space_in_mbに取り替えるという問題定義(管理番号)を設けました。このフィーチャーは、Cassandra1.0から利用可能になります。

・・Part2に続く。