Is BINARY as an In memory format consume more Memory space or not and Is not well suited for REST Client?

[Benjamin E.Ndugga]

 Hi All,

 I am about to finish my project, I have a Map Configuration set as follows the in Memory Format has been set to BINARY however the REST Cient whern retrieving this data cant not parse the data into txt. Do you think OBJECT format might be the best choice?
 
  Does the BINARY Format consume more memory space other than OBJECT. Please advise.

  <map name="eoy.band">
        <in-memory-format>BINARY</in-memory-format>
        <backup-count>1</backup-count>
        <async-backup-count>0</async-backup-count>
        <time-to-live-seconds>345600</time-to-live-seconds>
        <max-idle-seconds>0</max-idle-seconds>
        <eviction-policy>NONE</eviction-policy>
        <max-size policy="PER_NODE">0</max-size>
        <eviction-percentage>25</eviction-percentage>
        <min-eviction-check-millis>100</min-eviction-check-millis>
        <merge-policy>com.hazelcast.map.merge.PutIfAbsentMapMergePolicy</merge-policy>
        <cache-deserialized-values>INDEX-ONLY</cache-deserialized-values>
        <map-store enabled="true">
            <class-name>com.ibm.ug.hz.EoyBandStore</class-name>
            <write-delay-seconds>5</write-delay-seconds>
            <write-batch-size>100</write-batch-size>
            <write-coalescing>true</write-coalescing>
        </map-store>
    </map>

[David Zhou]

If you're having problems parsing your data, that is likely related to serialization / deserialization. Whether you use BINARY or OBJECT for the memory format should not matter.

BINARY and OBJECT refer to how Hazelcast stores your map entries in-memory. BINARY means the data is stored in the serialized format so put / get operations require only 1 serialization or deserialization. OBJECT means the data is stored in the deserialized format so get / put operations require 1 serialization and 1 deserialization. The provided guidance from the docs is to use BINARY (default) when most of your operations are typical gets and puts and to use OBJECT when you have a lot of entry processing or complex queries where the cost of serialization is comparatively high.

[Cleber Muramoto]

In general, binary is a better choice from a scalability perspective and in-memory from a throughput perspective.

With binary objects are serialized into Record instances which in turn hold byte-arrays. Lets say your objects being cached hold in average 20 references. It's almost certain that these objects will end up in old generation, so if you cache 1 million objects, full gcs will have to take care of roughly 21 Million objects if using in-memory format. On the other hand if each of these objects are converted into byte arrays, gc has to take care of ~ 2 Million objects only, but you end up paying the price of deserialization to convert back these arrays to the original objects.

If your application is mostly stateless, that is, the amount of data that lands on the old gen is fixed, regardless of the number of users, in-memory is the way to go, otherwise, go for binary, unless the Object graphs being cached are very simple.

[Benjamin E.Ndugga]

Hi David,

I think its fine that I am using BINARY in-memory format. lets take a step futher and look at the Map which is storing data in the type <String,Integer>, when we use the REST client to fetch a value from this Map , its not parsed well, therefore my question is, does Hazlecast only support <String,String> for REST clients?