Live data from Hacker News

Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

amzn.github.io

131–140 of 240 posts

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#131
post #44

This reminded me of a tight-packed binary format we used in the trading systems domain almost 20 years ago. Instead of including metadata/field names in each message, it had a central message dictionary that every client/server would first download a copy from. Messages had only type IDs, followed by binary packed data in the correct field order. Because of microsecond latency requirements, we even avoided the serial…

Well that's just like using C structs. The best serialization protocol :).

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#133
post #57

Earlier quoted context omitted.

That just reminded me of the most mysterious scaling issue I ever faced. We had a message to disseminate market data for multiple markets (e.g. IBM: 100/100.12 @ NYSE, 101/102 @ NASDAQ etc.). The system performed admirably under load testing (think 50,000 messages per second). One day we onboarded a single new regional exchange and the whole market data load test collapsed. We searched high and low for days without s…

Ouch that’s rough. One nice bit of IPv6 is that it doesn’t allow fragmentation. It often much nicer to get no message or an error than subtly missing data.

IPv6 does allow fragmentation.

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#134
post #44

This reminded me of a tight-packed binary format we used in the trading systems domain almost 20 years ago. Instead of including metadata/field names in each message, it had a central message dictionary that every client/server would first download a copy from. Messages had only type IDs, followed by binary packed data in the correct field order. Because of microsecond latency requirements, we even avoided the serial…

Apache Thrift works on the same principle of separating structure from data.

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#135
This is what JSON should have been extended to.

But Douglas Crockford just don't want to innovate anything, just like Gruber didn't want to make a proper specification of the Markdown format.

Sometimes people are keeping innovation back. Fortunately this did not happend with html.

The main thing missing from the text format is a magic and version number. At least the binary format has it.

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#136
post #126
post #109

Earlier quoted context omitted.

If you generate randomly then, due to the birthday paradox, after generating sqrt(N) values you have a reasonable chance of collision. The birthday paradox is named after the non-intuitive fact that with just 32 people in a room you have > 50% of 2 people having a birthday on the same day of the year.

Does birthday paradox apply here? It’s about any pair of people having the same birthday, whereas in this case you need someone else with a specific birthday. For example, if you generate 2 numbers and they are the same, but are different to the capnproto number, that’s a collision but doesn’t actually matter. EDIT: It does apply, I misunderstood what the number was being used for.

It does apply, according to https://www.johndcook.com/blog/2017/01/10/probability-of-sec...

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#137

Did anything ever become of the lispy language that was being built using Ion as its homoiconic syntax? I'm afraid I can't recall what it was called. Fusion maybe?

Dunno about that one but if you like that sort of thing, check out Rebol.

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#138

I wonder what's the performance relative to native JSON parsers?

Disclosure: I manage the Ion and PartiQL teams at Amazon.

We have done some work on performance comparisons with the ion-java-benchmark-cli tool (https://github.com/amzn/ion-java-benchmark-cli). Right now you can compare JSON serialized with Jackson and there is a pull request (https://github.com/amzn/ion-java-benchmark-cli/pull/27) for comparing against CBOR that should be merged soon.

We are always happy to hear suggestions for what is useful in this area.

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#139
post #100

Earlier quoted context omitted.

> It’s a 64bit random number so it’ll never have unintentional collisions. It'll have unintentional collisions if you ever generate more than 4 billion of these random numbers. That's not inconceivable.

Yes it is. Message schemas are made by humans. Most of these messages will be extended in a backwards compatible manner over the life of a project rather than replaced entirely so their IDs don’t change. That’s kinda the point of protobufs and its successors. I’ve probably generated 100 IDs over my lifetime.

Which puts it on the same order of magnitude as the number of people on the planet. If every person alive generated a schema (or if 1/100th of all people generate 100 IDs each like you) then we'd have a small number of collisions. More likely you'd get large numbers of schema like that if there's a widespread application of a protocol compiler that generates new schema programmatically, e.g. to achieve domain separation, and then is applied at scale. I'm not saying that's likely, just that it is not, as is claimed, inconceivable.

Re: Amazon Ion – A richly-typed, self-describing, hierarchical serialization format

#140
post #126

Earlier quoted context omitted.

Does birthday paradox apply here? It’s about any pair of people having the same birthday, whereas in this case you need someone else with a specific birthday. For example, if you generate 2 numbers and they are the same, but are different to the capnproto number, that’s a collision but doesn’t actually matter. EDIT: It does apply, I misunderstood what the number was being used for.

It does apply, according to https://www.johndcook.com/blog/2017/01/10/probability-of-sec...

You’re right, I misunderstood what the magic number was being used for.
Post reply on HN