cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Trivial Update of "StorageConfiguration_JP" by MakiWatanabe
Date Tue, 08 Feb 2011 14:26:10 GMT
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=66&rev2=67

--------------------------------------------------

  
  プラグイン可能なユーザ認証を指定します。ここではThriftの'login'メソッド呼び出しの必要性の有無、またログイン時に必要なパラメータについて定義します。デフォルトの'!AllowAllAuthenticator'を使用した場合、ユーザは'login'メソッドを呼ぶ必要がありません。即ち、すべてのユーザが任意の捜査を実行可能です。他のビルトインのオプションには'!SimpleAuthenticator'があります。このユーザ認証設定ではユーザはloginを呼び出す必要があり、プロパティファイルに設定されたユーザ名とパスワードが必要になります。
  
- デフォルト値: 'org.apache.cassandra.auth.AllowAllAuthenticator'
+ || プロパティ名 || デフォルト値 ||
+ || `authenticator` || `org.apache.cassandra.auth.AllowAllAuthenticator` ||
+ 
  
   * '''auto_bootstrap'''
  
  seedノード以外の新規ノードについて、この設定を'true'に指定して起動することにより、そのノードは自動的に適切なデータをレプリケートします。(InitialTokenが指定されていない場合、追加されたノードは最も収容量の多いノードの半分のTokenレンジを引き受けます。)ブートストラップなしでノードを起動した場合、以降のブートストラップの際に誤って使用されないように、自分自身をブートストラップ済みとしてマークします。(データとcommitlogディレクトリを削除すればリセットできます。)
- 
- デフォルト値: 'false' - 既にデータが格納されているクラスタに新しいノードを追加する場合は、これを'true'に設定すべきです。
+ 既にデータが格納されているクラスタに新しいノードを追加する場合は、これを'true'に設定すべきです。
+ 
+ || プロパティ名 || デフォルト値 ||
+ || `auto_bootstrap` || `false` ||
  
   * '''cluster_name'''
  
@@ -51, +55 @@

  
  できるだけcommitlog用のディスクとデータ格納用のディスクは分けてください。commitlogの性能は「追記のみ」という動作に依存しており、データに対するランダムアクセスと混在させた場合書き込み性能に悪影響を与えます。'saved_caches_directory'
にはカラムファミリの 'savedキャッシュ' が保存されます。詳しくは
'key/row_cache_save_period_in_seconds' を参照してください。
  
- デフォルト値: それぞれ次の通り。 '/var/lib/cassandra/commitlog'、'/var/lib/cassandra/data'、'/var/lib/cassandra/saved_caches'
+ || プロパティ名 || デフォルト値 ||
+ || `commitlog_directory` || `/var/lib/cassandra/commitlog` ||
+ || `data_file_directories ` || `/var/lib/cassandra/data` ||
+ || `saved_caches_directory ` || `/var/lib/cassandra/saved_caches` ||
+ 
  
   * '''concurrent_reads''' and '''concurrent_writes'''
  
  多くのシステムと異なり、CassandraではReadよりWriteのほうが速いため、より多くのWriteを並列に実行できます。経験則に従えば、一つのプロセッサコアごとにconcurrent_readsを4つづつ増やせばよいと思います。Write性能が問題になるまで'concurrent_writes'はいじらないほうがいいでしょう。とはいえ、一般的にはCassandraクラスタ専用環境ではリングのCPUコア数の合計以上の値にするとよいでしょう。
  
- デフォルト値: concurrent_reads = 8, concurrent_writes = 32
+ || プロパティ名 || デフォルト値 ||
+ || `concurrent_reads ` || `8` ||
+ || `concurrent_writes ` || `32` ||
  
   * '''commitlog_rotation_threshold_in_mb'''、'''commitlog_sync'''、'''commitlog_sync_period_in_ms'''、
'''commitlog_sync_batch_window_in_ms'''
  
@@ -67, +77 @@

  
  Cassandraはwriteを複数のノードに対して実施するため「writeしたデータが物理的にディスクに格納される前」の障害でデータが失われる危険性は実際には一般的なデータベースほど顕著ではありません。もう一つのオプション'periodic'を選択するとwriteに対して直ちにackを返します。CommitLog
は単純にCommitLogSyncPeriodInMs ミリ秒ごとにfsyncされます。通常はデフォルト値の1000msで問題ないでしょう。JMXでCommitLog
PendingTasksを監視して、一つのsyncが完了する前に次のsyncが発生する状況が多発しているようであればこの値を増やすことを検討してください。
  
