0

私は現在、次のモデル構造を持っています (関連するもののみを以下に貼り付けます):

class userData(ndb.Model): 
    uuId = ndb.StringProperty()
    fId = ndb.IntegerProperty()
    name = ndb.StringProperty()
    email = ndb.StringProperty()
    gender = ndb.BooleanProperty()
    age = ndb.StringProperty()
    created = ndb.DateTimeProperty(auto_now_add=True)
    lastUpdate = ndb.DateTimeProperty()

class responses(ndb.Model):
    pId = ndb.KeyProperty(kind=shoes2)
    uuId = ndb.KeyProperty(kind=userData)
    act = ndb.StringProperty()
    date = ndb.DateTimeProperty(auto_now_add=True)

質問1

各ユーザーは、uuId エンティティ プロパティに入る iOS アプリ (例: AAAAAAAA-AAAA-AAAA-AAAA-000000000000) によって提供される一意のコードによって一意に識別されます。現在、「userData」種類のキー名としても設定しています。アイデアは、将来のクエリで、iOS が UUID を送信し、必要なのはキーでクエリを実行することだけであり、これは超高速です。ただし、ここでのトレードオフは、keyName が appengine で生成されたものの約 2 倍のサイズであるため、インデックス サイズが大きくなるということです。

ですから、私の最初の質問は、この場合、何をするのが最も効率的ですか? 大きなキーを使用しますか？または、より遅い読み取りクエリを使用しますか?

質問 #2 同様のトレードオフが応答テーブルでも発生します。現在、userData uuId と別のテーブルの別のキーを連結して、次のような応答エンティティのダブル サイズの keyName を形成しています。

AAAAAAAA-AAAA-AAAA-AAAA-000000000000agtzfnNmYmFja2VuZHINCxIGc2hvZXMyGI56DA

私がこれを行っているのは、「pID==x & uuID==y の場所」という質問をする多くのクエリを実行することがわかっているためです。それもひとつに凝縮。

皆さんはどう思いますか？大きなキーは、高速読み取りを行うための合理的な決定ですか? 読み取りは速くなりますか?

更新 私が検討しているもう1つのことは、次のコードです。

import md5
m=md5.new()
lKey = "AAAAAAAA-AAAA-AAAA-AAAA-000000000000agtzfnNmYmFja2VuZHINCxIGc2hvZXMyGI56DA"
m.update(lKey)
print m.hexdigest()

これは、より短い一意の ID "569e1b8c6e469d703c8e7c2a739c5812" を返します。MD5 は一方通行であることはわかっているので、ここでの唯一の危険は、後戻りできないことですが、それがリスクであるとはまったく確信していないので、実際にはこのルートを使用するだけかもしれません。皆さんはどう思いますか？

ありがとう！

4

2 に答える 2

1

ID と名前の間のストレージのコストの違いは、プログラミング時間のコストに比べればごくわずかです。そして、クエリ時間の違いが測定可能であるとは思えません。効率的にクエリできるようにデータを構造化することは重要ですが、それは重要な名前の問題ではありません。

重要なのは、キー名と追加する Cookie が、HTTP GET 要求が別の TCP/IP パケットに流出するのに十分な大きさであるかどうかです。これは、接続が遅いユーザーに影響を与えるためです。

于 2013-10-29T05:39:30.530 に答える
0

質問 1) 必ずキー ルックアップを使用してください。UUID を短くしたい場合は、重複する可能性のあるこの質問を参照してください。

質問 #2)祖先クエリを使用できますか? 複合キーを使用してレコードを保存および取得します。

key = ndb.Key(userData, uuId, otherTable, otKey)
response = responses(parent=key)
qry = responses.query(ancestor=key)

モデル コンストラクターについては、こちらで説明しています。

于 2013-11-05T02:37:33.797 に答える