0

この問題を 1 週間解決しようとしてきましたが、すべての調査で解決策を見つけることができなかったので、皆さんに質問することにしました。

「Product」テーブルと「productSent」テーブルがあります。説明に役立つ簡単なスキームを次に示します。

class Product(ndb.Model):
  name = ndb.StringProperty();
  rating = ndb.IntegerProperty

class productSent(ndb.Model): <--- the key name here is md5(Product Key+UUID)
  pId = ndb.KeyProperty(kind=Product)
  uuId = ndb.KeyProperty(kind=userData)
  action = ndb.StringProperty()
  date = ndb.DateTimeProperty(auto_now_add=True)

私の目標は、ユーザーがこれまでに見たことのない最高評価の製品をすばやく表示することです。そこで、ユーザーが見た製品を追跡するために、productSent テーブルを使用します。評価順が変わるたびに、カーソルが新しい上位の商品をスキップする可能性があるため、カーソルを使用する代わりにこのテーブルを作成しました。例: ユーザーがデータベースで製品 1 ～ 24 を見たとします。次に、5 人のユーザーが製品 25 番を気に入り、データベースの 10 番目の製品になりました。この製品がユーザーに二度と表示されないのではないかと心配しています (そして、より高い規模で物事を台無しにする可能性があります)。

私が現在行っている方法の問題は、ユーザーが最初の 1,000 製品を超えると、クエリのパフォーマンスが実際に低下し始めることです。文字通り 1,000 件以上の結果を取得しているため、productSent テーブルに対してクエリを実行して送信されたかどうかを確認し (処理を高速化するために keyName ルックアップを実行)、15 件の新しい結果が検出されるまでループを実行します。

私が考えた 1 つの解決策は、製品を見たすべてのユーザーの Product テーブルに繰り返しプロパティ (listProperty) を追加することでした。または、不等式フィルターを使用したくない場合は、製品を見ていないすべてのユーザーの繰り返しプロパティを配置できます。そうすれば、クエリを実行するときに動的にそれらを取り出すことができます。しかし、1,000 人以上のユーザーがいるとどうなるか心配です。

a) 1 つのエンティティで繰り返されるプロパティの制限について屋根を通り抜けます。b) インデックスのサイズにより、サイズのコストが増加します

以前にこの問題に対処した人はいますか (きっと誰かが対処したと思います!)。

更新 さて、別のアイデアがありました。評価 (いいね! の数) が変化したときに発生する変化を最小限に抑えるために、ポジティブ、ニュートラル、ネガティブの 3 つの値のみを持つセカンダリ列を作成できます。そして、それで並べ替えますか？もちろん、評価が 0 で「いいね」を獲得した (それらを肯定的にする) アイテムの場合でも、順不同またはカーソルによってスキップされる可能性がありますが、その可能性は低くなります。皆さんはどう思いますか？

4

2 に答える 2

0

予想されるボリュームと正確な問題はわかりませんが (質問をざっと読んだだけです)、計画の一部として Json TextProperty ストレージの使用を検討してください。辞書/リストを作成し、それらを json.dump() して TextProperty に保存することにより、それらをレコードに保存します。クライアントが呼び出すときは、単に TextProperties をクライアントに送信し、JSON.parse() を実行すると、クライアント側ですべてを把握します。この方法で JS で非常に大きな配列/オブジェクト処理を行いましたが、非常に高速です (特にインデックス付き配列)。ユーザーが何かをクリックすると、トランザクションを送り返してレコードを更新します。全体的な製品リストの更新、主要な顧客記録の更新などを処理するために、いくつかのプルまたはプッシュ キュー プロセスを設定します。

欠点の 1 つは、アプリから出る帯域幅が大きくなることですが、GAE の処理を​​節約できる可能性があることを考えると、このコストは最小限に抑えられると思います。このように構造化すると、get_by_id() を使用して、計画したインデックスとクエリのすべてまたはほとんどを置き換えることができる場合があります。アプリ内でjson.loads () と json.dumps() が非常に高速であることがわかりましたが、単純な辞書/リスト構造のみを使用しています。クエリの。もう 1 つの潜在的な問題は、非常に大きなオブジェクトがソフト メモリ制限に達する可能性があることです。これを避けるために、Json オブジェクトがかなりシンプルかつ軽量であることを確認してください (たとえば、Json 項目に製品の説明、サブオブジェクトなどを含めず、製品番号などの基本のみを含めます)。HTH、-スティーブ

于 2013-11-10T14:40:58.457 に答える