Сериализация данных или диалектика общения: простая сериализация

[k12th]

Если мы храним в нашем объекте дату, то в случае формата JSON у нас есть только один вариант хранения — это один из вариантов ISO-8601, и в строковом представлении.

А почему не хранить в JSON Unix-time? Будет то же самое число.

[maximw]

Так timestamp всегда в UTC0 хранится. Так что часовой пояс может храниться отдельно.

[KyKyPy3uK]

Да, Вы правы можно хранить дату в UTC в числовом поле JSON, но тогда прийдется самим делать обертку сереализации/десериализации, а в случае BSON он делает все сам. Конечно не так просто использовать бонусы того, что хранится все в числовом формате, но не отметить того факта что Mongo это активно использует я не мог :)

[k12th]

Ну вы же пишите дальше, что де можно сортировать по этому полю просто как по числу — ну так и это и в JSON можно:) Но, конечно, с нативной поддержкой дат удобнее.

[KyKyPy3uK]

Простите за орфографию, исправим. Что касается вашего предложения, то да, так можно было сделать, но у нас стояла задача посмотреть что есть уже готового и не тратить усилия на написание своего велосипеда.

[vintage]

При этом, если мы хотим отфильтровать нашу коллекцию JSON-объектов по датам, при обработке нам нужно будет превратить строки в формат Date и только после этого их сравнивать между собой.

Не нужно, идея ISO8601 в том, что моменты можно сравнивать как строки (если используется одна временная зона)

Формат tree не рассматривали?

[vintage]

Добавил tree в тест: https://github.com/nin-jin/js-serialization-tests/

1. Парсер надо бы пооптимизировать.
2. tree в читаемом виде занимает столько же места, сколько и минифициованный json.

[KyKyPy3uK]

Спасибо, посмотрим на tree как будет время, но скажу сразу что для нас важен был факт доступности для различных языков. Не хочется самим реализовывать или портировать парсеры.

[vintage]

    "SENT_DATE": "2014-09-09 08:51:34",
    "SENT_DATE_TZ": "+04:00",

Это правильно писать так:

    "SENT_TIME": "2014-09-09T08:51:34+04:00",

    "PREVIEW_DATA": "{\"subject\":\"Кот акробат\"}",

Что-то тут не так.

[starius]

Раз речь зашла о протобуфе, то не смотрели ли также на gRPC?

[KyKyPy3uK]

Это только первая часть наших исследований, дальше мы рассмотрели уже более серьезные сериализаторы и в том числе смотрели и на gRPC. Чуть позднее думаю напишу чем у нас это закончилось и что мы выбрали в конечном итоге.

[Deosis]

Рассматривали вариант добавить библиотеку для сжатия и передавать (хранить) сжатые данные?

[KyKyPy3uK]

Тут я конечно немного слукавил. Он не самый медленный если смотреть на него в общем смысле. Cbor по сути такой же медленный как и Bson, если посмотреть на результаты тестов JS для node, но при этом ведет себя совсем по другому в браузере. А если посмотреть на результаты тестов для Go, то, если например у MsgPack decode/encode приблизительно на одном уровне, то у Cbor с decode явный перекос в худшую сторону. А теперь представим что у нас есть два сервиса — один со своей стороны пакует данные и отсылает второму который их распаковывает. С такой разницей в распаковке и запаковке мы получим бутылочное горлышко на принимающей стороне, чего совсем бы не хотелось.

[zelyony]

сравнения тестов не приведены к одной системе измерений: JS кажете в ops/sec, Go — в ns/op
все равно что скорость первого бегуна показывать в м/c, а второго — в наносекунд на метр

[KyKyPy3uK]

Да, Вы правы, но мы не сравнивали между собой результаты JS тестов и Go. Мы скорее смотрели как ведут себя сериализаторы в рамках каждого языка относительно друг друга, а также относительно различных этапов — emcoding, decoding и roundtrip.

[mantyr]

Поделитесь что имелось в виду под ops/sec, «operation per second/second» — почему-то так хочется прочитать.

[KyKyPy3uK]

ops/sec — это operations per second. Это не мой вариант сокращения, а то что выдает JSPerf. Честно говоря никогда не задумывался почему это пишется так.

[vintage]

operations/second

[rowdyro]

KyKyPy3uK, с почином тебя) Нормально копнул. А че от трифта отказались? Мне кажется как-раз для микросервисов он в темку.

[KyKyPy3uK]

Спасибо. Thrift интересен если брать его не только как сериализатор, а вместе с его RPC. Но вот при использовании её реализации (через TThreadedServer или TThreadedPoolServer) мы намучились с умиранием thrift серверов и другими проблемами со стабильностью сервисов, которые у нас вылезали при использовании. А если не брать RPC, то thrift далеко не самый удачный сериализатор.