JMXで行キャッシュあるいはキーキャッシュのヒット率が0.XX123456789のように表示されます。Logが大変肥大化しています。ハイレベルのクライアントを使用する場合は、リクエストがノード間で分散するように、そのクライアントでどのオプションが使用できるかよく調査して下さい。動いているCassandra上でReplicationFactorを変更することは出来ますか?可能ですが、既存データのレプリカの数を変更するために、リスタートと手動リペアが必要です。クラスターのすべてのノードにおいて、ストレージ設定内の対象キースペースのReplicationFactorを更新します。クラスターのすべてのノードをリスタートします。各ノードに対して実施します。repair"を各ノードで実行します。これは重い処理ですので、クラスターの性能に悪影響があるかもしれません。リペアはノード別に順番に実施することを強く推奨します。全ノードで同時にリペアを実行するとひどく時間がかかるか、あるいはクラッシュするかもしれません。Cassandraで巨大なファイルやBLOBを保存できますか?現在のCassandraは巨大なファイルやBlobストレージとしては最適化されていません。64MB前後のファイルまでであれば分割することなく容易に格納できます。これは主にCassandraが公式APIとして使用しているThriftに起因する制約事項です。Thriftではストリーミング機能が提供されていないため、write/readされるデータはメモリに収まらなければなりません。Cassandraが将来Thrift以外のインターフェースをサポートすればこの問題を解決するかもしれませんが、今のところThrift自体の挙動を変更する計画はありません。Blobを格納するようなアプリケーションを設計する場合、以下のCassandraの特性にも注意して下さい。特定のキーとカラムに含まれるデータは単一ノードのディスクに収まらなければなりません。これがカラムやスーパーカラムの大きさに関する主要な制限になります。キーはレプリカ先のノードを決定するために使用されるため、特定のキーにひもづけられたデータは格納先ノードのストレージサイズによって規定されます。これはCassandraの分散モデルから派生する制限事項です。巨大なカラムを作成したり、読み出したりする場合、カラムのデータはRAMに読み込まれます。このようなケースでは容易にリソース集約的になりがちです。それぞれ10MBの画像ファイルを格納したカラムを含む行を200行RAMにロードすると小計2GBのRAMを使用することになります。ロードする行数が増えれば増えるほど、RAMの消費は急激に増加します。これを回避することは可能ですが、多くのアプリケーションで有効な解決方法を見いだすには事前の設計と試験が必要です。この挙動に関する情報についてはmemtablesを参照して下さい。0.7で使用可能な対策については次のリンクを参照してください。Limitationsを参照して下さい。127.0.1.1"と言われます.何が起きているのでしょうか?NodetoolはJMXに依存しています。JMXはRMIに依存しており、独自のリスナとコネクタをデータ交換の必要に応じて生成します。通常はこれらはバックグラウンドで透過的に動作しますが、接続元、あるいは接続先のホスト名の名前解決が正しく行われないと、混乱させられるような例外が発生する場合があります。ホストが正しく/etc/hostsに登録されていることを確認してください。それでもうまくいかない場合は、JVMの起動時に-Djava.rmi.server.hostname=$IPを指定して下さい。ここで、$IPは他のホストからそのホストに接続できるIPアドレスです。get_range_slicesを使います。空文字列から始め、呼び出し毎に最後に読んだキーを次の繰り返しのスタートキーに使います。HadoopSupportを使います。Keyspaceがstorage-conf.xmlに一つも定義されていないのはなぜでしょうか?0.7以前ではcassandraはstorage-conf.xmlに静的に定義されたキースペースをロードしました。よって稼働中のクラスタのスキーマを動的に変更する機能が追加されました。このため、storage-conf.xmlに定義されたスキーマは無視するように動作を変更する必要がありました。同時に、0.7では設定ファイルはYAML形式に変更されました。使用中のstoreage-conf.xmlがある場合、はじめにbin/config-converterツールでYAML形式に変換する必要があります。このツールはstorage-conf.xmlからcassandra.yamlを生成します。cassandra.yamlを作成したら、定義されているスキーマを一度だけロードすることができます。0.7ではStorageServiceMBeanにloadSchemaFromYAMLメソッドが追加されています(JMXによってトリガされます。詳しくはhttps://issues.apache.org/jira/browse/CASSANDRA-1001を参照して下さい。このメソッドによりcassandra.yamlに定義されたスキーマをロードすることができますが、これは一度のみ実行可能な操作です。loadSchemaFromYAMLによってスキーマ定義されたノードは、以降のリスタートではsystemテーブルからスキーマを読み込みます。これ以降のスキーマ変更はthriftのsystem_*操作で行う必要があります。スキーマ変更は同一のノードで実行し、他のクラスターノードへのスキーマ変更の伝搬はcassandraに任せることをお勧めします。同じスキーマ変更を複数のノードで同時に実行した場合、マイグレーションの不整合を引き起こし、クラスターを混乱させる可能性があります。詳細はLiveSchemaUpdatesを参照して下さい。UIとしてhttp://code.google.com/p/cassandra-guiがあります。これはSwingベースのデータブラウザです。bytes"あなたは恐らくカラムファミリーの中でLongTypeカラムソーターを使っているはずです。endianであることを想定しています。以下のサンプルコードで、phpからcassandraにintegerをpackして格納する方法、そしてcassandraから読み出してunpackする方法について説明します。newClusterName"が出力され,起動できませんオペレーターによる誤操作を避けるため、Cassandraはクラスター名をsystemテーブルに記録しています。削除したほうが安全です。batch_mutateはアトミックな操作ですか?特殊な例として、単一のキーに対するbatch_mutationを考えると、それぞれのmutationはアトミックですが、アイソレーションはされていません。このようなmutationの最中にreadを行うと、部分的に更新された状態が見える可能性があります。一般的に言うと、batch_mutateはアトミックではありません。複数のキーに対する操作を単一の呼び出しにまとめることを許しています。batch_mutateがmutationの途中で失敗した場合、既に適用されたmutationはそのまま残ります。ロールバックはされません。このような場合、一般的にはクライアントアプリケーションはbatch_mutateをリトライする必要があります。Cassandraクラスタはマルチテナント運用可能ですか?スケジューリングや認証など、マルチテナント機能をより充実するための取り組みが行われています。詳しくはMultiTenantを参照して下さい。どんなユーザが何のためにCassandraを使っているのでしょうか?Cassandraを使用しているユーザや、その用途についてはCassandraUsersを参照して下さい。Cassandra用のODBCドライバはありませんか?ありません。Cassandraに直接ログを記録する方法はありますか?Cassandraに直接ログする方法についてはLoggingToCassandraを参照して下さい。Linuxを使う上で何か問題はありますか?もしselinuxがONになっていたら、OFFにしてください。認証・権限付与の機能はありますか?あります。詳細についてはExtensibleAuthを参照して下さい。データをバルクロードするにはどうしたらいいでしょうか?BulkLoadingを参照して下さい。レンジスライスやシーケンシャルスキャンはなぜ期待通りの結果を返さないのでしょうか?あなたは多分RandomPartitionerを使っているはずです。これはデフォルト設定で、データが特定のノードに偏ることを避けられます。keyのmd5ハッシュ値の順で並びます。count引数を指定すれば実現できます。行の中であれば、カラムをカラム名の順序で取得できます。データを各行に配置する方法を工夫することで、行そのものが整列していなくても済む場合もあるでしょう。メーリングリストの配信を停止するにはどうしたらいいですか?user-unsubscribe@cassandra.apache.orgにメールを送ってください。Compactionを実行してもディスク使用量が減らないのはなぜでしょうか?compactionによって不要になったSSTableはJVMがGCを実行する際に非同期的に削除されます。必要ならjconsoleで強制的にGCさせることもできますが、Cassandraは空きスペースが少なくなれば自動的にGCを実行します。不要になったsstableにはcompactionマーカーが付与されます。GCが実行される前にサーバーがリスタートした場合、起動時にこれらのsstableを削除します。詳細についてはMemtableSSTableを参照してください。readのためにmmapを使用しています。sstableデータファイルをCassandraプロセスのアドレス空間にマップするためにOSの仮想メモリシステムを使用しているのです。これが仮想メモリが多量に使用されているように見える理由です。実際に使用されているのは仮想アドレス空間ですが、topなどのツールでは仮想メモリの消費としてレポートされます。64ビット環境ではアドレス空間はほぼ無限大ですので、あまり気にする必要はありません。通常の意味でのメモリ使用量の観点から問題となるのはbrk()でアロケートされたデータの量やmmapされた/dev/zeroです。これは使用された実メモリ量を示しています。mmapされたファイルについて注意すべき点は、それらを物理メモリに保持する必要がないということです。物理メモリに保持されたmmapファイルは基本的にはキャッシュとみなせます。これはちょうど通常のI/Oによってread/writeしたデータがカーネルのページキャッシュに保持されるのと同じです。通常のI/Oとmmap()の違いは、mmap()がメモリをプロセスにマップするため、topでレポートされる仮想メモリサイズに影響することにあります。通常のI/Oに替えてmmap()を使う主な利点は、メモリにアクセスするだけでreadが完了する点にあります。そのメモリ領域が実際にロードされている(residentである)場合は、正にそれを読むだけで、ページフォルトも不要です。詳細については次のリンクを参照してください。Keyspaceを更新する場合、最初にスナップショットが取られます。これには既存のSSTableへのハードリンクを生成することを意味しますが、Javaにはハードリンクをネイティブで生成する機能がないため、"ln"をfork/execする必要があります。forkを実行する際には、例え子プロセスがそのすべてを使用しないとしても親プロセスと同じ大きさのフリーメモリが必要です。Javaは巨大なプロセスですので、これは難しい問題です。Accessをインストールし、ハードリンクの生成をネイティブで実行することです。特定のデータを担当するノードセット(単一、または複数のノードの場合があります)は以下の要素で決定されます。SimpleStrategyの場合、レプリカはリング上の後続ノードに配置されます。最初のノードはパーティショナーと行キーによって決定され、残りのレプリカデータは後続ノード上に配置されることになります。NetworkTopologyStrategyの場合、レプリカ配置はデータセンターとラック構成によって影響されます。異なるラックやデータセンターに配置されたノードがどのようにリング上に配置されるかにも依存します。注意すべきなのは、Cassandraは現在の負荷や、ノードの死活情報、クライアントが接続したノード等よってレプリカセットの構成を変更しないと言うことです。JMXで行キャッシュあるいはキーキャッシュのヒット率が0.XX123456789のように表示されます。これはXX%という意味でしょうか?それとも0.XX%でしょうか?XX%です。Logが大変肥大化しています。logは削除されません。回避方法をひとつ紹介します。それは、カラムファミリー別のオプションである、memtable_flush_after_minを設定することです。分毎にフラッシュさせることができます。初期設定としては、60分からはじめるのがよいでしょう。この設定をするには、cassandra-cliで以下のコマンドを実行して下さい。言い換えると、seedはGossipネットワークのハブとして機能します。Seedノードが存在することにより、リング内の各ノードは他のノードの状態変化をよりすばやく検出することができるようになります。新規のノードをリングに追加する場合にもSeedが使用されます。新規ノードはseedを参照してリング内の他のノードの情報を学習します。リングにノードを追加する場合、少なくとも一つの稼働中のseedを指定しなければなりません。一度リングにjoinして他のノード情報を学習すれば、以降はseed無しでもboot可能です。seedとして設定したノードはauto_bootstrapしません。新規のノードをseedとして追加したいなら、まずauto_bootstrapでリングにjoinし、次にseedとして設定する必要があります。seedが1台しかない場合、それは単一障害点になりますか?カラムファミリーがレプリケートされているのであれば、リングにseedが1台しかなくても単一障害点とはなりません。seedが稼働していなくてもリングはブート可能ですし、要求を処理できます。seedが無い場合、リング内のノード状態の変化の検出に時間がかかるようになります。本番環境では複数のseedを配置した方がよいでしょう。getNaturalEndpoints)JMXインターフェースの幾つかの操作はjconsole上ではボタンが無効となっていて、呼び出すことができません。jconsoleは配列引数を持つ操作の実行をサポートしていないため、このような操作をjconsoleから実行することはできません。配列引数を持つJMX操作を実行するには、独自のJMXクライアントを作成するか、あるいは配列引数をサポートしているJMX管理ツールを使用する必要があります。キーには最大どのくらいのサイズのデータが使用可能でしょうか?キー(及びカラム名)は64Kバイト以下でなければなりません。一般的にはこれらの影響は他の要素に比べて無視できる範囲ですが、非常に大きい「生の」キーを扱う事例では代わりにそれらのハッシュ値をキーとして使用しているユーザもいます。