NDB HRD事務，哪個祖先決定實體組？

Question

它是正在寫入的實體的最接近的還是最遠的親屬親屬，它決定了實體組？ （問題1）有關，如果我有，

兩個同時的請求寫入兩個不同的實體，在此示例中，具有直接父數據實體（與鍵「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？另外如果有兩個實體，從數據：2開始，例如記錄和方案，所有記錄和方案實體都屬於同一個實體組，由數據：2錨定，或者由於不同類型，屬於單獨的實體組？ （問題2）

順便提及，如果是人：9，其確定一個父下所述實體組，和不同類型的不形成親下不同實體組，然後一切從人後裔：9因爲在這個例子中，我正在執行這些相同類型的實體同時寫入同一個實體組，它們將被應用因此，如果可以同時應用，則需要「雙倍的時間」。

什麼是這種「倍增」時間的好方法？ （問題3 - 可選！）

我想到了以下幾點：

因爲我知道，這兩個單獨的寫操作必須由兩個獨立的客戶端實例來啓動，我可以添加一個進一步的祖先到鏈，它代表客戶機實例做寫作，就像這樣：

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 

這樣寫操作將屬於不同的實體組（只要人的假設：9錨固組是錯誤的），因此，總是可以同時執行。 AppEngineer/expert可以衡量這個嗎？ （問題4）

另外，由於我強制限制，即獨立的客戶端只能進行連續請求的數據存儲，並且不會造成任何性能的影響，通過一個單一的客戶端所做的任何寫操作永遠需要發生超過我可以保證每秒1次，上述方法如果有效，將意味着有零性能影響並且只要我有足夠的獨立客戶端（並且他足夠的配額）我可以對數據存儲進行多次寫入與HTTP可以承載的速度一樣快。 AppEngineer/expert可以衡量這個嗎？ （問題5）

我這個組拆分方法看到的唯一問題是，查詢的數據在記錄實體：2母，現在是由複雜的，因爲，即使記錄在語義上是相關的，它們是由不同的客戶端分開的。所以爲了收集所有記錄，我需要先收集全部客戶端，然後收集所有記錄。任何人都可以看到這是否會造成巨大的可怕的性能影響，做這種「查詢你剛纔查詢的孩子的所有孩子」查詢...？ AppEngineer/expert可以衡量這個嗎？ （Question 6）

Answer 1

這裏有一些誤解。

首先，文檔對於實體組的構成非常明確：在根實體下它是的所有內容。

但是，我不知道你在哪裏得到這樣的想法，即在一個實體組中寫入的內容在某種程度上比外部的更「串行」。文檔不會這麼說，或者暗示它。它所說的唯一的事情就是寫入單個實體組的速度不會超過每秒1次。

其餘的問題根本沒有意義：在鏈中添加另一個元素不會改變根實體。

我不知道爲什麼你首先需要這麼深的實體組鏈。文檔的advice on scaling用於保持實體組較小。如果每個葉子實體只能由一個客戶端寫入，那麼聽起來客戶端本身應該是根，而其他路徑根本不應該是祖先的一部分：或許您可以使用ReferenceProperty來引用其中一個或多個實體通過其密鑰。