在AppEngine中使用更短的屬性名稱是否被認爲是一種好的做法？

根據多個來源如this presentation by Johan Euphrosine，AppEngine將屬性名稱與數據和索引一起存儲。正因爲如此我使用縮短的種類和屬性名的版本，在數據存儲，節省空間的磁盤：在AppEngine中使用更短的屬性名稱是否被認爲是一種好的做法？

@Entity("p") 
public class PersistentClass { 

    @Property("n") 
    private String name; 

}

該實體的索引條目將是線：

PersistentClass:1 
PersistentClass:name:foo:PersistentClass:1

相比有（申請縮短屬性名）：

p:1 
p:n:foo:p:1

這是73％的壓縮，但是這是一種理論上的做法，難以推進，而不平臺進行的內部知識R M。我的問題是：這是常見的做法嗎？有沒有人測量過在NoSQL中儲存的縮短的屬性名稱，特別是AppEngine？

來源

2013-10-28 Nacho Coloma

從我記得您可以在應用程序中使用的「名稱」和您在數據存儲區中使用的名稱（以Python的形式）。簡而言之，如果你存儲數百萬條記錄，然後你的節省將是「數記錄X字符串的長度」的每一個。所以，如果你預計有很多很多的記錄.... –

我覺得長屬性名的數據存儲中的影響是類似於JSON的問題 - 有短屬性名稱將幫助你倆當存儲你的實體在DS和當它發送到您的客戶端應用程序。 – Tom

回答這個問題最簡單的方法可能是通過一個簡單的測試。我只是將一個示例應用程序投入Gist（https://gist.github.com/jeremydw/7201456），其中我測試了一個具有長屬性名稱的模型的2000個實體的創建，以及2000個具有單字符屬性名稱的模型的實體。

使用數據存儲統計模塊（https://developers.google.com/appengine/docs/python/datastore/stats）確認較長的屬性名稱佔用更多的磁盤空間。（在這個特定實驗中爲278KB）。還有一個有趣的測試是測量創建或檢索實體的時間，因爲這也會影響應用程序的速度。

這裏有一個測試的結果：

name: l_PersistentClass2, bytes: 1507635 
name: super_very_long_property_name_PersistentClass1, bytes: 1787607 
difference: 279972 bytes

來源

2013-10-28 18:05:34 jeremydw

太棒了。如果我正確讀取此測試，它只會對數據使用的存儲進行求和，而不是索引。 –

是的，看着我的devappserver的數據存儲統計數據（使用數據存儲瀏覽器），該指數的大小（以字節爲單位）對於用長屬性名的種類和短屬性名相同。這樣，索引大小是相同的，存儲是不同的，RPC時間（潛在地，可能）不同的。現在，我們可以從中得出一些有趣的結論，但最好的做法可能是分析您的實際應用，以查看差異是否與價格和速度有關。 :) – jeremydw

每個實體的差異是140個字節，其是IMO忽略不計。它甚至不應該在RPC上可見。這聽起來像是一個不成熟的優化。 –

不妥的地方 - 這應該是一個完全可以接受的做法。

它是否真的爲你節省了錢是另一回事。這當然完全取決於應用程序，但我們最大的開支是數據庫操作和帶寬。經過兩年的運營（不斷儲存數據），我們的總數據存儲費用僅佔總費用的5％。

您應該確實做一點calc以確定這是否會對您的總GAE成本產生實際影響。

來源

2013-10-28 18:07:52

是的，這通常是一個好主意。

這可能對索引影響可以忽略不計，我不認爲索引實際上使用每個索引條目的屬性名稱。

但是，屬性名稱用於存儲的每個實體中。我現在沒有數字，但是我用一個具有大約80個整數屬性的實體運行測試。在這種情況下，長屬性名稱在實際整數值之上佔有相當大的開銷，並且使用1或2個字符屬性名稱會顯着減少實體的大小。

但是，我只有幾千個這樣的實體存儲，所以對成本的實際影響是最小的。但是現在每次在數據存儲視圖中顯示這些實體時，我都必須提供我的源代碼來確定哪個屬性是哪個屬性。

來源

2013-10-28 18:53:26 dragonx

在AppEngine中使用更短的屬性名稱是否被認爲是一種好的做法？

回答

相關問題