0

したがって、約 3 億人のユーザーの情報を格納できる DB が必要です。各ユーザーには 2 つのベクトルがあります: 5 つのお気に入りアイテムと 5 つの最も類似したユーザー (これらのユーザーもユーザー セットに含まれています)。

元：

preferences                  users

user  |  item           user  |  user  
--------------          --------------
user1 |  item1          user1 |  user2
user1 |  item2          user1 |  user4
user1 |  item3          user2 |  user8
user2 |  item3             .   .   .
user2 |  item4
.    .   .

したがって、基本的には 2 つのテーブルが必要です。どちらも多対多の関係であり、どちらも比較的大きなものです。私は cassandra を調査してきましたが (ただし、他のソリューションも受け入れています)、スキーマをどのように定義するのか、最適化して適切に機能させるために必要なインデックスの種類を考えていました。

次の 2 つの方法でクエリを実行する必要があります。

1.もちろんユーザーごと、
2.リストにあるアイテムごと。（同じお気に入りアイテムを持つユーザーのリストを取得できるように）

私はすでに cassandra をセットアップして、いじり始めましたが、「複合」主キーが必要なため、リストを機能させることさえできませんか? 理由がわかりません。

ヘルプ/正しい方向へのプッシュは大歓迎です。

ありがとう！

4

1 に答える 1

1

ユースケースを適切に説明しているかどうかわかりません。何よりもまず重要な設計を定義するのはアクセス パターンであり、最終的に NoSQL データベースのワークロード特性を定義するのはアクセス パターンです。たとえば、特定の地域やそれに沿った何かに基づいてユーザーを検索する必要がありますか、それとも単純に 1 人のユーザーとそのお気に入りのアイテム、および/または類似のユーザーを取得するだけですか。

説明した内容に基づいて、おそらく user_ids のキースペースを作成するだけで、値を「お気に入りのアイテム」の非正規化されたコピーと「類似のユーザー ID」のリストにすることができます。あなたの次のアクションが、それらの類似したユーザーに対して何かを行うことであると仮定すると、ID のリストからそれらをすばやく取得できます。

重要な点は、キーの大きさ (文字数/バイト数) と、それらをメモリに収めることができるかどうかです。これにより、非常に高速なパフォーマンスが得られます。キー サイズに対してマシンのメモリが限られている場合は、特定の数のキーに対応できるノード数を計画し、それらのノードを別のサーバーで実行できるようにする必要があります。少なくとも、それが Oracle NoSQL Database (ONDB) にとって最も重要な部分です。私はそのチームの一員です。良いニュースは、300M がまだ非常に小さいことです。

それが役に立てば幸い、

-ロバート

于 2013-07-12T18:42:18.350 に答える