Порівнюємо два формати серіалізації даних: 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