Порівнюємо два формати серіалізації даних: Protobuf vs JSON
Привіт, мене звати Ярослав. Я займаюся розробкою в компанії Evrius . У цій статті ми порівняємо два формати серіалізації даних та ознайомимося з інструментами, які оптимізують її виконання. Інформація буде цікавою гоферам, які використовують серіалізацію для збереження та передачі даних.
Ця стаття є продовженням задачі, яку я розв'язків язував в офісі (тут ностальгійка, бо зараз працюю дистанційно).
Приклади коду доступні в репозиторії .
Історичні рішення, які треба переписати
На практиці це здається пробачимо: з'єднання явилася завдання, її виконали швидко й легко, використовуючи стандартні інструменти, і всі задоволені. А з часом, хай за рік, змінились умови, збільшився трафік тощо, і ті красиве рішення, що було спочатку, треба переписати. Знайомо?
JSON to Protobuf
У моєму робочому проєкті в одному з мікросервісів є операція, яка на кожен запит від користувачів зберігає JSON в key-value базу даних на три години. За рік користувачів стало більше, і ці операції збереження почали перевантажувати мережу (гарний початок для страшного оповідання).
Для зменшення трафіку і розміру БД ми вирішили замінити JSON на Protobuf. У результаті об'єм трафіку зменшився на третину, і це розв'язків язало проблему.
Альо перед тім, як замінити, провели мікробенчмарки, якими й хочу поділитись далі.
JSON vs Protobuf, стандартна реалізація через рефлексію
У цьому мікробенчмарку Protobuf справді виграє у JSON. Але ми дамо JSON другий шанс у наступних порівняннях, щоб побачити можливості для розвитку у Protobuf.
Приклади структур буду скорочувати в ... , а повні можна глянути в репозиторії , де я проводив тести.
Для прикладу візьмемо GitHub API :
{
 "id": 23096959,
 "node_id": "MDEwOlJlcG9zaXRvcnkyMzA5Njk1OQ==",
 "name": "go",
 "full_name": "golang/go",
 "private": false,
 "owner": {
 // ...
},
 // ...
 "license": {
 // ...
},
 // ...
 "organization": {
 // ...
},
 "network_count": 10164,
 "subscribers_count": 3448
}
За допомогою онлайн-інструмента JSON to Go конвертуємо попередньо отримані дані в Go-структуру, яку будемо використовувати для серіалізації:
type Repository struct {
 ID int `json:"id"`
 // ...
 Owner Owner `json:"owner"`
 // ...
 License License `json:"license"`
 // ...
 Organization Organization `json:"organization"`
 // ...
}
type Owner struct {
 Login string `json:"login"`
 ID int `json:"id"`
 // ...
}
type License struct {
 String Key `json:"key"`
 // ...
}
type Organization struct {
 Login string `json:"login"`
 ID int `json:"id"`
 // ...
}
Через інший, ще сирий інструмент JSON to Protobuf конверую в:
syntax = "proto3";
package protos;
message Repository {
 uint32 id = 1;
 // ...
 Owner owner = 6;
 // ...
 License license = 69;
 // ...
 Organization organization = 75;
 // ...
}
message Owner {
 string login = 1;
 uint32 id = 2;
 // ...
}
message License {
 string key = 1;
 // ...
}
message Organization {
 string login = 1;
 uint32 id = 2;
 // ...
}
Я підготував і заповнив структури даними з JSON, які отримав з GitHub API раніше. Тепер можемо провести бенчмарки:
import (
"encoding/json"
"github.com/stretchr/testify/require"
"gitlab.com/go-yp/proto-vs-json-research/models/fulljson"
"testing"
)
func BenchmarkRepositoryMarshalJSON(b *testing.B) {
 var repository = &jsonExpectedRepository
 for i := 0; i < b.N; i++ {
 _, _ = json.Marshal(repository)
}
}
func BenchmarkRepositoryUnmarshalJSON(b *testing.B) {
 var fixture = []byte(jsonRepositoryFixture)
 for i := 0; i < b.N; i++ {
 var repository = &fulljson.Repository{}
 json.Unmarshal(fixture, repository)
}
}
import (
"encoding/json"
"github.com/golang/protobuf/proto"
"github.com/stretchr/testify/require"
"gitlab.com/go-yp/proto-vs-json-research/models/protos"
"testing"
)
func BenchmarkRepositoryMarshalProto(b *testing.B) {
 for i := 0; i < b.N; i++ {
 _, _ = proto.Marshal(protoExpectedRepository)
}
}
func BenchmarkRepositoryUnmarshalProto(b *testing.B) {
 var repository = protoExpectedRepository
 var content, marshalErr = proto.Marshal(repository)
 require.NoError(b, marshalErr)
b.ResetTimer()
 for i := 0; i < b.N; i++ {
 var repository = &protos.Repository{}
 _ = proto.Unmarshal(content, repository)
}
}
| Назва тесту | Середній годину ітерації | Виділення пам'яті | 
| BenchmarkRepositoryMarshalJSON | 13172 ns/op | 6146 B/op 1 allocs/op | 
| BenchmarkRepositoryUnmarshalJSON | 51246 ns/op | 6256 B/op 105 allocs/op | 
| BenchmarkRepositoryMarshalProto | 8302 ns/op | 4208 B/op 8 allocs/op | 
| BenchmarkRepositoryUnmarshalProto | 9357 ns/op | 5968 B/op 94 allocs/op | 
Як і очікували, Protobuf швидше серіалізує та потребує менше пам'яті.
JSON серіалізується в 5488 байтів, а Protobuf у 3811 байтів. У нашому прикладі на 30% менше пам'яті займає Protobuf.
Розглянємо «таємничний» 1 allocs/op при серіалізації JSON у бенчмарку BenchmarkRepositoryMarshalJSON . Стандартна бібліотека encoding/json має кеш sync.Pool , який перевикористовує раніше виділену пам'ять:
package json
// ...
var encodeStatePool sync.Pool
func newEncodeState() *encodeState {
 if v := encodeStatePool.Get(); v != nil {
 e := v.(*encodeState)
e.Reset()
 // ...
 return e
}
 return &encodeState{ptrSeen: make(map[interface{}]struct{})}
}
// ...
func Marshal(v interface{}) ([]byte, error) {
 e := newEncodeState()
 err := e.marshal(v, encOpts{escapeHTML: true})
 if err != nil {
 return nil, err
}
 buf := append([]byte(nil), e.Bytes()...)
encodeStatePool.Put(e)
 return buf, nil
}
Таким чином отримуємо алокацію пам'яті buf := append([]byte(nil), e.Bytes()...) на всіх ітераціях циклу, окрім першої, де створюється encodeState .
Відсутня можливість виключити доданий кеш , щоб перевірити справжнє число алокацій.
JSON з кодогенерацією та перспективи серіалізації Protobuf
Коли тільки почав вчити Golang за уроками з «Техносфери» , то дізнався, що стандартна JSON-серіалізація в Golang під капотом зроблена через рефлексію, яка використовує багато ресурсів у високонавантажених системах. Так розробникі витворили свою реалізацію JSON-серіалізації через кодогенерацію easyjson . Вона виконується швидше, потребує менше пам'яті та відбувається без рефлексії на момент виконання коду.
Для нашої структури Repository згенеруємо код, який буде серіалізувати в JSON.
Спершу встановимо easyjson :
go get -u github.com/mailru/easyjson/...
Тепер до структури Repository додамо службовий коментар easyjson:json . Він потрібний, щоб easyjson побачив, для якої структури треба згенерувати код:
//easyjson:json
type Repository struct {
 ID int `json:"id"`
 // ...
 Owner Owner `json:"owner"`
 // ...
 License License `json:"license"`
 // ...
 Organization Organization `json:"organization"`
 // ...
}
type Owner struct {
 Login string `json:"login"`
 ID int `json:"id"`
 // ...
}
type License struct {
 String Key `json:"key"`
 // ...
}
type Organization struct {
 Login string `json:"login"`
 ID int `json:"id"`
 // ...
}
І запустимо кодогенерацію:
easyjson ./models/fulljson/repository.go
~/go/src/gitlab.com/go-yp/proto-vs-json-research ??? models ??? fulljson ??? repository_easyjson.go [+] ??? repository.go
У згенерованому файлі repository_easyjson.go нам будуть потрібні методи для серіалізації структури Repository :
// Code generated by easyjson for marshaling/unmarshaling. DO NOT EDIT.
// ... 
// MarshalJSON supports json.Marshaler interface
func (v Repository) MarshalJSON() ([]byte, error) {
 // ...
}
// ...
// UnmarshalJSON supports json.Unmarshaler interface
func (v *Repository) UnmarshalJSON(data []byte) error {
 // ...
}
Оновимо бенчмарки, які використовують згенеровані методи, і запустимо:
func BenchmarkRepositoryEasyMarshalJSon(b *testing.B) {
 for i := 0; i < b.N; i++ {
 _, _ = jsonExpectedRepository.MarshalJSON()
}
}
func BenchmarkRepositoryEasyUnmarshaljson(b *testing.B) {
 var fixture = []byte(jsonRepositoryFixture)
 for i := 0; i < b.N; i++ {
 var repository = fulljson.Repository{}
 _ = repository.UnmarshalJSON(fixture)
}
}
| Назва тесту | Середній годину ітерації | Виділення пам'яті | 
| BenchmarkRepositoryMarshalJSON | 13172 ns/op | 6146 B/op 1 allocs/op | 
| BenchmarkRepositoryUnmarshalJSON | 51246 ns/op | 6256 B/op 105 allocs/op | 
| BenchmarkRepositoryEasyMarshalJSon | 9718 ns/op | 6867 B/op 8 allocs/op | 
| BenchmarkRepositoryEasyUnmarshaljson | 13996 ns/op | 4128 B/op 86 allocs/op | 
| BenchmarkRepositoryMarshalProto | 8302 ns/op | 4208 B/op 8 allocs/op | 
| BenchmarkRepositoryUnmarshalProto | 
9357 ns/op | 5968 B/op 94 allocs/op | 
Як бачимо, ефективність десеріалізації значно підвищилась. А вісь серіалізація стала використовувати більше пам'яті через відсутність схожого кешу, як у стандартної бібліотеки.
Епілог
Коли завершивши статтю і відіслав друзям, від Павла дізнався, що вже є інструмент protoc-gen-gogofaster , який працює без рефлексії.Protobuf-серіалізація без рефлексії
Ми під'єднаємо protoc-gen-gogofaster , згенеруємо новий код для Protobuf-серіалізації, оновимо бенчмарки та порівняємо результати.
Під'єднуємо та генеруємо (Makefile):
gogofaster: go get github.com/gogo/protobuf/protoc-gen-gogofaster proto: protoc -I . protos/*.proto --gogofaster_out=models
make gogofaster
make proto
У результаті файл repository.pb.go буде мати 6576 рядків коду замість 1192, які були згенеровані стандартним інструментом protoc .
Оновимо бенчмарки:
func BenchmarkRepositoryFasterMarshalproto(b *testing.B) {
 for i := 0; i < b.N; i++ {
 _, _ = protoExpectedRepository.Marshal()
}
}
func BenchmarkRepositoryFasterUnmarshalproto(b *testing.B) {
 var content, marshalErr = protoExpectedRepository.Marshal()
 require.NoError(b, marshalErr)
{
 var repository = protos.Repository{}
 var unmarshalErr = repository.Unmarshal(content)
 require.NoError(b, unmarshalErr)
 require.Equal(b, protoExpectedRepository, &repository)
}
b.ResetTimer()
 for i := 0; i < b.N; i++ {
 var repository = protos.Repository{}
 _ = repository.Unmarshal(content)
}
}
| Назва тесту | Середній годину ітерації | Виділення пам'яті | 
| BenchmarkRepositoryMarshalJSON | 13172 ns/op | 6146 B/op 1 allocs/op | 
| BenchmarkRepositoryUnmarshalJSON | 51246 ns/op | 6256 B/op 105 allocs/op | 
| BenchmarkRepositoryEasyMarshalJSon | 9718 ns/op | 6867 B/op 8 allocs/op | 
| BenchmarkRepositoryEasyUnmarshaljson | 13996 ns/op | 4128 B/op 86 allocs/op | 
| BenchmarkRepositoryMarshalProto | 8302 ns/op | 4208 B/op 8 allocs/op | 
| BenchmarkRepositoryUnmarshalProto | 9357 ns/op | 5968 B/op 94 allocs/op | 
| BenchmarkRepositoryMarshalProto | 8302 ns/op | 4208 B/op 8 allocs/op | 
| BenchmarkRepositoryUnmarshalProto | 9357 ns/op | 5968 B/op 94 allocs/op | 
| BenchmarkRepositoryFasterMarshalproto | 1705 ns/op | 4096 B/op 1 allocs/op | 
| BenchmarkRepositoryFasterUnmarshalproto | 
3894 ns/op | 4784 B/op 89 allocs/op | 

Як бачимо, результати стали кращими.
Вже після написання статті дізнався про інструмент, який мені потрібнен — protoc-gen-gogofaster . Сподіваюсь, цей простий мікробенчмарк стані корисним, коли захочете мігрувати з JSON-у на Protobuf, а також зможете його використовувати як шаблон для своїх досліджень. У цій статті мені вдалось поєднати дві речі: обмін досвідом та можливість краще розібратись з інструментами.
Опубліковано: 13/05/20 @ 10:00
Розділ  Різне  
Рекомендуємо:
Essential Factors to Consider When Writing an Essay
 User Acceptance Testing: як організувати процес менеджеру
 It is time for you waiting to quit and begin to work difficult to increase your publishing that is educational.
 Як і навіщо IT-фахівці розвивають українськомовний YouTube
 C++ дайджест #27: Continuous Integration