hazelcast.xml - Map Ayarları

Giriş

MapStore için parametreleri MapStore Ayarları yazısına taşıdım

default map

Açıklaması şöyle

In Hazelcast, a "default map" refers to the default configuration for the IMap data structure, which is the most commonly used data structure in Hazelcast. When you create an IMap instance without specifying any specific configuration, it uses the default configuration for IMap, which can be customized in the Hazelcast configuration file or programmatically through the Hazelcast API.

İsmi "default" olan bir konfigürasyon yaratılırsa, otomatik olarak tüm IMap'lere uygulanır. Şöyle yaparız

<hazelcast>
  ...
  <map name="default">
    <backup-count>1</backup-count> 
    <in-memory-format>BINARY</in-memory-format> 
    <max-idle-seconds>3600</max-idle-seconds>
    <time-to-live-seconds>21600</time-to-live-seconds>
  </map>
  ...
</hazelcast>

wildcard Configuration

Açıklaması şöyle

Hazelcast supports wildcard configuration for most of the data structures that are configured in the cluster. Using an asterisk (*) character in the name, different instances of maps, queues, topics, semaphores, etc. can be configured by a single configuration. See the example below: 

Açıklaması şöyle

On the other hand, the "wildcard configuration" is a feature in Hazelcast that allows you to use a single configuration for multiple data structures that match a specific pattern. This is useful when you have a large number of data structures with similar configuration needs, as it allows you to reduce the amount of duplicate configuration code.

For example, let's say you have several IMap instances that share a similar naming convention, such as customerData_US, customerData_EU, customerData_APAC, etc. You can use a wildcard configuration to apply the same configuration to all IMap instances whose name matches the pattern customerData_*. This can be achieved by defining a single configuration in the Hazelcast configuration file that uses the name attribute with a wildcard, like this:

<map name="customerData_*">

    <in-memory-format>OBJECT</in-memory-format>

    <eviction size="1000" max-size-policy="ENTRY_COUNT"/>

</map>

This configuration will be applied to all IMap instances whose name starts with "customerData_".

Örnek

Şöyle yaparız

<map name="map*">
  <max-size policy="USED_HEAP_PERCENTAGE">20</max-size>
  <eviction-policy>LFU</eviction-policy>
  <statistics-enabled>true</statistics-enabled>
  <backup-count>0</backup-count>
  <async-backup-count>1</async-backup-count>
  <read-backup-data>true</read-backup-data>
</map>

Açıklaması şöyle

By using this configuration, both map1 and map2 will have the exact same configuration. But you need to use programmatic configuration if you want to add more configuration elements (such as time-to-live-seconds) by using a base config.

Örnek - Bence şu kullanım doğru değil. Burada wildcard Configuration aynı default map gibi kullanılıyor

<map name="*">
  <async-backup-count>0</async-backup-count>
  <backup-count>0</backup-count>
  <read-backup-data>true</read-backup-data>
  <in-memory-format>BINARY</in-memory-format>
</map>

default map vs wildcard Configuration

Açıklaması şöyle

The main difference between default map and wildcard configuration in Hazelcast is that the former is the default configuration used by IMap instances if no specific configuration is provided, while the latter allows you to use a single configuration for multiple data structures that match a specific pattern.

Alanlar

entry-listeners

Örnek

Şöyle yaparız

public class SampleEntryListener implements
        EntryAddedListener<String, String>, EntryUpdatedListener<String ,String> {

    @Override
    public void entryAdded( EntryEvent<String, String> event ) {
        System.out.println( "Entry Added:" + event );
    }

    @Override
    public void entryUpdated( EntryEvent<String, String> event ) {
        System.out.println( "Entry Updated:" + event );
    }
    
}

<entry-listeners>
  <entry-listener include-value="true" local="true">com.hazelcast.SampleEntryListener</entry-listener>
</entry-listeners>

event-journal

Event Journal veri yapısına yapılan değişiklikleri takip etmek için kullanılır

Örnek