- デフォルト値:  'commitlog_rotation_threshold_in_mb' = 128 mb、'commitlog_sync' =
'periodic'、'commitlog_sync_period_in_ms' = 1000 ms
+ || プロパティ名 || デフォルト値 ||
+ || `commitlog_rotation_threshold_in_mb ` || `128` ||
+ || `commitlog_sync ` || `periodic` ||
+ || `commitlog_sync_period_in_ms ` || `1000` ||
  
   * '''disk_access_mode'''
  
- In 0.7, the default 'mmap_index_only' is recommended. For version 0.6, the default is 'auto',
but you're better off beginning your tuning with this set to 'standard'. Don't otherwise touch
this dial until you've read and understood the [[http://issues.apache.org/jira/browse/CASSANDRA-1214|discussion
in CASSANDRA-1214]], and examined your [[MemtableThresholds|swap and VM configuration]].
+ 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'''
  
- !EndPointSnitch: Setting this to the class that implements {{{IEndPointSnitch}}} which will
see if two endpoints are in the same data center or on the same rack. Out of the box, Cassandra
provides 4 such Snitches, found in {{{org.apache.cassandra.locator}}} :
+ '''endpoint_snitch''': このプロパティに {{{IEndPointSnitch}}} を実装したクラスを指定することにより、2つのノードが同じデータセンターに存在するか、あるいは同じラックに収容されているかの判定条件を制御できます。Cassandraパッケージの{{{org.apache.cassandra.locator}}}以下に4種類のSnitchが標準で添付されています。
  
-   a. {{{org.apache.cassandra.locator.SimpleSnitch}}} which will do nothing, 
+   a. {{{org.apache.cassandra.locator.SimpleSnitch}}} 何もしません。
-   a. {{{org.apache.cassandra.locator.RackInferringSnitch}}} which will assume that the 2nd
and 3rd octets of the IP contain the datacenter and rack, 
+   a. {{{org.apache.cassandra.locator.RackInferringSnitch}}} IPアドレスの第2オクテットがデータセンター、第3オクテットがラックに対応すると仮定して判定します。

-   a. {{{org.apache.cassandra.locator.PropertyFileSnitch}}} which will read from cassandra-topology.properties
to give explicit proximities, and 
+   a. {{{org.apache.cassandra.locator.PropertyFileSnitch}}} cassandra-topology.propertiesに明示的に設定された近傍定義(proximities)に従います。

-   a. {{{org.apache.cassandra.locator.Ec2Snitch}}} which will read the region and zone from
the ec2 node and use them as datacenter and rack. Don't use this if you're not running on
EC2.
+   a. {{{org.apache.cassandra.locator.Ec2Snitch}}} Amazon EC2ノードからリージョンとゾーンを読み取り、それらをデータセンターとラックと見なします。あなたの環境をEC2で動かしていない場合には使用しないでください。
  
- Dynamic Snitch is a boolean that controls if the above snitch is wrapped with a dynamic
snitch, which will monitor read latencies and avoid reading from hosts that have slowed.
+ '''dynamic_snitch''': 上記のsnitchをdynamic snitchでラッピングするかどうかを指定するbooleanです。dynamic
snitchは対向ノードの読み込み遅延を監視し、遅いノードからの読み出しを避けます。
  
- Defaults are: 'org.apache.cassandra.locator.SimpleSnitch' and 'false'.
+ || プロパティ名 || デフォルト値 ||
+ || `endpoint_snitch` || `org.apache.cassandra.locator.SimpleSnitch` ||
+ || `dynamic_snitch` || `false` ||
+ 
  
   * '''listen_address'''
  
  Commenting out this property leaves it up to {{{InetAddress.getLocalHost()}}}. This will
always do the Right Thing *if* the node is properly configured (hostname, name resolution,
etc), and the Right Thing is to use the address associated with the hostname (it might not
be: on cloud services you should ensure the private interface is used).
  
- Default is: 'localhost'. This must be changed for other nodes to contact this node.
+ このプロパティをコメントアウトすると{{{InetAddress.getLocalHost()}}}が使用されます。ノードのネットワーク設定が正しければこれでうまく動きます。(hostnameに紐づいたアドレスを使用します。)クラウドサービス上でシステムを構築する場合は正しいインターフェースを明示的に指定した方がいいでしょう。
+ 
+ || プロパティ名 || デフォルト値 ||
+ || `listen_address` || `localhost` (他のホストからこのノードにアクセスする為には、この値を変更する必要があります。)||
  
   * '''memtable_flush_after_mins''', '''memtable_operations_in_millions''', and '''memtable_throughput_in_mb'''
  

Mime
View raw message