そして、避けるべき落とし穴は何ですか？取引の中断はありますか? たとえば、Cassandra データのエクスポート/インポートが非常に難しいと聞いたことがありますが、それによって本番データと開発環境の同期が妨げられるのではないかと考えています。
ところで、Cassandra に関する優れたチュートリアルを見つけるのは非常に困難です。私が持っている唯一のチュートリアルは、まだ非常に基本的なものです。
ありがとう。
質問する
25780 次
5 に答える
41
私にとって重要なことは、OrderedPartitioner と RandomPartitioner のどちらを使用するかを決定することです。
RandomPartitioner を使用する場合、範囲スキャンはできません。これは、古いデータのクリーンアップを含め、すべてのアクティビティの正確なキーを知っている必要があることを意味します。
したがって、多くのチャーンがある場合、挿入したキーを正確に知る魔法の方法がない限り、ランダムパーティショナーを使用すると、簡単にデータを「失う」ことができ、ディスクスペースリークが発生し、最終的にはすべてのストレージを消費します。
一方、注文されたパーティショナーに「A と B の間の列ファミリー X にあるキーは何ですか?」と尋ねることができます。-そしてそれはあなたに教えてくれます。その後、それらをクリーンアップできます。
ただし、欠点もあります。Cassandra は自動ロード バランシングを行わないため、順序付けされたパーティショナーを使用すると、すべてのデータが 1 つまたは 2 つのノードだけに配置され、他のノードにはデータが配置されない可能性が高くなります。つまり、リソースを浪費することになります。
これについて簡単な答えはありませんが、キーの先頭に短いハッシュ値 (他のデータ ソースから簡単に列挙できるもの) を配置することで、場合によっては「両方の世界のベスト」を得ることができます。たとえば、ユーザー ID の 16 ビット 16 進数ハッシュ - これにより、4 桁の 16 進数が得られ、その後に実際に使用したいキーが続きます。
次に、最近削除されたユーザーのリストがある場合は、ID をハッシュし、範囲スキャンを実行して、関連するすべてのものをクリーンアップできます。
次のトリッキーなビットはセカンダリ インデックスです。Cassandra にはセカンダリ インデックスがありません。したがって、X ごとに Y で検索する必要がある場合は、両方のキーの下にデータを挿入するか、ポインターを用意する必要があります。同様に、これらのポインタが指しているものが存在しない場合、これらのポインタをクリーンアップする必要があるかもしれませんが、これに基づいてクエリを実行する簡単な方法はないため、アプリはただ覚えておく必要があります。
また、アプリケーションのバグにより、忘れていた孤立したキーが残る可能性があり、db 内のすべてのキーを定期的にスキャンするガベージ コレクターを作成しない限り、それらを簡単に検出する方法はありません (これにはしばらく時間がかかります -チャンクで行うこともできます）、不要になったものをチェックします。
これは実際の使用法に基づいたものではなく、調査中にわかったことです。本番環境では Cassandra を使用していません。
編集: Cassandra は現在、トランクにセカンダリ インデックスを持っています。
于 2009-10-03T06:26:31.557 に答える
17
これはコメントとして追加するには長すぎたので、問題のリストからのいくつかの誤解を解消するために、次のように返信します。
どのクライアントもどのノードにも接続できます。選択した (またはロード バランサー経由で接続した) 最初のノードがダウンした場合は、単純に別のノードに接続します。さらに、クライアントが書き込み自体を指示できる「ファット クライアント」API を使用できます。例はhttp://wiki.apache.org/cassandra/ClientExamplesにあります
サーバーが無期限にハングアップするのではなく、応答しなくなったときにタイムアウトすることは、過負荷の rdbms システムを扱ってきたほとんどの人が望んでいた機能です。Cassandra RPC タイムアウトは構成可能です。必要に応じて、数日に自由に設定して、代わりに無期限にぶら下げることもできます。:)
確かに、複数削除または切り捨てのサポートはまだありませんが、これらの両方に対するパッチが検討中です。
クラスター ノード間で負荷のバランスを保つには、明らかにトレードオフがあります。より完全にバランスを保とうとすればするほど、より多くのデータ移動が必要になりますが、これは自由ではありません。デフォルトでは、Cassandra クラスター内の新しいノードはトークン リング内の最適な位置に移動して、不均一性を最小限に抑えます。実際には、これはうまく機能することが示されており、クラスターが大きいほど、倍増が最適であるという事実は少なくなります。これについては、 http://wiki.apache.org/cassandra/Operationsで詳しく説明されています
于 2009-12-17T15:16:51.967 に答える
7
于 2009-10-04T02:47:41.340 に答える
5
Cassandra 1.2 が最近リリースされたので、これは更新に値すると思います。
過去 18 か月間、ソーシャル ゲームの本番環境で Cassandra を使用してきました。
ただし、Cassandra の長所を活かすには、Cassandra を使用する必要があります。そのため、どのデータ モデルを使用するかを確認したり、別の DB ソリューションがより役立つかどうかを特定したりするために、それが何をどのように行うかを十分に理解する必要があります。
OrderedPartitionerは、アプリケーションがキー範囲クエリに依存している場合にのみ役立ちますが、そのために Cassandra の最も強力な機能の 1 つである自動シャーディングと負荷分散を諦めることになります。行キー範囲クエリの代わりに、同じ行内の列名の範囲を使用して、必要な同じ機能を実装しようとします。TL;DR読み取り/書き込みは、これを使用するノード間でバランスが取れていません。
RandomPartioner (md5 ハッシュ) とMurmurPartitioner (Murmur ハッシュ、より良く、より高速) は、ビッグ データと高いアクセス頻度をサポートする場合に使用する必要がある方法です。あなたがあきらめるのは、キー範囲クエリだけです。同じ行にあるものはすべてクラスター内の同じノードにあり、それらに対してコンパレーターと列名の範囲クエリを使用できます。TL;DR : 適切なバランスをとるためにこれを使用してください。
カサンドラについて知っておくべきこと:
Cassandra は最終的に一貫性があります。Cassandra は、一貫性と引き換えに高可用性と優れたパーティショニングを選択しました ( http://en.wikipedia.org/wiki/CAP_theorem )。しかし、あなたはcassandraから一貫性を得ることができます.それはあなたがそれを読み書きするときの一貫性ポリシーに関するものです. cassandra の使用について話すとき、これは非常に重要で複雑なトピックですが、 http: //www.datastax.com/docs/1.2/dml/data_consistency で詳しく読むことができます。
経験則として (そして簡単にするために)、QUORUM ConsistencyLevel で読み取りと書き込みを行います (私のアプリでは、読み取りは書き込みと同じ頻度で行われる傾向があるため)。アプリの書き込み負荷が非常に高く、読み取りの頻度がはるかに低い場合は、書き込みを 1 つに、読み取りをすべてに使用します。または、ユースケースが逆の場合 (書き込みは読み取りよりもはるかに頻度が低い)、ONE で読み取り、ALL で書き込みを試すことができます。ANY を書き込みの一貫性レベルとして使用することは、解決しようとしているのが一貫性である場合には良い考えではありません。ミューテーションがクラスターに到達したことは保証されますが、どこかに書き込まれたことは保証されないためです。これは、cassandra で書き込みがサイレントに失敗した唯一のケースです。
これらは、cassandra 開発を簡単に開始できるようにするための単純なルールです。本番クラスターから可能な限り多くの一貫性とパフォーマンスを得るには、このトピックをよく調べて、自分でよく理解する必要があります。
エンティティ (テーブル) 間の複雑な関係を持つ人間が読めるデータモデルが必要な場合は、Cassandra は適していないと思います。MySQL と、場合によっては NewSQL の方が、ユース ケースにより役立つ場合があります。
知っておくと良いことは、大まかに、cassandra がデータを保存および読み取る方法です。書き込むたびに (削除は実際には cassandra の「墓石」値の書き込みです)、システムは新しい値とそのタイムスタンプを新しい物理的な場所に配置します。
読み取ると、cassandra は特定の key/column_name の場所に対するすべての書き込みをプルしようとし、見つけた最新のもの (クライアントから提供されたタイムスタンプが最も高いもの) を返します。そのため、ノードが必要とするメモリは、書き込みの頻度に直接依存します。Cassandra には、古いミューテーションを消去する圧縮プロセスがあります。Cassandra には、場所の最新の値で読み取り時に更新される内部キャッシュがあります。
SSTables (データを永続化するデータ構造) のディスク上のマージ/圧縮は、読み取りによって引き起こされる可能性がありますが、それを当てにしない方がよいでしょう。トゥームストーンと有効期限が切れた列のクリーニング (存続時間機能を使用) は、ガベージ コレクターによって管理される別のメカニズムです (詳細については、GC 猶予時間の設定を参照してください)。
これは、私が言いたい最後のポイントにつながります。書き込みと読み取りがクラスター全体でバランスが取れていることを確認してください!
すべてのユーザーが 1 つの場所を非常に頻繁に更新する必要があるとします。
その理論上の単一の場所を 1 つの行キーのみにマップしないでください。これにより、すべての書き込みがクラスター内の 1 つのノードのみに分類されます。すべてがダウンしない場合 (ロックスターの sysop があるため)、少なくともクラスターのパフォーマンスが大幅に低下します。
私のアドバイスは、クラスター内のすべてのノードに書き込みを分散するのに十分な数の異なる行キーに書き込みをバケット化することです。その単一の理論上の場所のすべてのデータを取得するには、すべての「サブ行キー」で multi_get を使用します。
例:
すべてのアクティブな http セッション (uuid が割り当てられている) のリストが必要です。すべてを 1 つの「セッション」行キーに保存しないでください。6 ノードの cassandra クラスターの行キーとして使用するのは、_sessions. 次に、すべてのアクティブなセッションを取得するための小さな 16 個のキー multi_get があります。または、単純な get を使用するだけでセッションがアクティブかどうかを判断できます (もちろん、その uuid がわかっている場合)。クラスターが非常に大きい場合は、バケット キーの生成にハッシュ関数を使用することをお勧めします。
于 2013-04-04T14:33:39.460 に答える