Kapasite atamak için şöyle yaparız

<hazelcast>
  ...
  <map name="default">
    <event-journal enabled="true">
      <capacity>5000</capacity>
      <time-to-live-seconds>20</time-to-live-seconds>
    </event-journal>
  </map>
  ...
  <cache name="*">
    <event-journal enabled="true">
      <capacity>10000</capacity>
      <time-to-live-seconds>0</time-to-live-seconds>
    </event-journal>
  </cache>
  ...
</hazelcast>

max-size Alanı

Map için en fazla olabilecek büyüklüğü verir. Bu sınır aşılırsa bazı nesneler silinir. Açıklaması şöyle. Varsayılan policy PER_NODE

Maximum size of the map. When maximum size is reached, the map is evicted based on the policy defined. Valid values are integers between 0 and Integer.MAX VALUE. Default value is 0. If you want max-size to work, set the eviction-policy property to a value other than NONE. 

Örnek

Şöyle yaparız

<map name="simpleMap">
  <backup-count>0</backup-count>
  <max-idle-seconds>0</max-idle-seconds>
  <eviction-policy>LRU</eviction-policy>
  <time-to-live-seconds>30</time-to-live-seconds>
  <max-size>3000</max-size>
  <eviction-percentage>30</eviction-percentage>
  <merge-policy>com.hazelcast.map.merge.PutIfAbsentMapMergePolicy</merge-policy>
</map>

max-size-policy Alanı

Bir sürü farklı policy var. En çok kullanılanları PER_NODE ve PER_PARTITION.

PER_NODE

Açıklaması şöyle. Yani en küçük 271 değerini alabilir.

Hazelcast Map internally does eviction on partition basis, that means when you use PER_NODE policy with a maxSize of 5000, it translates that maxSize to partition-max-size by using this equation 

partition-max-size = maxSize * memberCount / partitionCount.

And when entry-count in that partition exceeds partition-max-size, eviction starts on that partition. Min value for partition-max-size is internally set 1 not to evict every added entry. So partitionCount is the minimum settable max-size (default partition-count is 271).

Örnek

Şöyle yaparız

<map name="ReportsPerNode">
    <eviction-policy>LRU</eviction-policy>
    <max-size policy="PER_NODE">500</max-size>
</map>

in-memory-format Alanı

Açıklaması şöyle

To configure how the cluster will store map data, set the in-memory-format element in the configuration:

1. BINARY (default): The data (both the key and value) is stored in serialized binary format.

2. OBJECT: The data is stored in deserialized form. The key is still stored in binary format.

3. NATIVE: (Hazelcast Enterprise) The data is stored in serialized binary format, outside the JVM heap.

Hangisini seçmek lazım ? Açıklaması şöyle. Mesela eğer EntryProcessor kullanıyorsak format olarak OBJECT seçilebilir.

- If the majority of your cluster operations are reads (get) and writes (put), leaving the data in BINARY format is most efficient.

- However, if the majority of your cluster operations are queries, deserialization overhead becomes a concern. Queries have to run against objects, not binary data.

Eğer Native seçtiysek xml içinde High Density Memory Store ayarları yapılmalıdır.

Örnek

Şöyle yaparız

<hazelcast>
  ...
  <map name="objectMap">
    <in-memory-format>OBJECT</in-memory-format>
  </map>
  ...
</hazelcast>

veya 

<hazelcast>
  ...
  <map name="nativeMap">
    <in-memory-format>NATIVE</in-memory-format>
  </map>
  ...
</hazelcast>

Index Alanı

Map Index Ayarları yazısına taşıdım

statistics-enabled Alanı

Örnek

Şöyle yaparız

  map:
    default:
      statistics-enabled: true
      time-to-live-seconds: 86400
      eviction:
        max-size-policy: PER_NODE
        eviction-policy: LFU
        size: 200000

time-to-live-seconds Alanı
Örnek
Şöyle yaparız

<map name="some-cache">
  <time-to-live-seconds>20</time-to-live-seconds>
</map>