[
https://issues.apache.org/jira/browse/TINKERPOP-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507889#comment-16507889
]
Jorge Bay commented on TINKERPOP-1942:
--------------------------------------
Thanks for sharing, smile format looks interesting.
I think there are inherent benefits into creating our own serialization format,
which can be based on existing conventions (like big endian format for any
numeric) but has the advantages of being minimally descriptive. When you create
a serialization format you don't have to provide meta type information, for
example:
Consider a type is composed by 2 properties (property1 and property2) of type
integer, when you use a custom serialization format the reader can be defined
as:
{code:java}
var result = new MyTypeSample();
// Read 4 bytes from a buffer and set the int value.
result.setProperty1(reader.readInt(buffer, offset));
offset += 4;
result.setProperty2(reader.readInt(buffer, offset));
{code}
This is a more simple set of instructions compared to reusing a serializer
(json, smile, protobuf, ...) where you have to have some kind of generic
mapping between the binary data and a class, and/or metadata information about
the type (ie: reflected properties).
Developing a custom serialization format is usually out of scope of any
application developer and it's easier to reuse existing serializers for an
application where you don't know which types you are going to have to support
in the future, but in our case where we provide a server framework with a fixed
set of types, it's a good choice. It's not usually something the developers
are exposed to and when the implementation is a success you don't hear much
about it: take [MySql
format|https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_basic_packets.html#sect_protocol_basic_packets_packet]
or [Apache Cassandra
format|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=doc/native_protocol_v4.spec;hb=refs/heads/cassandra-2.2],
as an example.
> Binary serialization format
> ---------------------------
>
> Key: TINKERPOP-1942
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1942
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
> Reporter: Jorge Bay
> Priority: Major
>
> We should provide a binary serialization format designed to reduce
> serialization overhead and minimizing the size of the payload that is
> transmitted over the wire.
> It could be implemented in a very similar way as Kryo support but with
> interoperability in mind and ultimately we could fade Gryo out, as now with
> the GLVs it doesn't have a role to play.
> The main benefit would be the performance improvement, making serialization
> and deserialization processing time negligible on both the server and the
> client.
> Background:
> https://lists.apache.org/thread.html/13e70235591853801bab16ed457ee4f56f3dfe2d1c5817c34a036408@%3Cdev.tinkerpop.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
