Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "StorageConfiguration_JP" page has been changed by MakiWatanabe. http://wiki.apache.org/cassandra/StorageConfiguration_JP?action=diff&rev1=69&rev2=70 -------------------------------------------------- = 設定の読み込み = == config-converter == - bin/config-converterはstorage-conf.xmlを可能な限り忠実に[[http://ja.wikipedia.org/wiki/YAML|YAML]]形式に変換します。このツールはあなたのxmlファイルがconf/storage-conf.xmlに配置されており、また出力先がconf/cassandra.yamlであることを想定しています。ただし、0.7において多くのプロパティのスコープが変更されたため（例えば、endpoint_snitchはKS単位ではなくグローバルスコープに、gc_grace_secondsはグローバルからKeyspace単位に変わっています）、自動生成されたyamlファイルは使用前に必ず精査してください。 + bin/config-converterはstorage-conf.xmlを可能な限り忠実に[[http://ja.wikipedia.org/wiki/YAML|YAML]]形式に変換します。このツールはあなたのxmlファイルがconf/storage-conf.xmlに配置されており、また出力先がconf/cassandra.yamlであることを想定しています。ただし、0.7において多くのプロパティのスコープが変更されたため（例えば、endpoint_snitchはKS単位ではなくグローバルスコープに、gc_grace_secondsはグローバルからKeyspace単位に変わっています）、自動生成されたyamlファイルは使用前に必ず精査してください。 == -Dcassandra.config == - Cassandraの起動時に、Java VMのパラメータとして渡すことにより、任意の設定ファイルをロードすることができます。具体的には、''-Dcassandra.conf=<your value here>''という形式でパラメータを与えます。値にはclasspath上のファイル、ローカル又はリモートのURLを指定できます。幾つかの例を次に示します： + Cassandraの起動時に、Java VMのパラメータとして渡すことにより、任意の設定ファイルをロードすることができます。具体的には、''-Dcassandra.conf=<your value here>''という形式でパラメータを与えます。値にはclasspath上のファイル、ローカル又はリモートのURLを指定できます。幾つかの例を次に示します： - ||'''Value''' ||'''Implication''' || + ||'''値''' ||'''意味''' || - ||''-Dcassandra.config=alternate-cassandra.yaml'' ||cassandraのclasspath上に ''alternate-cassandra.yaml'' があればそれをロードします。 || + ||''-Dcassandra.config=alternate-cassandra.yaml'' ||cassandraのclasspath上に ''alternate-cassandra.yaml'' が存在すればそれをロードします。 || ||''-Dcassandra.config=http://www.example.com/remote-cassandra.yaml'' ||リモートホストから設定ファイルをロードします。 || ||''-Dcassandra.config=file:///home/me/external-local-cassandra.yaml'' ||cassandraのclasspath上にないローカルの設定ファイルをロードします。 || @@ -21, +21 @@ == "私のkeyspaceはどこ?" == - LiveSchemaUpdates。次のコマンドでスキーマを一度にロードすることができます。: + LiveSchemaUpdates。次のコマンドでスキーマを一度にロードすることができます。: {{{ bin/schematool HOST PORT import }}} = 設定の概要 = - ここでは重要な設定項目にのみ絞って解説し、すべての設定値についてはカバーしません。疑問があれば、標準のcassandra.yamlに豊富に記述されているコメントを確認してください。 + ここでは重要な設定項目にのみ絞って解説し、すべての設定値についてはカバーしません。疑問があれば、標準のcassandra.yamlに豊富に記述されているコメントを確認してください。 == クラスタ単位（グローバル）の設定 == * '''authenticator''' - プラグイン可能なユーザ認証を指定します。ここではThriftの'login'メソッド呼び出しの必要性の有無、またログイン時に必要なパラメータについて定義します。デフォルトの'!AllowAllAuthenticator'を使用した場合、ユーザは'login'メソッドを呼ぶ必要がありません。即ち、すべてのユーザが任意の捜査を実行可能です。他のビルトインのオプションには'!SimpleAuthenticator'があります。このユーザ認証設定ではユーザはloginを呼び出す必要があり、プロパティファイルに設定されたユーザ名とパスワードが必要になります。 + プラグイン可能なユーザ認証を指定します。ここではThriftの'login'メソッド呼び出しの必要性の有無、またログイン時に必要なパラメータについて定義します。デフォルトの'!AllowAllAuthenticator'を使用した場合、ユーザは'login'メソッドを呼ぶ必要がありません。即ち、すべてのユーザが任意の捜査を実行可能です。他のビルトインのオプションには'!SimpleAuthenticator'があります。このユーザ認証設定ではユーザはloginを呼び出す必要があり、プロパティファイルに設定されたユーザ名とパスワードが必要になります。 || プロパティ名 || デフォルト値 || || `authenticator` || `org.apache.cassandra.auth.AllowAllAuthenticator` || @@ -41, +41 @@ * '''auto_bootstrap''' - seedノード以外の新規ノードについて、この設定を'true'に指定して起動することにより、そのノードは自動的に適切なデータをレプリケートします。（InitialTokenが指定されていない場合、追加されたノードは最も収容量の多いノードの半分のTokenレンジを引き受けます。）ブートストラップなしでノードを起動した場合、以降のブートストラップの際に誤って使用されないように、自分自身をブートストラップ済みとしてマークします。（データとcommitlogディレクトリを削除すればリセットできます。） + seedノード以外の新規ノードについて、この設定を'true'に指定して起動することにより、そのノードは自動的に適切なデータをレプリケートします。（InitialTokenが指定されていない場合、追加されたノードは最も収容量の多いノードの半分のTokenレンジを引き受けます。）ブートストラップなしでノードを起動した場合、以降のブートストラップの際に誤って使用されないように、自分自身をブートストラップ済みとしてマークします。（データとcommitlogディレクトリを削除すればリセットできます。） - 既にデータが格納されているクラスタに新しいノードを追加する場合は、これを'true'に設定すべきです。 + 既にデータが格納されているクラスタに新しいノードを追加する場合は、これを'true'に設定すべきです。 || プロパティ名 || デフォルト値 || || `auto_bootstrap` || `false` || * '''cluster_name''' - クラスタの名称です。ノードが誤って他の論理クラスタに参加しないようにするために使用されます。 + クラスタの名称です。ノードが誤って他の論理クラスタに参加しないようにするために使用されます。 * '''commitlog_directory'''、'''data_file_directories'''、'''saved_caches_directory''' - できるだけcommitlog用のディスクとデータ格納用のディスクは分けてください。commitlogの性能は「追記のみ」という動作に依存しており、データに対するランダムアクセスと混在させた場合書き込み性能に悪影響を与えます。'saved_caches_directory' にはカラムファミリの 'savedキャッシュ' が保存されます。詳しくは 'key/row_cache_save_period_in_seconds' を参照してください。 + できるだけcommitlog用のディスクとデータ格納用のディスクは分けてください。commitlogの性能は「追記のみ」という動作に依存しており、データに対するランダムアクセスと混在させた場合書き込み性能に悪影響を与えます。'saved_caches_directory' にはカラムファミリの 'savedキャッシュ' が保存されます。詳しくは 'key/row_cache_save_period_in_seconds' を参照してください。 || プロパティ名 || デフォルト値 || || `commitlog_directory` || `/var/lib/cassandra/commitlog` || @@ -62, +62 @@ * '''concurrent_reads''' and '''concurrent_writes''' - 多くのシステムと異なり、CassandraではReadよりWriteのほうが速いため、より多くのWriteを並列に実行できます。経験則に従えば、一つのプロセッサコアごとにconcurrent_readsを4つづつ増やせばよいと思います。Write性能が問題になるまで'concurrent_writes'はいじらないほうがいいでしょう。とはいえ、一般的にはCassandraクラスタ専用環境ではリングのCPUコア数の合計以上の値にするとよいでしょう。 + 多くのシステムと異なり、CassandraではReadよりWriteのほうが速いため、より多くのWriteを並列に実行できます。経験則に従えば、一つのプロセッサコアごとにconcurrent_readsを4つづつ増やせばよいと思います。Write性能が問題になるまで'concurrent_writes'はいじらないほうがいいでしょう。とはいえ、一般的にはCassandraクラスタ専用環境ではリングのCPUコア数の合計以上の値にするとよいでしょう。 || プロパティ名 || デフォルト値 || || `concurrent_reads ` || `8` || @@ -70, +70 @@ * '''commitlog_rotation_threshold_in_mb'''、'''commitlog_sync'''、'''commitlog_sync_period_in_ms'''、 '''commitlog_sync_batch_window_in_ms''' - commitlog_rotation_threshold_in_mb はどのくらいの頻度で新しいcommitlogセグメントが生成されるかを決定します。一般的にはこの値を変更すべきではありませんが、この値を小さくすると僅かではありますがシステムのメモリ使用量を節約できます。 + commitlog_rotation_threshold_in_mb はどのくらいの頻度で新しいcommitlogセグメントが生成されるかを決定します。一般的にはこの値を変更すべきではありませんが、この値を小さくすると僅かではありますがシステムのメモリ使用量を節約できます。 - CommitLogSync には periodic か batch を指定できます。batchモードではCassandraはcommitlogがfsyncされるまでwrite ackを返しません。CommitLogSyncBatchWindowInMS ミリ秒の間他のwriteが到着するのを待ったあと、fsyncを実行します。 + CommitLogSync には periodic か batch を指定できます。batchモードではCassandraはcommitlogがfsyncされるまでwrite ackを返しません。CommitLogSyncBatchWindowInMS ミリ秒の間他のwriteが到着するのを待ったあと、fsyncを実行します。 - Cassandraはwriteを複数のノードに対して実施するため「writeしたデータが物理的にディスクに格納される前」の障害でデータが失われる危険性は実際には一般的なデータベースほど顕著ではありません。もう一つのオプション'periodic'を選択するとwriteに対して直ちにackを返します。CommitLog は単純にCommitLogSyncPeriodInMs ミリ秒ごとにfsyncされます。通常はデフォルト値の1000msで問題ないでしょう。JMXでCommitLog PendingTasksを監視して、一つのsyncが完了する前に次のsyncが発生する状況が多発しているようであればこの値を増やすことを検討してください。 + Cassandraはwriteを複数のノードに対して実施するため「writeしたデータが物理的にディスクに格納される前」の障害でデータが失われる危険性は実際には一般的なデータベースほど顕著ではありません。もう一つのオプション'periodic'を選択するとwriteに対して直ちにackを返します。CommitLog は単純にCommitLogSyncPeriodInMs ミリ秒ごとにfsyncされます。通常はデフォルト値の1000msで問題ないでしょう。JMXでCommitLog PendingTasksを監視して、一つのsyncが完了する前に次のsyncが発生する状況が多発しているようであればこの値を増やすことを検討してください。 || プロパティ名 || デフォルト値 || || `commitlog_rotation_threshold_in_mb ` || `128` || @@ -83, +83 @@ * '''disk_access_mode''' - 0.7ではデフォルト値の 'mmap_index_only' が推奨値です。バージョン0.6ではデフォルト値は 'auto' ですが、'standard' に設定した方がいいでしょう。これ以外は[[http://issues.apache.org/jira/browse/CASSANDRA-1214|discussion in CASSANDRA-1214]]を読み、あなたの環境の[[MemtableThresholds|スワップとVM設定]]を確認するまで、この設定に触らないでください。 + 0.7ではデフォルト値の 'mmap_index_only' が推奨値です。バージョン0.6ではデフォルト値は 'auto' ですが、'standard' に設定した方がいいでしょう。これ以外は[[http://issues.apache.org/jira/browse/CASSANDRA-1214|discussion in CASSANDRA-1214]]を読み、あなたの環境の[[MemtableThresholds|スワップとVM設定]]を確認するまで、この設定に触らないでください。 * '''dynamic_snitch''' and '''endpoint_snitch''' - '''endpoint_snitch''': このプロパティに {{{IEndPointSnitch}}} を実装したクラスを指定することにより、2つのノードが同じデータセンターに存在するか、あるいは同じラックに収容されているかの判定条件を制御できます。Cassandraパッケージの{{{org.apache.cassandra.locator}}}以下に4種類のSnitchが標準で添付されています。 + '''endpoint_snitch''': このプロパティに {{{IEndPointSnitch}}} を実装したクラスを指定することにより、2つのノードが同じデータセンターに存在するか、あるいは同じラックに収容されているかの判定条件を制御できます。Cassandraパッケージの{{{org.apache.cassandra.locator}}}以下に4種類のSnitchが標準で添付されています。 a. {{{org.apache.cassandra.locator.SimpleSnitch}}} 何もしません。 a. {{{org.apache.cassandra.locator.RackInferringSnitch}}} IPアドレスの第2オクテットがデータセンター、第3オクテットがラックに対応すると仮定して判定します。 a. {{{org.apache.cassandra.locator.PropertyFileSnitch}}} cassandra-topology.propertiesに明示的に設定された近傍定義（proximities）に従います。 a. {{{org.apache.cassandra.locator.Ec2Snitch}}} Amazon EC2ノードからリージョンとゾーンを読み取り、それらをデータセンターとラックと見なします。あなたの環境をEC2で動かしていない場合には使用しないでください。 - '''dynamic_snitch''': 上記のsnitchをdynamic snitchでラッピングするかどうかを指定するbooleanです。dynamic snitchは対向ノードの読み込み遅延を監視し、遅いノードからの読み出しを避けます。 + '''dynamic_snitch''': 上記のsnitchをdynamic snitchでラッピングするかどうかを指定するbooleanです。dynamic snitchは対向ノードの読み込み遅延を監視し、遅いノードからの読み出しを避けます。 || プロパティ名 || デフォルト値 || || `endpoint_snitch` || `org.apache.cassandra.locator.SimpleSnitch` || @@ -103, +103 @@ * '''listen_address''' - このプロパティをコメントアウトすると{{{InetAddress.getLocalHost()}}}が使用されます。ノードのネットワーク設定が正しければこれでうまく動きます。（hostnameに紐づいたアドレスを使用します。）クラウドサービス上でシステムを構築する場合は正しいインターフェースを明示的に指定した方がいいでしょう。 + このプロパティをコメントアウトすると{{{InetAddress.getLocalHost()}}}が使用されます。ノードのネットワーク設定が正しければこれでうまく動きます。（hostnameに紐づいたアドレスを使用します。）クラウドサービス上でシステムを構築する場合は正しいインターフェースを明示的に指定した方がいいでしょう。 || プロパティ名 || デフォルト値 || || `listen_address` || `localhost` （他のホストからこのノードにアクセスする為には、この値を変更する必要があります。）|| * '''memtable_flush_after_mins'''、'''memtable_operations_in_millions'''、'''memtable_throughput_in_mb''' - '''memtable_flush_after_mins''': ダーティなmeltableがフラッシュされずにいる最大時間（分）です。（影響するカラムファミリについてcommit logから読みこんでからフラッシュしていないデータが存在する限り、そのcommit logセグメントは削除できません）この値が小さすぎると、サイズやカウントのスレッショルドに到達する前に同時にmemtableのフラッシュが発生してしまいます。本番環境では大きな値、例えば1440程度がおすすめです。 + '''memtable_flush_after_mins''': ダーティなmeltableがフラッシュされずにいる最大時間（分）です。（影響するカラムファミリについてcommit logから読みこんでからフラッシュしていないデータが存在する限り、そのcommit logセグメントは削除できません）この値が小さすぎると、サイズやカウントのスレッショルドに到達する前に同時にmemtableのフラッシュが発生してしまいます。本番環境では大きな値、例えば1440程度がおすすめです。 - ’’’memtable_operations_in_millions’’’: memtableをディスクにフラッシュする前にカラムファミリに格納可能な最大のカラム数を100万を単位として指定します。これもmemtableごとの設定になります。メモリ使用量を調整するには{{{MemtableSizeInMB}}}を使用してください。 + '''memtable_operations_in_millions''': memtableをディスクにフラッシュする前にカラムファミリに格納可能な最大のカラム数を100万を単位として指定します。これもmemtableごとの設定になります。メモリ使用量を調整するにはMemtableSizeInMBを使用してください。 - '''memtable_throughput_in_mb''': memtableをディスクにフラッシュする前にカラムファミリに格納可能な最大のデータサイズをMB単位で指定します。memtableはカラムファミリごとに用意されます。この閾値は単純に格納されたデータサイズにのみ依存し、実際のヒープメモリの使用量を基準にはしていません。（カラムのインデックスを作成するため、メモリサイズ上いくらかのオーバーヘッドが発生します。）併せてMemtableThresholdsを参照してください。 + '''memtable_throughput_in_mb''': memtableをディスクにフラッシュする前にカラムファミリに格納可能な最大のデータサイズをMB単位で指定します。memtableはカラムファミリごとに用意されます。この閾値は単純に格納されたデータサイズにのみ依存し、実際のヒープメモリの使用量を基準にはしていません。（カラムのインデックスを作成するため、メモリサイズ上いくらかのオーバーヘッドが発生します。）併せてMemtableThresholdsを参照してください。 - memtable_operations_in_millionsもmemtable_throughput_in_mbもデフォルト値はブート時のヒープ割当によって決まります。 + memtable_operations_in_millionsもmemtable_throughput_in_mbもデフォルト値はブート時のヒープ割当によって決まります。 || プロパティ名 || デフォルト値 || || `memtable_flush_after_mins ` || `60` ||
