« Rev
@gogolang   879
Fwd »


Aleksandr
один
Alexander
Хаха, да, они все почти одинаковые. WebStorm, PhpStorm, IntelliJ
Pawel
Надо как можно сильнее запаковать трафик. Будет ли gob для этого адекватным решением, или надо мутить какой нибудь protobuff ?
Aleksandr
В rar паковать
Aleksandr
Винраром
Pawel
это троллинг был?
Pawel
или винрар умеет в структуры данных Го?
Pawel
Пачка жсон с "Content-Encoding": "gzip" весит примерно 5 мб. Это много, учитывая что такие пачки идут нон стопом в клиент. Если сериализовать по отдельность каждое значение поля структуры в поток байтов, то получается примерно 300 кб. Но это говнокод.
Alexander
По-моему, в данном случае загонять всё в json это и есть говнокод. Хотя бы потому что его создавать и потом декодировать - это совершенно ненужная работа
Alexander
В сторону BSON может посмотреть? https://github.com/pkg/bson
Pawel
и чем это отличается принципиально от жсон + "Content-Encoding": "gzip"?
Alexander
эффективностью и отсутствием ненужного превращения данных в строку и обратно
Alexander
Если у данных энтропия низкая, то можно еще и BSON пожать gzip-ом. Ну это уже зависит от данных
Pawel
да пофигу на эффективность. меня только размер волнует. А с чего ему быть на много меньше в bson чем зазипованного json, если наименования пропертей передаются в обоих случаях?
Bogdan
Приветствую У меня слайс с одной и той же структуры. У этой структуры есть поле ID. Как мне преобразовать этот слайс структур в слайс интов от поля ID?)
Bogdan
Может какой то красивый способ есть, а не что бы писать все это руками)
Alexander
да пофигу на эффективность. меня только размер волнует. А с чего ему быть на много меньше в bson чем зазипованного json, если наименования пропертей передаются в обоих случаях?
Потому что Если сериализовать по отдельность каждое значение поля структуры в поток байтов, то получается примерно 300 кб. Или json сильно больше только из-за большого количества свойств, чьи имена передаются? Что-то слабо верится, что там данных на 300кб, а названий свойств на десятки мегабайт (если 5мб - это _сжатый_ json)
Bogdan
или говэй и здесь применять?)))
Pawel
это такой жсон
Alexander
790 кб распакованный, 33кб в gzip
Pawel
это сегодня футбола нет практически . А вчера был такой как я сказал
Pawel
там действительно как ты сказал - большое количества свойств, чьи имена передаютс
Alexander
Т.е. там реально был json в 120 мегабайт размером? И сервер не подавился?
Alexander
5мб * (790/33) = 120мб
Pawel
хз скока там на сервере, я не проверял. Ну пока что мене до балды как там сервер это тянет, сейчас нужно именно с форматом сериализации определиться
Pawel
Я так понимаю что gob как и жсон включает все имена пропертей и особо смысла его использовать нет
Pawel
вот думаю стоит ли манаться с протобуфом или asn1
Pawel
5мб * (790/33) = 120мб
не факт что этот множитель - констатнта
Alexander
не факт, конечно, но порядок примерно такой будет. Сжатие в 24 раза - вполне ожидаемо для столь регулярного текста.
Alexander
протобуф названия свойств не передает?
Alexander
Вообще, конечно, вот, на выбор - https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats
Anonymous
Сейчас в основном юзают protobuf, flatbuffers и messagepack протоколы сериализации
Pawel
Сейчас в основном юзают protobuf, flatbuffers и messagepack протоколы сериализации
ну это в основном фреймворки же типа grpc и ZeroMQ. хотя может оно и всем так надо, я вот пока не понял этого
Pawel
не факт, конечно, но порядок примерно такой будет. Сжатие в 24 раза - вполне ожидаемо для столь регулярного текста.
Небольшая поправка, 5 МБ - это не сжатый объём, я вот щас это понял. Но это всё равно много
Anonymous
Это протоколы) А вот grpc это уже фреймворк использующий под капотом RPC + protobufs
Pawel
Это протоколы) А вот grpc это уже фреймворк использующий под капотом RPC + protobufs
а почему например не использовать asn.1? чем он хуже чем protobuff ?
Slava
Протобуф моднее
Vladislav
Экосистема вокруг протобуфа побольше.
Pawel
Протобуф моднее
зато asn.1 есть в ГОСТе !!!
Pawel
)))
Vladislav
зато asn.1 есть в ГОСТе !!!
А это точно +?
Pawel
А это точно +?
http://docs.cntd.ru/document/1200031914
Антон
а почему например не использовать asn.1? чем он хуже чем protobuff ?
ну с asn.1 сравнивать точно бессмысленно, т.к. это лишь спецификация, а вот der, per и тп, интересно
Pawel
ну с asn.1 сравнивать точно бессмысленно, т.к. это лишь спецификация, а вот der, per и тп, интересно
не понял, в каком смысле он только лишь, а протобуф не только лишь. asn1 описывает формат представления данных, он есть в стандартной гошной либе. что не так и чем протобуф лучше?
Антон
не, asn.1, на сколько я знаю, не описывает как конкретно будут сериализованы данные
Alexander
Небольшая поправка, 5 МБ - это не сжатый объём, я вот щас это понял. Но это всё равно много
Тогда в гзипе он будет 200-250 кб. Не так уж и много. Меньше сырых двоичных данных
Антон
аля у asn.1 может быть множество сериализаторов/десериализаторов типа der
Alexander
Хотя двоичные данные тоже можно сжать, конечно
Антон
а protobuf включает в своё описание и способ сериализации/десериализации
Anonymous
Хотя двоичные данные тоже можно сжать, конечно
Это если есть избыточность. Попроуй сжать например png
Alexander
Тут вполне определенные данные. Без картинок
Anonymous
Это был как пример. В json есть избыточноть, а еще повторяемость от сообщения к сообщению ключей
Alexander
Кстати, да, интересная мысль - сжимать данные с учетом предыдущего пакета. Этакий мпег для json
Anonymous
Это и делает protobuffer, flatbuffer и ему подобные
Alexander
О_о, правда что ли?
Pawel
Спасибо за помощь, парни. Буду юзать protobuff
Anonymous
Ну да, а еще ZigZag кодирование и другие трюки
Anonymous
Если есть возможность лучше flatbuffer. Он быстрее
Alexander
Спасибо за помощь, парни. Буду юзать protobuff
Сделай для начала тест на размер данных и скорость декодирования и сравни с json. А то обидно будет потратить время на переделку, а результат получить не лучше, чем просто json.
Антон
Кстати, да, интересная мысль - сжимать данные с учетом предыдущего пакета. Этакий мпег для json
А если бакенд упал? Прошлого сообщения не помнит. Или балансировщик отправил следующее сообщение другому экземпляру бакенда? Как он его десериализует?
Антон
нету такого в протобуфе
Alexander
Понятно, что это сопряжено с кучей проблем. Это я так, просто мыслью поделился
Антон
и повторюсь, в условиях гугла с множественном резервированием и распределением нагрузки запросы могут идти совсем непоследовательно
Anonymous
Он его может хранить где угодно, например в localStorage
Антон
понятно. Это не про протобуф.
Anonymous
Слушай probobuf родился в google и гугл им активно пользуется) Думаю такая компания все хорошо продумала
Anonymous
На сервер протокол буффера храниться в отдельном файле или заинлайнен. После того, как сервер подыметься он все равно вычитает этот протокол. И да, возможно вы не верно поняли protobuffer это не delta inter-message сжатие, он просто хранит все ключи в протоколе, а ссобщение выстраивается в нужном порядке следуя декларативному описанию в нем
Антон
воот. Просто из вашей переписки выше можно сделать вывод что протобуф зависит от контекста
Pawel
Если есть возможность лучше flatbuffer. Он быстрее
вот это решает кмк - FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data
Pawel
таки да, это лучше
Pawel
не, asn.1, на сколько я знаю, не описывает как конкретно будут сериализованы данные
тем не менее в стандартной либе это реализовано как надо быть - https://play.golang.org/p/SKCGbC-OFkZ
Антон
тем не менее в стандартной либе это реализовано как надо быть - https://play.golang.org/p/SKCGbC-OFkZ
Package asn1 implements parsing of DER-encoded ASN.1 data structures, as defined in ITU-T Rec X.690.
Антон
DER
Pawel
Посмотрел protobuff и FlatBuffers и прифигел - дрочбы в присядку там не мало однако. Почему нельзя взять структуру Го и сгенерить весь необходимый бойлерплейт - не понятно
Антон
Этим мне нравится дока го, она точно описывает, что собственно реализует модуль
Pawel
DER
лично меня это более чем исчерпывающе устраивает
« Rev
@gogolang   879
Fwd »