GAE projektowanie ndb, wydajność i wykorzystanie powtarzalnych właściwości

Załóżmy, że mam galerię zdjęć, a zdjęcie może mieć potencjalnie 100 000 fanów. Który projekt ndb jest bardziej wydajny?GAE projektowanie ndb, wydajność i wykorzystanie powtarzalnych właściwości

class picture(ndb.model): 
    fanIds = ndb.StringProperty(repeated=True) 
    ... [other picture properties]

lub

class picture(ndb.model): 
    ... [other picture properties] 

class fan(ndb.model): 
    pictureId = StringProperty() 
    fanId = StringProperty()

Czy istnieją jakieś ograniczenia co do liczby elementów, które można dodać do NDB wielokrotnym nieruchomości i czy jest jakiś hit wydajność z przechowywania dużej ilości elementów w wielokrotnym nieruchomości? Jeśli użycie mniej powtarzalnych właściwości jest mniej efektywne, jakie jest ich przeznaczenie?

Źródło

2013-03-13 waigani

Nie ma nic wspólnego z odpowiedzią, ale proponuję przestrzegać konwencji. Nazwy klas 'CamelCase' i nazwy właściwości' lower_case_underscore' .. – Lipis

Również dla 'pictureId' użyj' ndb.KeyProperty (kind = picture) 'jak masz to w bieżącym modelu .. i' fanId = ndb.KeyProperty (kind = fan, repeat = True) 'zamiast' StringProperty' dla lepszej obsługi encji. – Lipis

Nie używaj powtarzających się właściwości, jeśli masz więcej niż 100-1000 wartości. (1000 prawdopodobnie już to popycha). Nie były zaprojektowane do takiego użytku.

Źródło

2013-03-14 19:26:03

Przeskakiwanie do tej odpowiedzi z innego pytania: (stackoverflow.com/questions/26740505). Nie należy używać powtarzanych właściwości dla więcej niż 10 elementów? Dlatego należy unikać relacji za pomocą powtarzających się kluczy. Poprawny? – EsseTi

@Guido Co powinniśmy użyć do przechowywania tego typu danych? – Napolean

@Napolean Myślę, że [NDB PickleProperty] (https://cloud.google.com/appengine/docs/python/ndb/properties#types) jest tym, czego szukasz. – cjlallana

Ogólnie v1 byłoby znacznie tańsze.

Pod względem kosztów odczytu/zapisu, płacisz za jednostkę pobrania/pisemnej, więc chcesz zmniejszyć liczbę podmiotów. wersja 1 będzie tańsza. Znacznie taniej, jeśli pobierasz każdego fana za każdym razem, gdy pobierasz zdjęcie.

Jednak każda jednostka jest ograniczona do 1 MB. Jeśli masz 100k + fanów, możesz trafić ten limit w zależności od wielkości twojego fanId. To nie liczy innych twoich danych zdjęciowych, więc możesz zrzucić ten limit 1 MB. Będziesz musiał dodać bardziej skomplikowany kod do obsługi przypadków przepełnienia.

Duże obiekty pobierają więcej czasu niż małe obiekty. Jeśli masz zamiar przyciągnąć wszystkich fanów naraz, v1 będzie lepszy. Jeśli masz zamiar pobrać tylko 5 fanów w jednym punkcie, v2 może być szybszy (tylko może). Jeśli z drugiej strony spróbujesz wyciągnąć 100k fanów, to zajmie to całe wieki.

Źródło

2013-03-13 15:35:06 dragonx

GAE projektowanie ndb, wydajność i wykorzystanie powtarzalnych właściwości

Odpowiedz

Powiązane problemy