Pull to refresh

Comments 24

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

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

Возможно, вместе с датой/временем необходимо хранить часовой пояс.
Так timestamp всегда в UTC0 хранится. Так что часовой пояс может храниться отдельно.
Верно. Можно сделать 2 предположения:
1. Не удобно хранить. 2 поля вместо одного.
2. Придется конвертировать при каждом выводе. Лишний расход ресурсов.

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

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

UFO just landed and posted this here
Простите за орфографию, исправим. Что касается вашего предложения, то да, так можно было сделать, но у нас стояла задача посмотреть что есть уже готового и не тратить усилия на написание своего велосипеда.
При этом, если мы хотим отфильтровать нашу коллекцию JSON-объектов по датам, при обработке нам нужно будет превратить строки в формат Date и только после этого их сравнивать между собой.

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


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

Спасибо, посмотрим на tree как будет время, но скажу сразу что для нас важен был факт доступности для различных языков. Не хочется самим реализовывать или портировать парсеры.
    "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\":\"Кот акробат\"}",

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

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

Это только первая часть наших исследований, дальше мы рассмотрели уже более серьезные сериализаторы и в том числе смотрели и на gRPC. Чуть позднее думаю напишу чем у нас это закончилось и что мы выбрали в конечном итоге.
Рассматривали вариант добавить библиотеку для сжатия и передавать (хранить) сжатые данные?
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.
Поделитесь что имелось в виду под ops/sec, «operation per second/second» — почему-то так хочется прочитать.
ops/sec — это operations per second. Это не мой вариант сокращения, а то что выдает JSPerf. Честно говоря никогда не задумывался почему это пишется так.
KyKyPy3uK, с почином тебя) Нормально копнул. А че от трифта отказались? Мне кажется как-раз для микросервисов он в темку.

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