0

私はcassandraを初めて使用し、cassandraは多くの読み取りタイムアウトエラーを出しています..タイムアウトを微調整しましたが、それでも問題は設計に問題がある可能性があります(私のアプリケーションcassandraは何兆ものデータを保存すると予想されます):

質問 1 : すべての cassandra テーブルで UUID を行キーとして使用しています...しかし、いくつかのテーブルでは、メンテナンスのためだけにそのルールを破っています。保存されたデータ...巨大なケースにはUUIDの正しいアプローチを使用し、ユーザーテーブルには2番目のアプローチが正しいかどうか???????????

質問 2 : startNodeId、relationTypeId、endNodeId を持つ 1 つの関係テーブルがあります。そのための行キーは、relationId である UUID です.....私は、startNode、relationType、endNode でセカンダリ インデックスを定義します。ビジネスケース.......そのため、新しい行ごとに、既存の関係をチェックする必要があります....既存のチェックを回避する1つの方法は、startNodeId、relationTypeId、endNodeId SORTを取りますそれらを作成して HASH CODE を作成し、それを ROWKEY として使用します...だから、ここでは明示的にチェックすることを避けます........これは正しいアプローチですか???????

私はこれらの考えに行き詰まっています...どんなガイダンスも本当に私を助けてくれます

4

2 に答える 2

0

最初の質問に答えると、uuid 以外の値で行キーを快適に処理できるようになるまで、UUID の方が追跡しやすくなります。

2 番目の質問については、複合キーを試してみませんか。ハッシュコードのようなものを維持する必要はありません。Cassandra に任せてください。

于 2013-07-15T06:29:54.840 に答える