2

PenWag.comでMySQLからCassandraへの変換を急いでいるところです。Cassandraでは、GUIDからキーオフされたユーザーを保存していますが、ユーザーはGUIDではなく電子メールでサインインします（明らかに）。ユーザーのキーとしてのGUIDは、2つの理由から、電子メールよりも私にとって理にかなっています。実用的な観点からは、すべてのSuperColumnsを含む行を変更または削除/追加するのは面倒すぎるようです。理論的な観点からは、それはまだ同じユーザーですが、なぜ彼らのキーを変更する必要がありますか？

それでも、私の質問は次のとおりです。別のColumnFamilyにインデックスを作成し、ログインをサポートするようにemail->GUIDをマッピングしています。これは標準タイプのCFであり、列名は電子メールで、値はGUIDです。マッピングごとにSC全体がロードされないようにするのは、SuperではなくStandardです。「メールの変更」のサポートは簡単で、列の削除/追加だけです。ただし、これに代わる方法は、インデックスを列ではなく行として格納することです。行キーは電子メールであり、列はGUIDを保持します。管理する列（GUID）しかないため、これらの行の削除/追加は面倒ではありません。

どちらのアプローチでもうまくいくようです。それぞれの長所と短所は何ですか？ベストプラクティスはありますか？

4

2 に答える 2

2

私は Cassandra や同様のデータベースを実際に使用した経験がないので、私の回答を一粒の塩で受け取る必要があります :)

電子メール アドレスを列名として使用して、各マッピングを列として格納すると、膨大な量の列を含む 1 つの行を意味します。ウィキペディア[ 1 ]によると:

読み取りまたは書き込み対象の列の数に関係なく、1 つの行キーでのすべての操作はレプリカごとにアトミックです。

これにより、すべてのマッピングが 1 つの行に格納されている場合、ロックのオーバーヘッドが大きくなる可能性があります。

Cassandra Wiki には[ 2 ]と記載されています。

行キーは、どのマシン データが格納されるかを決定するものです。

これにより、列名よりも行キーに基づいて検索を行う方が効率的であると私は信じています。この情報に基づいて、メール アドレスを行キーとして使用し、GUID を列に格納することをお勧めします。

于 2010-07-28T07:42:20.890 に答える
2

ニールスは正しいです。これを手動で行うには、ユーザーごとに 1 行にするのが正しい方法です。

0.7では、残りのUUIDユーザーデータを含む行にメール列を作成し、Cassandraにインデックスを依頼することができたので、私はそれを修飾します: http://www.riptano.com/blog/whats-新しい-cassandra-07-secondary-indexes

于 2010-12-06T14:58:48.870 に答える