2017-02-18 38 views
10

Chcę sprawdzić, czy proto-bufor jest najlepszym serializerem do mojego użytku, moje badania wykazały, że nic więcej się nie zbliża. Pracuję nad aplikacją java backend i Android (java), jednak możliwe jest, że inny klient zostanie utworzony w niedalekiej przyszłości, więc chcę mieć coś na platformę. brulion struktury danych:Ograniczenia buforów proto - ładowanie częściowych danych i udostępnianie ciągów znaków

message All { 
    repeated Line lines = 1; 
    Common common = 2; 
} 

Istnieje kilka setek obiektu linii, każda linia jest dość skomplikowane i zajmuje ~ 100 KB na własną rękę.

Dwa problemy, które widzę z buforem proto - przy uruchomieniu aplikacji Potrzebuję tylko części dostępnych danych - tylko "Wspólne" i podstawowe informacje z "Linii". Czy można załadować częściowe dane? - każdy obiekt linii zawiera setki ciągów znaków, ale ten sam ciąg występuje w kilku obiektach linii, więc chcę się mocno postarać, aby je udostępnić między tymi obiektami. Czy jest to możliwe na poziomie proto buf, czy też musi być częścią poziomu aplikacji?

Dzięki!

+0

Czy rozważałeś użycie wielu rozgraniczonych wiadomości? –

+0

"Czy można załadować częściowe dane" Nie. Należy je przechowywać w oddzielnych wiadomościach. –

+0

Ja się zakwalifikuję: możesz ominąć części bufora protokołu w formacie przewodowym, ponieważ znany jest rozmiar wiadomości. Ale brzmi to tak, jakbyś musiał przeczytać komunikaty "Line", aby określić odpowiednie treści do przeczytania. Być może mógłbyś mieć inne pole, na przykład 'repeat Line basic_lines'; ale nadal musisz napisać niestandardowy analizator składni, aby wyodrębnić tylko te rzeczy, które Cię interesują. –

Odpowiedz

0

Z ograniczonej specyfikacji, którą podałeś, trudno jest podać odpowiednią opinię. Stwierdziłeś, że dla twojego problemu najlepszym rozwiązaniem wydaje się być protobuf, ale nie możemy tego powtórzyć na podstawie podanych informacji.

Na podstawie tego, co napisałeś, powiedziałbym nawet, że prosta tablica bajtów GZIPped (lub JSON, ponieważ większość z nich można wydrukować (twierdzisz, że są String s)) może być lepsza dla ciebie ("ponowne wykorzystanie" wielu rzeczy przez obiekty liniowe => GZIP kołysze).

I jak oświadczyli inni: z protobuf nie można załadować "częściowych struktur danych" (w rzeczywistości twoja nie byłaby częściowa, o ile część "powtórzona" to np. Collection, ponieważ protobuf zajmie dbałość o segmentowanie danych w samej strukturze).

Chciałbym umieścić moje dwa centy na strumieniach GZIPped JSON (np. Z Jacksonem), oczywiście w tym przypadku zmniejszyłbyś przepustowość dzięki kosztom cykli procesora.

+1

Masz rację, że powinienem przedłużyć aby uzasadnić moje wymagania, powinienem to zrobić wkrótce. Jednak nie zgadzam się z tobą w kilku kwestiach: tablica bajtów to moje obecne podejście i mogę powiedzieć, że to naprawdę nie jest skalowalne i jest bardzo podatne na błędy. Mam zamiar gzipować wynik protobuf, więc i tak Json będzie większy. Ponadto deserializacja jsona na starszych telefonach spowoduje zauważalne opóźnienie (cykle procesora), a ładowanie wielu kopii tego samego ciągu zwiększy presję pamięci.Również moja struktura ma wielowymiarową tablicę int, która zajmie znacznie więcej miejsca w jsonie niż protobuf. – MichalMa

+0

W przypadku Jacksona możliwe jest również użycie odniesień do obiektów ⇒ ten sam ciąg znaków nie będzie występował dwukrotnie w zestawie;) Ale tak, zgadzam się, to naprawdę zależy od konkretnego przypadku użycia, w którym się znajdujesz. –

0

Odpowiadając na moje własne pytanie dotyczące ładowania częściowych danych. Nie próbowałem go jeszcze w praktyce, ale zastanawiam się, czy nie będzie działać co następuje:

message All { 
    repeated Line lines = 1; 
    Common common = 2; 
} 

message All_partial { 
    Common common = 2; 
} 

jak wszystkie pola w proto3 są opcjonalne, możemy mieć drugą definicję naszej strukturze, z „cząstkowych” pól . Jeśli zachowamy ten sam numer pola, mam nadzieję, że wszystko będzie dobrze.