Comments 24
Если мы храним в нашем объекте дату, то в случае формата JSON у нас есть только один вариант хранения — это один из вариантов ISO-8601, и в строковом представлении.
А почему не хранить в JSON Unix-time? Будет то же самое число.
Возможно, вместе с датой/временем необходимо хранить часовой пояс.
Да, Вы правы можно хранить дату в UTC в числовом поле JSON, но тогда прийдется самим делать обертку сереализации/десериализации, а в случае BSON он делает все сам. Конечно не так просто использовать бонусы того, что хранится все в числовом формате, но не отметить того факта что Mongo это активно использует я не мог :)
UFO just landed and posted this here
При этом, если мы хотим отфильтровать нашу коллекцию JSON-объектов по датам, при обработке нам нужно будет превратить строки в формат Date и только после этого их сравнивать между собой.
Не нужно, идея ISO8601 в том, что моменты можно сравнивать как строки (если используется одна временная зона)
Формат tree не рассматривали?
Добавил tree в тест: https://github.com/nin-jin/js-serialization-tests/
- Парсер надо бы пооптимизировать.
- tree в читаемом виде занимает столько же места, сколько и минифициованный json.
"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\":\"Кот акробат\"}",
Что-то тут не так.
Рассматривали вариант добавить библиотеку для сжатия и передавать (хранить) сжатые данные?
UFO just landed and posted this here
Тут я конечно немного слукавил. Он не самый медленный если смотреть на него в общем смысле. Cbor по сути такой же медленный как и Bson, если посмотреть на результаты тестов JS для node, но при этом ведет себя совсем по другому в браузере. А если посмотреть на результаты тестов для Go, то, если например у MsgPack decode/encode приблизительно на одном уровне, то у Cbor с decode явный перекос в худшую сторону. А теперь представим что у нас есть два сервиса — один со своей стороны пакует данные и отсылает второму который их распаковывает. С такой разницей в распаковке и запаковке мы получим бутылочное горлышко на принимающей стороне, чего совсем бы не хотелось.
сравнения тестов не приведены к одной системе измерений: JS кажете в ops/sec, Go — в ns/op
все равно что скорость первого бегуна показывать в м/c, а второго — в наносекунд на метр
Да, Вы правы, но мы не сравнивали между собой результаты JS тестов и Go. Мы скорее смотрели как ведут себя сериализаторы в рамках каждого языка относительно друг друга, а также относительно различных этапов — emcoding, decoding и roundtrip.
Спасибо. Thrift интересен если брать его не только как сериализатор, а вместе с его RPC. Но вот при использовании её реализации (через TThreadedServer или TThreadedPoolServer) мы намучились с умиранием thrift серверов и другими проблемами со стабильностью сервисов, которые у нас вылезали при использовании. А если не брать RPC, то thrift далеко не самый удачный сериализатор.
Sign up to leave a comment.
Сериализация данных или диалектика общения: простая сериализация