Files
2nd/10_Wiki/Topics/Architecture/In-Memory Data Grid.md
T
koriweb d8a80f6272 chore(wiki): dangling 링크 canonical 정규화 (768파일/1200건)
이름만 다른(표기 변형) [[위키링크]]를 대상 문서의 canonical 제목으로 치환해
끊겼던 1,200개 링크를 연결. 제목/파일명 정규화 일치만 적용하고 별칭 매칭은
과병합 위험으로 제외(애매성 가드). 원본은 _link_reconcile_backup/ 에 백업.
도구: Datacollect/scripts/link_reconcile_apply.mjs

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-08 12:24:15 +09:00

5.5 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-in-memory-data-grid In-Memory Data Grid 10_Wiki/Topics verified self
IMDG
Distributed Cache
In-Memory Computing
none A 0.9 applied
architecture
distributed-systems
cache
performance
jvm
2026-05-10 pending
language framework
java hazelcast-ignite

In-Memory Data Grid

매 한 줄

"매 distributed RAM 의 partitioned + replicated 의 통한 sub-ms key-value + compute 의 horizontal scale". 매 Oracle Coherence (2001) 의 commercial origin, 매 Hazelcast (2008) / Apache Ignite (2014) 의 OSS 의 popularization — 매 modern 의 Redis Cluster + Apache Ignite + Hazelcast 5.x 의 dominant.

매 핵심

매 IMDG vs Distributed Cache

  • Cache (Redis, Memcached): 매 read-through, eviction-driven, simple K/V.
  • IMDG (Hazelcast, Ignite, Coherence): + co-located compute, SQL, transactions, near-cache, entry processors, CP subsystem.

매 Core Capabilities

  • Partitioning: consistent hash, 매 271 partitions (Hazelcast default).
  • Replication: backup count (sync/async), 매 partition 의 N-1 backup.
  • Near Cache: client-side mirror, invalidation 의 push.
  • Entry Processor: 매 data-local computation (move code to data).
  • Continuous Query: predicate-based push.
  • CP Subsystem: Raft-based linearizable primitives (Hazelcast 4+).

매 응용

  1. Session store / shopping cart (low-latency).
  2. Real-time risk / pricing (compute grid).
  3. Hybrid OLTP+stream (Ignite + Kafka).

💻 패턴

Hazelcast 5 — Embedded + IMap

HazelcastInstance hz = Hazelcast.newHazelcastInstance();
IMap<String, Order> orders = hz.getMap("orders");
orders.put("o-123", new Order(...));
Order o = orders.get("o-123");  // sub-ms

// Pessimistic lock 의 partition-local
orders.executeOnKey("o-123", entry -> {
    Order cur = entry.getValue();
    cur.markPaid();
    entry.setValue(cur);
    return null;
});

Apache Ignite — SQL over Cache

IgniteConfiguration cfg = new IgniteConfiguration();
Ignite ignite = Ignition.start(cfg);

CacheConfiguration<Long, Person> ccfg = new CacheConfiguration<>("Person");
ccfg.setIndexedTypes(Long.class, Person.class);
IgniteCache<Long, Person> cache = ignite.getOrCreateCache(ccfg);

List<List<?>> rows = cache.query(new SqlFieldsQuery(
    "SELECT name, salary FROM Person WHERE salary > ? ORDER BY salary DESC")
    .setArgs(100_000)).getAll();

Hazelcast Near Cache

hazelcast-client:
  near-cache:
    orders:
      in-memory-format: OBJECT
      invalidate-on-change: true
      time-to-live-seconds: 60
      max-size: 10000
      eviction-policy: LRU

Entry Processor (move compute to data)

public class IncrementVersion implements EntryProcessor<String, Order, Long> {
    public Long process(Map.Entry<String, Order> e) {
        Order o = e.getValue();
        o.setVersion(o.getVersion() + 1);
        e.setValue(o);
        return o.getVersion();
    }
}
Long v = orders.executeOnKey("o-1", new IncrementVersion());

Continuous Query (Hazelcast)

IMap<String, Order> orders = hz.getMap("orders");
orders.addEntryListener((EntryAddedListener<String, Order>) ev -> {
    if (ev.getValue().getAmount() > 10_000) alert(ev.getValue());
}, Predicates.greaterThan("amount", 10_000), true);

CP Subsystem — Linearizable Counter

CPSubsystem cp = hz.getCPSubsystem();
IAtomicLong seq = cp.getAtomicLong("order-seq");
long next = seq.incrementAndGet();   // Raft-backed, linearizable

Kubernetes Deployment (Hazelcast Operator)

apiVersion: hazelcast.com/v1alpha1
kind: Hazelcast
metadata: { name: hz }
spec:
  clusterSize: 5
  repository: hazelcast/hazelcast
  version: "5.5"
  persistence:
    baseDir: /data/hot-restart
    pvc: { accessModes: [ReadWriteOnce], requestStorage: 50Gi }

매 결정 기준

상황 Approach
Simple K/V cache Redis / Memcached
Java-heavy + SQL on cache Apache Ignite
Compute + cache + CP primitives Hazelcast 5
Multi-language polyglot Redis Cluster + redis-om
Persistent in-memory DB Ignite native persistence / Aerospike

기본값: 매 Java/Kotlin stack — Hazelcast 5; 매 polyglot — Redis Cluster.

🔗 Graph

🤖 LLM 활용

언제: IMDG 의 sizing 의 estimate, partition strategy 의 review, Hazelcast/Ignite config 의 generate. 언제 X: 매 production 의 capacity planning 의 final sign-off (real workload benchmark 필수).

안티패턴

  • Distributed monolith state: 매 service 의 IMDG 의 shared mutable state — 매 hidden coupling.
  • N+1 across grid: client-side loop 의 단일 키 fetch — 매 batch API 의 use.
  • No backup count: backup=0 → 매 node loss 의 data loss.
  • Serialization neglect: default Java serialization → 매 slow + bloated, 매 IdentifiedDataSerializable / Compact 의 use.
  • Treating IMDG as durable DB: 매 persistence 의 explicit config 없이 → restart 의 data loss.

🧪 검증 / 중복

  • Verified (Hazelcast 5.5 docs, Apache Ignite 2.16 docs, Oracle Coherence 14c docs).
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — IMDG (Hazelcast/Ignite) 의 full content