Limits and gotchas: migrate from Hazelcast to KiviDB

its own JVMs (Hazelcast.newHazelcastInstance()), the application is the cluster: there is no separate server to switch off, and the data goes away when the…

  • Embedded members. If your application starts Hazelcast members inside its own JVMs (Hazelcast.newHazelcastInstance()), the application is the cluster: there is no separate server to switch off, and the data goes away when the last instance stops. Run the copy program as a client of that embedded cluster (members accept client connections on port 5701 by default) before the release that removes Hazelcast, and remember that local reads in an embedded member were in-process; reads from KiviDB cross the network.
  • Java serialization. Values stored with Serializable need the exact classes to be read, at the versions that wrote them. Keep a build of the old classes for the copy program.
  • Near-cache staleness. A near cache, and a client-side cache over CLIENT TRACKING, can return a value that changed a moment ago. Code that read-modify-writes through a near cache needs WATCH or SET ... IFEQ.
  • Max-idle. No KiviDB key slides its expiry on read by itself; refresh the TTL on each read where it matters.
  • Entry processors and executors run your Java code next to the data. KiviDB runs commands, transactions and (in a lua build) Lua scripts, not Java.
  • Entry listeners become keyspace notifications, which carry no values and are not stored.
  • Lock semantics differ; see Locks.
  • Per-map settings (backup-count, in-memory-format, per-map eviction) have no KiviDB equivalent: memory limits and eviction apply to the whole server, and redundancy comes from replicas.
  • Cardinality estimators and FlakeIdGenerator state can't be copied; start them again in KiviDB (set the sequence above the last issued ID).
  • Jet pipelines and Hazelcast SQL jobs have no equivalent in KiviDB.