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. The comment on this change is: Translation to Japanese. http://wiki.apache.org/cassandra/StorageConfiguration_JP?action=diff&rev1=64&rev2=65 -------------------------------------------------- = 設定の読み込み = == 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はKeyspace単位ではなくグローバルスコープに、gc_grace_secondsはグローバルからKS単位に変わっています）、自動生成されたyamlファイルは使用前に必ず精査してください。 + bin/config-converterを使用すると、現在使用しているstorage-conf.xmlをyaml形式にベストエフォートで変換できます。このツールはあなたのxmlファイルがconf/storage-conf.xmlに配置されており、また出力先がconf/cassandra.yamlであることを想定しています。ただし、0.7において多くのプロパティのスコープが変更されたため（例えば、endpoint_snitchはKS単位ではなくグローバルスコープに、gc_grace_secondsはグローバルからKS単位に変わっています）、自動生成されたyamlファイルは使用前に必ず精査してください。 == -Dcassandra.config == @@ -49, +49 @@ * '''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' を参照してください。 - デフォルト値: それぞれ '/var/lib/cassandra/commitlog'、'/var/lib/cassandra/data'、'/var/lib/cassandra/saved_caches' + デフォルト値: それぞれ次の通り。 '/var/lib/cassandra/commitlog'、'/var/lib/cassandra/data'、'/var/lib/cassandra/saved_caches' - - （中断） * '''concurrent_reads''' and '''concurrent_writes''' - Unlike most systems, in Cassandra writes are faster than reads, so you can afford more of those in parallel. A good rule of thumb is 4 concurrent_reads per processor core. It's unwise to adjust the {{{concurrent_writes}}} until you have a a performance problem to address. In general, though, for a dedicated cluster it should exceed somewhat the number of cpu-cores on the ring + 多くのシステムと異なり、CassandraではReadよりWriteのほうが速いため、より多くのWriteを並列に実行できます。経験則に従えば、一つのプロセッサコアごとにconcurrent_readsを4つづつ増やせばよいと思います。Write性能が問題になるまで'concurrent_writes'はいじらないほうがいいでしょう。とはいえ、一般的にはCassandraクラスタ専用環境ではリングのCPUコア数の合計以上の値にするとよいでしょう。 - Defaults are: '8' c. reads, and '32' c. writes. + デフォルト値: concurrent_reads = 8, concurrent_writes = 32 - * '''commitlog_rotation_threshold_in_mb''', '''commitlog_sync''', '''commitlog_sync_period_in_ms''', and '''commitlog_sync_batch_window_in_ms''' + * '''commitlog_rotation_threshold_in_mb'''、'''commitlog_sync'''、'''commitlog_sync_period_in_ms'''、 '''commitlog_sync_batch_window_in_ms''' - The rotation threshold determines how often a new commitlog segment is created. This number is generally never changed, but can be reduced if small amount of memory need to be squeezed from the system. - {{{CommitLogSync}}} may be either "periodic" or "batch". When in batch mode, Cassandra won't ack writes until the commit log has been fsynced to disk. It will wait up to {{{CommitLogSyncBatchWindowInMS}}} milliseconds for other writes, before performing the sync. + commitlog_rotation_threshold_in_mb はどのくらいの頻度で新しいcommitlogセグメントが生成されるかを決定します。一般的にはこの値を変更すべきではありませんが、この値を小さくすると僅かではありますがシステムのメモリ使用量を節約できます。 - This is less necessary in Cassandra than in traditional databases since replication reduces the odds of losing data from a failure after writing the log entry but before it actually reaches the disk. So the other option is "periodic", where writes may be acked immediately and the {{{CommitLog}}} is simply synced every {{{CommitLogSyncPeriodInMS}}} milliseconds. Usually the default of 1000ms is fine; increase it only if the CommitLog PendingTasks backlog in jmx shows that you are frequently scheduling a second sync while the first has not yet been processed. + CommitLogSync には periodic か batch を指定できます。batchモードではCassandraはcommitlogがfsyncされるまでwrite ackを返しません。CommitLogSyncBatchWindowInMS ミリ秒の間他のwriteが到着するのを待ったあと、fsyncを実行します。 - Defaults are: '128'mb commitlog size, 'periodic' sync, '10000' ms between syncs. + 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 * '''disk_access_mode'''
