Mutimap vs Map + multi nodes cluster

[karim slaimi]

Hello,

I am using multimap and map objects to store my data in Hazelcast.

However, I have some questions:

1- it seems we cannot set neither a TTL nor an eviction policy for multimap. So is there a way to do it.

2- Is multimap more efficient (serialization/deserialization phase) than map?

3- I am using java Serializable interface. the serialization/deserialization phase is taking too much time. Should I use IdentifiedDataSerializable interface instead of java Serializable one to go fatser with serialization phase?

4- In the management center, I am able to see the amount of memory of any map. But there is no information about the multimap memory, it's always displaying zéro. It's like I cannot verify what's the memory used by multimap. is it normal?

My last question is related to multi nodes cluster. So I would like to add a second node to my cluster but how can I connect my clients to the whole cluster and not only to one node:

1- in java client I am setting the ip address of one node:

clientConfig.getNetworkConfig().addAddress(ip_address);

so should I add ip addresses of all nodes:  clientConfig.getNetworkConfig().addAddress(ip_addres_node1, ip_address_node2);
what happened if node1 gowes down is the client will be redirected to node2 automatically?
2- for my Hazelcast tomcat session manager, is this conf correct to connect to the whole cluster?
<cluster-members>
            <address>ip_address_node1</address>

            <address>ip_address_node2</address>  
        </cluster-members>

Also same question as for java client, what happened if node1 goes down? 

Best regards

Karim

[Tom OConnell]

1. Setting a TTL is unsupported – I believe this is because of possible ambiguity, i.e. can members of a single collection (belonging to the same key) expire at different times?
2. The serialization will probably be similar, but this depends upon which serialization mechanism you use. A “get()” returns a collection, so there’s probably one more object creation, but this will tend to be small.
3. Java default Serializable will be the worst performing of any common choice. IdentifiedDataSerializable could be a good choice. There are other choices, depending upon your use, including Hazelcast Portable, but also Avro/Kryo/Protocol Buffers/… All of these will outperform java serialization.
4. MultiMaps have a couple monitoring limitations, compared to IMap. This is expected, currently.

 

1. Clients, by default, will connect to all members. This is to allow optimal network routing of requests. You can use unisocket (https://docs.hazelcast.com/imdg/4.2/clients/java.html#java-client-operation-modes) connections, but, the data will still be distributed, so you may only introduce extra network hops.
   The smart-client connection will generally be the best approach for performance and resilience. Unisocket clients may be required if your cluster grows to a size where you cannot or do not want to, support that many open socket connections.
   If any member exits, for any reason, your client may reconnect (https://docs.hazelcast.com/imdg/4.2/clients/java.html#java-client-connection-strategy) automatically. You may also want to ensure that the “retry” mode is on. This would allow a request to be re-retried for connection drops.
2. Minimally, you only need the address of a single member – the membership state of the running cluster will be sent to the client upon connection – and, updates will be sent. If you do use the unisocket client connection, you will have unbalanced connections and possibly sub-optimal performance.
   Your last question, about node1 exiting, depends upon the factors named above – it will reconnect if configured to do so. Smart clients will continue to operate with other members, during interruptions. Assuming that node1 restarts, all clients will be informed. You’ll see, in the management-center, that the data rebalances upon the exit and again when the “new” member joins.