2011/10/11

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


Part 1に続き、Part 2です。


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

今回は後半部分を日本語訳で紹介いたします。

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


What is leveled compaction and what kinds of workloads does it help? 
レベル・コンパクションとは何でしょうか? どういったワークロードを助けるのでしょう? 
手短な回答としては、レベル・コンパクションは、(新しい行を挿入することに反して)同一行へ多くの更新も含め、読み出しが多いワークロードに対してより良い性能を発揮します。 もう少し長い回答としては、ブログを書く必要があります。それまでの間、CassandraサミットのLightning TalksでBen Coverston氏がレベルコンパクションに関して説明したスライドとビデオがこちらにありますので参照して下さい。

What management tools are there for performance tuning and recovery? 
性能チューニングと復旧のために、どのような管理ツールがありますか?
 DataStax’s OpsCenter は、クラスター管理と監視に注力しています。
これは、キャッシュサイジングやi/oキャパシティのようなハイ・レベルの性能チューニングに役立ちます。バックアップとリストアの管理はロードマップに載っています。 ロー・レベルの性能チューニングのためには、AppDynamicsやdynaTraceといったものが役立つでしょう。

Does Cassandra offer Hadoop integration? 
CassandraはHadoop統合を提供しますか? 
 はい。Cassandraは、基本的なmap/reduce、Pig、Hiveによる読み書きをサポートしています。DataStaxも、DataStax Enterpriseを提供しており、これは、別個にHDFS、ジョブ・トラッカー、タスク・トラッカーやメタストア不要で、同一クラスターにおいてCassandraとHadoopを利用できるプロダクトです。

How do you add and remove nodes in a Cassandra cluster? 
どのようにして、Cassandraクラスターにノードを加えたり、取り除いたりできますか?
 基本的に既存のシードに新しいノードを加えて起動するだけというシンプルさです。DataStaxのドキュメンテーションの、adding capacity (容量追加)のところに内容が記載されています。

What is snapshot used for? 
スナップショットは何に使われるのでしょうか? 
スナップショットは、クラスターのある時点のバックアップを取れるという素晴らしい機能です。
cassandra.yaml内のincremental_backups設定と組みあわせることで、復旧時に最小限のオーバーヘッドとなるように、きめ細かい調整ができます。
 スナップショットは、ハード・リンクを使って実装されており、これはCassandraのログ・ストラクチャード・ストレージエンジンゆえに可能です。これにより、速さと極めて効率的な容量確保の両方を実現しています。
 スナップショットは、他のクラスターにデータをロードするbulk loaderのためにも使われます。たとえば、本物のデータを使って、アプリケーションの新しいバージョンをテストできるといったようなことができます。私たちは、スナップショットデータに対して直接Hadoopクエリを行えるようにすることも計画しています。

What hardware do you recommend for Cassandra deployments? 
Cassandraをデプロイするうえで推奨するハードウェアはありますか? 
 サーバ以外の機材が同じなのであれば、性能の高いマシンを少ない台数用意するよりも、性能の低いマシンを多い台数用意したいところです。これは、ひとつのマシンの障害が全体のキャパシティに与える影響を少なくします。 経験則として、1Uサーバで充分得られるくらいの性能と考えてください。現在では、8コアで32GBのRAMが最適でしょう。 しかし、これは作業量によります。 もし、Hadoopによる分析を多く行う予定ならば、典型的にディスクスペースやi/oに制約されるでしょう。 もし、重い挿入が中心であるならば、CPUに制約されるでしょう。もし、ランダムな読み込みが多いのであれば、磁気ディスクの代わりにSSDを使うべきです。

 What performance tuning advice do you have at the OS, JVM, and Cassandra levels? 
 OS、JVMとCassandraレベルで、性能チューニングに対するアドバイスをお願いします。
 XFSを使用してください。RADI0かRAID10(ディスクスペースに制約があるかによります)を使い、commitlogのために別のスピンドル(又はRAID1で2つ)を残しておいてください。noopやdeadlineスケジューラを使用してください。 Cassandraパッケージは、重要なJVM設定をしっかり設定します。通常、箱から出して唯一変更するとしたら、マシンのRAMの半分がJVMヒープサイズに割当てられるので、大きなマシンを使用する場合は8GBを上限値として設定するとよいでしょう(これは、Cassandra1.0のデフォルト動作になります)。 私たちは、Cassandraがデフォルトの自動設定で高性能に動くよう最善を尽くしました。あなたがインストールしてすぐに変更したいと思うような項目があるとは考えられません。一度何か負荷を掛け始めた後は、キャッシュサイズのチューニングの項キャッシュサイズのチューニングの項が参考になるでしょう。

Are there best practices for running a cluster on Amazon EC2? 
Amazon EC2上のクラスターで動かす際の良い事例はありますか?
 ローカル・ストレージでLかXLのインスタンスを使用してください: I/O性能はSとMサイズでは比例的に悪くなります。EBSはいくつかの理由で悪い組み合わせです(Erik Omnen氏の素晴らしい説明をご覧ください)。 すべてのEphemeral disksをRAID0とし、commitlogとデータの両方をそのボリュームへ置いてください(これは、rootボリュームにcommitlogを置くよりも良いことがテストされています)

How does Cassandra compare to OpenStack? 
CassandraとOpenStackを比較してどう思いますか? 
 これらは全く別物です。Cassandraは、高性能分散型データベースです。OpenStackは、クラウド管理ソフトウェアです。OpenStackのクラウド内にCassandraをデプロイしたり、CassandraをOpenStackに組み込んで、コンフィギュレーションと監視データを格納することはできるかもしれません。しかし、そうでなければ、それらは全く関係ありません。

What considerations are there for running repair in a cluster with a few tens of servers? 
 数十台のサーバーのクラスターでリペアを走らせる際に考慮すべき点は? 
 最も考慮すべきは、repair merkle treesの構築は、(今のところ)かなり重い処理です。そのため、通常は同時にひとつ以上動かさないほうがよいです。ひとつのマシンでリペアを動かし、それが終わったら次を開始してください。 もし、リペアにより性能が悪くなるようであれば、cassandra.yaml内のcompaction_throughput_mb_per_sec設定を減らしてください。