как раз с JSON ты нихуя не можешь сделать, пока его не "десереализируешь" в память. про protobuf не скажу. а по BSON ты можешь прекрасно бродить отступами, т.к. размер объекта пишется перед ним.
судя по формату MsgPack — BSON эффективнее, т.к. в нём хранится размер всего документа, а не количество элементов (то есть ты не можешь просто пропустить массив или документ, тебе надо пропустить каждый из его элементов). но в остальном да — сгодится, наверное.
ну вот формат fix map +--------+-------- |1000XXXX|...N*2 objects +--------+-------- => 0000XXXX (=N) elements map where odd elements are key and next element of the key is its associate value.
какое количество байт будет занимать эти самые N*2 objects?
мне кажется, что в случае с небольшими документами BSON и его подход "размер, потом документ" будет лучше, т.к. объекты маленькие и в случае изменения элемента объект можно перестроить заново, пересчитав все его размеры (при вложенности). а вот бродить по ним можно будет ничего не меняя. а этот ваш MsgPack сгодится, если элементы могут быть хуй знает каких размеров, и нужно будет эффективно чего-то менять.
только MsgPack, только хардкор!
why not protobuf?
а вообще, этот msgpack без десереализации как-то можно юзать? если нет — значит говно собачье (точнее не для того оно)
Можно и без десериализации. Ничем он в этом от JSON/protobuf не отличается.
как раз с JSON ты нихуя не можешь сделать, пока его не "десереализируешь" в память. про protobuf не скажу. а по BSON ты можешь прекрасно бродить отступами, т.к. размер объекта пишется перед ним.
/4 ~= s/JSON/BSON/
Там тоже можно бродить отступами
судя по формату MsgPack — BSON эффективнее, т.к. в нём хранится размер всего документа, а не количество элементов (то есть ты не можешь просто пропустить массив или документ, тебе надо пропустить каждый из его элементов). но в остальном да — сгодится, наверное.
ШТО
что непонятно?
Ты что-то гонишь
ну вот формат fix map
+--------+--------
|1000XXXX|...N*2 objects
+--------+--------
=> 0000XXXX (=N) elements map
where odd elements are key and next element of the key is its associate value.
какое количество байт будет занимать эти самые N*2 objects?
У каждого элемента там размер хранится :)
если элемент — тоже map, или массив — то аналогично придется идти "внутрь". вот об этом я тебе и говорю.
мне кажется, что в случае с небольшими документами BSON и его подход "размер, потом документ" будет лучше, т.к. объекты маленькие и в случае изменения элемента объект можно перестроить заново, пересчитав все его размеры (при вложенности). а вот бродить по ним можно будет ничего не меняя. а этот ваш MsgPack сгодится, если элементы могут быть хуй знает каких размеров, и нужно будет эффективно чего-то менять.