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=71&rev2=72 -------------------------------------------------- == -Dcassandra.config == Cassandraの起動時に、Java VMのパラメータとして渡すことにより、任意の設定ファイルをロードすることができます。具体的には、''-Dcassandra.conf=<your value here>''という形式でパラメータを与えます。値にはclasspath上のファイル、ローカル又はリモートのURLを指定できます。幾つかの例を次に示します： - ||'''値''' ||'''意味''' || + ||'''値''' ||'''意味''' || - ||''-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=http://www.example.com/remote-cassandra.yaml'' ||リモートホストから設定ファイルをロードします。 || - ||''-Dcassandra.config=file:///home/me/external-local-cassandra.yaml'' ||cassandraのclasspath上にないローカルの設定ファイルをロードします。 || + ||''-Dcassandra.config=file:///home/me/external-local-cassandra.yaml'' ||cassandraのclasspath上にないローカルの設定ファイルをロードします。 || @@ -23, +23 @@ == "私のkeyspaceはどこ?" == LiveSchemaUpdates。次のコマンドでスキーマを一度にロードすることができます。: - {{{ + {{{ bin/schematool HOST PORT import }}} @@ -35, +35 @@ プラグイン可能なユーザ認証を指定します。ここではThriftの'login'メソッド呼び出しの必要性の有無、またログイン時に必要なパラメータについて定義します。デフォルトの'!AllowAllAuthenticator'を使用した場合、ユーザは'login'メソッドを呼ぶ必要がありません。即ち、すべてのユーザが任意の捜査を実行可能です。他のビルトインのオプションには'!SimpleAuthenticator'があります。このユーザ認証設定ではユーザはloginを呼び出す必要があり、プロパティファイルに設定されたユーザ名とパスワードが必要になります。 - || プロパティ名 || デフォルト値 || + || プロパティ名 || デフォルト値 || - || `authenticator` || `org.apache.cassandra.auth.AllowAllAuthenticator` || + || `authenticator` || `org.apache.cassandra.auth.AllowAllAuthenticator` || * '''auto_bootstrap''' @@ -44, +44 @@ seedノード以外の新規ノードについて、この設定を'true'に指定して起動することにより、そのノードは自動的に適切なデータをレプリケートします。（InitialTokenが指定されていない場合、追加されたノードは最も収容量の多いノードの半分のTokenレンジを引き受けます。）ブートストラップなしでノードを起動した場合、以降のブートストラップの際に誤って使用されないように、自分自身をブートストラップ済みとしてマークします。（データとcommitlogディレクトリを削除すればリセットできます。） 既にデータが格納されているクラスタに新しいノードを追加する場合は、これを'true'に設定すべきです。 - || プロパティ名 || デフォルト値 || + || プロパティ名 || デフォルト値 || - || `auto_bootstrap` || `false` || + || `auto_bootstrap` || `false` || * '''cluster_name''' @@ -55, +55 @@ できるだけcommitlog用のディスクとデータ格納用のディスクは分けてください。commitlogの性能は「追記のみ」という動作に依存しており、データに対するランダムアクセスと混在させた場合書き込み性能に悪影響を与えます。'saved_caches_directory' にはカラムファミリの 'savedキャッシュ' が保存されます。詳しくは 'key/row_cache_save_period_in_seconds' を参照してください。 - || プロパティ名 || デフォルト値 || + || プロパティ名 || デフォルト値 || - || `commitlog_directory` || `/var/lib/cassandra/commitlog` || + || `commitlog_directory` || `/var/lib/cassandra/commitlog` || - || `data_file_directories ` || `/var/lib/cassandra/data` || + || `data_file_directories ` || `/var/lib/cassandra/data` || - || `saved_caches_directory ` || `/var/lib/cassandra/saved_caches` || + || `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_reads ` || `8` || - || `concurrent_writes ` || `32` || + || `concurrent_writes ` || `32` || * '''commitlog_rotation_threshold_in_mb'''、'''commitlog_sync'''、'''commitlog_sync_period_in_ms'''、 '''commitlog_sync_batch_window_in_ms''' @@ -76, +76 @@ Cassandraはwriteを複数のノードに対して実施するため「writeしたデータが物理的にディスクに格納される前」の障害でデータが失われる危険性は実際には一般的なデータベースほど顕著ではありません。もう一つのオプション'periodic'を選択するとwriteに対して直ちにackを返します。CommitLog は単純にCommitLogSyncPeriodInMs ミリ秒ごとにfsyncされます。通常はデフォルト値の1000msで問題ないでしょう。JMXでCommitLog PendingTasksを監視して、一つのsyncが完了する前に次のsyncが発生する状況が多発しているようであればこの値を増やすことを検討してください。 - || プロパティ名 || デフォルト値 || + || プロパティ名 || デフォルト値 || - || `commitlog_rotation_threshold_in_mb ` || `128` || + || `commitlog_rotation_threshold_in_mb ` || `128` || - || `commitlog_sync ` || `periodic` || + || `commitlog_sync ` || `periodic` || - || `commitlog_sync_period_in_ms ` || `1000` || + || `commitlog_sync_period_in_ms ` || `1000` || * '''disk_access_mode''' @@ -87, +87 @@ * '''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オクテットがラックに対応すると仮定して判定します。 @@ -96, +97 @@ '''dynamic_snitch''': 上記のsnitchをdynamic snitchでラッピングするかどうかを指定するbooleanです。dynamic snitchは対向ノードの読み込み遅延を監視し、遅いノードからの読み出しを避けます。 - || プロパティ名 || デフォルト値 || + || プロパティ名 || デフォルト値 || - || `endpoint_snitch` || `org.apache.cassandra.locator.SimpleSnitch` || + || `endpoint_snitch` || `org.apache.cassandra.locator.SimpleSnitch` || - || `dynamic_snitch` || `false` || + || `dynamic_snitch` || `false` || * '''listen_address''' このプロパティをコメントアウトすると{{{InetAddress.getLocalHost()}}}が使用されます。ノードのネットワーク設定が正しければこれでうまく動きます。（hostnameに紐づいたアドレスを使用します。）クラウドサービス上でシステムを構築する場合は正しいインターフェースを明示的に指定した方がいいでしょう。 - || プロパティ名 || デフォルト値 || + || プロパティ名 || デフォルト値 || - || `listen_address` || `localhost` （他のホストからこのノードにアクセスする為には、この値を変更する必要があります。）|| + || `listen_address` || `localhost` （他のホストからこのノードにアクセスする為には、この値を変更する必要があります。）|| * '''memtable_flush_after_mins'''、'''memtable_operations_in_millions'''、'''memtable_throughput_in_mb''' @@ -118, +119 @@ memtable_operations_in_millionsもmemtable_throughput_in_mbもデフォルト値はブート時のヒープ割当によって決まります。 - || プロパティ名 || デフォルト値 || + || プロパティ名 || デフォルト値 || - || `memtable_flush_after_mins ` || `60` || + || `memtable_flush_after_mins ` || `60` || - || `memtable_operations_in_millions` || `HeapSize/2**29 * 0.3` || + || `memtable_operations_in_millions` || `HeapSize/2**29 * 0.3` || - || `memtable_throughput_in_mb` || `HeapSize/2**23` || + || `memtable_throughput_in_mb` || `HeapSize/2**23` || * '''partitioner''' - Partitioner: any {{{IPartitioner}}} may be used, including your own as long as it is on the classpath. Out of the box, Cassandra provides {{{org.apache.cassandra.dht.RandomPartitioner}}}, {{{org.apache.cassandra.dht.OrderPreservingPartitioner}}}, and {{{org.apache.cassandra.dht.CollatingOrderPreservingPartitioner}}}. (CollatingOPP colates according to EN,US rules, not naive byte ordering. Use this as an example if you need locale-aware collation.) Range queries require using an order-preserving partitioner. + '''partitioner''': クラスパスに配置されている任意のIPartitionerを指定できます。Cassandraパッケージには標準で{{{org.apache.cassandra.dht.RandomPartitioner}}}、{{{org.apache.cassandra.dht.OrderPreservingPartitioner}}}、{{{org.apache.cassandra.dht.CollatingOrderPreservingPartitioner}}}が含まれています。（CollatingOrderPreservingPartitionerはネイティブバイト値ではなく、EN.USの規則に従って順序づけを行います。）レンジクエリを行うには順序を保存する（Order-Preserving）Partitionerを指定する必要があります。 - Achtung! Changing this parameter requires wiping your data directories, since the partitioner can modify the !sstable on-disk format. + 注意！この設定を変更するとPartitionerはディスク上のsstableのフォーマットを変更するので、データディレクトリを削除して再作成する必要があります。 - If you are using an order-preserving partitioner and you know your key distribution, you can specify the token for this node to use. (Keys are sent to the node with the "closest" token, so distributing your tokens equally along the key distribution space will spread keys evenly across your cluster.) This setting is only checked the first time a node is started. + あなたが順序を保存するPartitionerを使用中で、キーの分散特性を理解しているなら、このノードが使用するトークンを指定することができます。（キーはキー値に最も「近い」トークンを持つノードに送られます。つまりキー空間内で均等な間隔でトークンを配置すればクラスターノード間で均等にキーが分散します。）この設定はノードを最初に起動した時のみ確認されます。 - This can also be useful with {{{RandomPartitioner}}} to force equal spacing of tokens around the hash space, especially for clusters with a small number of nodes. + RandomPartitionerはトークンをハッシュ値によって分散しますが、クラスターノードの数が少ない場合には特に有用です。 - Cassandra uses MD5 hash internally to hash the keys to place on the ring in a {{{RandomPartitioner}}}. So it makes sense to divide the hash space equally by the number of machines available using {{{InitialToken}}} ie, If there are 10 machines, each will handle 1/10th of maximum hash value) and expect that the machines will get a reasonably equal load. + RandomPartitionerを使用した場合Cassandraは内部的にMD5ハッシュを使用してリング上のキー配置を決定します。InitialTokenを適切に設定することでハッシュ空間をリング上のノード数で均等に分割することができます。例えばリングに10台のノードがある場合、それぞれのノードはハッシュの最大値の1/10づつを境に処理を受け持つように構成すれば、負荷はほぼ均等になるでしょう。 - With {{{OrderPreservingPartitioner}}} the keys themselves are used to place on the ring. One of the potential drawback of this approach is that if rows are inserted with sequential keys, all the write load will go to the same node. + OrderPreservingPartitionerを使用した場合キーはリング上の配置を決定します。この構成の欠点は、仮に行がシーケンシャルなキーで挿入された場合、すべてのトラフィックが同じノードに集中するということです。 - Default is: 'org.apache.cassandra.dht.RandomPartitioner'. Manually assigning tokens is highly recommended to guarantee even load distribution. + || プロパティ名 || デフォルト値 || + || `partitioner ` || `org.apache.cassandra.dht.RandomPartitioner` || + + 負荷の均等な分散を保証したいならトークンを明示的に指定することをお勧めします。 * '''seeds'''
