エンティティ グループを決定するのは、書き込まれているエンティティに最も近い親の親族ですか、それとも最も遠い親の親族ですか? (質問 1 ) もし私が持っているなら、
2 つの異なるエンティティを書き込むための 2 つの同時要求。この例では、どちらも Data エンティティ (キー '2') の直接の親を持ち、次の祖先を持ちます。
Person:9 > Collection:3 > Script:4 > Data:2 > Record of Tom Cruise
Person:9 > Collection:3 > Script:4 > Data:2 > Record of Shia La Boef
どちらの場合も、両方とも同じエンティティ グループに属し、エンティティ Person:9 またはエンティティ Data:2 に固定されています。エンティティ グループの正しい決定子は、Person:9 と Data:2 のどちらですか? また、Data:2 の子孫に2 種類のエンティティ、たとえば Record と Scheme がある場合、すべての Record エンティティと Scheme エンティティは、Data:2 によって固定された同じエンティティ グループに属しますか、または異なる種類であるため、次のエンティティ グループに属します個別のエンティティ グループ? (問2 )
ちなみに、エンティティ グループを決定するのが Person:9 であり、親の下の異なる種類がその親の下で異なるエンティティ グループを形成しない場合、Person:9 から派生したものはすべて同じエンティティ グループであり、記述する必要があります。連続で、恐怖
この例では、同じエンティティ グループに対して同じ種類のエンティティのこれらの書き込みを同時に実行しているため、これらの書き込みは順次適用されるため、同時に適用できる場合よりも「2 倍の時間」がかかります。
この「倍増」した時間に対する適切な解決策は何ですか? (質問 3 -- オプション! )
私は次のことを考えました：
2 つの個別の書き込みは 2 つの個別のクライアント インスタンスによって開始される必要があることがわかっているため、次のように、書き込みを行うクライアント インスタンスを表すチェーンにさらに先祖を追加できます。
Person:9 > Collection:3 > Script:4 > Data:2 > **Client:92** > Record of Tom Cruise
Person:9 > Collection:3 > Script:4 > Data:2 > **Client:37** > Record of Shia La Boef
このようにして、書き込みは異なるエンティティ グループに属し (グループを固定する Person:9 の仮説が間違っている限り)、常に同時に実行できます。AppEngineer/専門家はこれについて検討できますか? （質問4）
さらに、個別のクライアントはデータストアに対してシリアル リクエストのみを行うことができるという制限を適用しているため、パフォーマンスに影響を与えることなく、単一のクライアントによる書き込みが毎秒 1 回以上発生する必要がないことを保証できます。それは機能し、パフォーマンスへの影響がゼロであることを意味し、十分な数の個別のクライアント (および十分なクォータ) がある限り、HTTP が転送できる速度でデータストアにできるだけ多くの書き込みを行うことができます。AppEngineer/専門家はこれについて検討できますか? (問5 )
このグループ分割アプローチで私が目にする唯一の問題は、Data:2 の親の下にあるレコード エンティティのクエリが、レコードが意味的に関連しているにもかかわらず、異なるクライアントによって分離されているという事実によって複雑になっていることです。したがって、すべてのレコードを収集するには、まずすべてのクライアントを収集し、次にそこにあるすべてのレコードを収集する必要があります。この種の「クエリした子のすべての子をクエリする」クエリを実行すると、これが途方もなく恐ろしいパフォーマンスへの影響を引き起こすかどうか、誰にもわかりますか...? AppEngineer/専門家はこれについて検討できますか? （問6）