What are the pros and cons for JCS against Ignite?
In Apache Ignite, the server node(where caches are stored) can run in a separate JVM in a separate host machine, other than the client application. For example, our application can be distributed in 4 nodes, and the distributed cache can be spread across 10 separate independent nodes. Can JCS Cache support this scenario?
From the docs, I understand the JCS Cache supports distributed caching, but does the cache reside in the same JVM process as the Client application or it can be a separate one like in Ignite.
These are two different projects. JCS is just a local in-memory cache which is designed to be mostly read-only. Each local cache can have lateral TCP cache that will notify other cache instances whenever local cache is updated, but this does not have any consistency guarantees, and there is no partitioning. Ignite on the other head is Data Grid (actually even more), it can run on a separate cluster, partition the data across nodes and guarantee update consistency so that you interact with the cluster as with a single entity, regardless of how many nodes you have.
Having said that, based on your use case description I think Ignite is more suitable.
Related
I have two servers, where I will be deploying the same application. Basically these two servers will handle work from a common Web API, the work that handed out will be transformed and go through some logic and loaded into DB. I want to cache the data the get loaded/update or deleted in the database, so that when the same data is referenced i can get it from the Cache (Kind of explained the cache mechanism). Now I am using Ncache and it working perfectly fine within one application. I am trying have kind of a shared cache, so that both my application can have access to. How do i go about doing it?
NCache is a distributed cache so you can continue to use that.
There is good general documentation available and very good getting started material that walks you through all the steps required.
In essence you install NCache on both the servers and then reference both servers in your client configuration (%NCHOME%\config\client.ncconf)
In cluster caches, a single logical cache instance is distributed over multiple server nodes and because the cache process is running outside the application address space, multiple applications can share and see the same exact cache data change in terms of addition, removal and update of the cache content.
Local out-proc caches are limited to one server node but as they are outside the application address space, they also support sharing of data between applications.
In fact, besides allowing multiple applications to share data, NCache supports a pub/sub infrastructure to allow for multiple applications to actually communicate with each other. This allows NCache to play a key part in setting up a fast and reliable microservices environment wherein all the participating services send messages to each other through the NCache platform.
See the link below where they have shared information about NCache topologies
http://www.alachisoft.com/resources/docs/ncache/admin-guide/cache-topologies.html
http://www.alachisoft.com/resources/videos/five-steps-getting-started.html
I understand that there is a cache implemented in Javers to store the globalId and CdoSnapshot, namely LatestSnapshotCache. But I'm not sure about it's behaviour in a distributed system. Our application uses mongoDB on multiple nodes, I'm not sure whether this cache will have a major impact in this scenario. Please guide me here. Also, can we have our own custom cache to boost performance instead of this. For example, a Hazelcast cache.
LatestSnapshotCache is a simple (guava) local heap cache and
there is no way to plug a distributed cache (like Hazelcast) or another impl of local cache. Agreed that it could be useful but i'm doubt about distributed caches, Mongo is a really fast database. Again, I agreed that the cache could be pluggable.
LatestSnapshotCache is safe in distributed systems, because snapshots are immutable.
Which is better suited for the following environment:
Persistence not a compulsion.
Multiple servers (with Ehcache some cache sync must be required).
Infrequent writes and frequent reads.
Relatively small database (very less memory requirement).
I will pour out what's in my head currently. I may be wrong about these.
I know Redis requires a separate server (?) and Ehcache provides local cache so it must be faster but will replicate cache across servers (?). Updating all caches after some update on one is possible with Ehcache.
My question is which will suit better for the environment I mentioned?
Whose performance will be better or what are scenarios when one may outperform another?
Thanks in advance.
You can think Redis as a shared data structure, while Ehcache is a memory block storing serialized data objects. This is the main difference.
Redis as a shared data structure means you can put some predefined data structure (such as String, List, Set etc) in one language and retrieve it in another language. This is useful if your project is multilingual, for example: Java the backend side , and PHP the front side. You can use Redis for a shared cache. But it can only store predefined data structure, you cannot insert any Java objects you want.
If your project is only Java, i.e. not multilingual, Ehcache is a convenient solution.
You will meet issues with EhCache scaling and need resources to manage it during failover and etc.
Redis benefits over EhCache:
It uses time proven gossip protocol for Node discovery and synchronization.
Availability of fully managed services like AWS ElastiCache, Azure Redis Cache. Such services offers full automation, support and management of Redis, so developers can focus on their applications and not maintaining their databases.
Correct large memory amount handling (we all know that Redis can manage with hundreds of gigabytes of RAM on single machine). It doesn't have problems with Garbage collection like Java.
And finally existence of Java Developer friendly Redis client - Redisson.
Redisson provides many Java friendly objects on top of Redis, like:
Set
ConcurrentMap
List
Queue
Deque
BlockingQueue
BlockingDeque
ReadWriteLock
Semaphore
Lock
AtomicLong
CountDownLatch
Publish / Subscribe
ExecutorService
and many more...
Redisson supports local cache for Map structure which cold give you 45x performance boost for read operations.
Here is the article describing detailed feature comparison of Ehcache and Redis.
I'm going to deploy an in-memory cache cluster (current thinking Redis) for some public facing web workloads and was wondering where the cluster should live (deployment topology), two options IMO:
Sitting on the Web tier (which is horizontally scalable)
Create a dedicated cache cluster behind the Web Tier and in-front of the DB Tier.
Background, application on Web and DB Tier running on Windows, so if I stick the cluster on the Web Tier then it needs to be supported on Windows (MSFT have a stable Redis port), if I go with the dedicated cache tier I was thinking of some lightweight Linux servers (HA cluster) meaning as the Web Tier horizontally scaled it used this cache cluster for its lookups e.g. reference data etc.
Pros, cons thoughts, other option I'm missing?
*Note, I don't have the luxury of utilising a cloud service provider "cache as a service", not an option unfortunately ...
Cheers,
Surprised at the lack of community support around Redis and caching in general.
To answer my question, I ended up going with a Linux (RHEL) master/slave Redis cache tier, opted for master/slave deployment topology giving me HA at the cache tier (as opposed to a Redis cache cluster). Master gives me writes, master/slave allows for reads. Suits my needs as I will go to the DB on a cache miss, configured Redis to never persist to disk (in-memory only).
With Memcached, it is my understanding that each of the cache servers doesn't need to know diddly about the other servers. With AppFabric Cache on the other hand, the shared configuration links the servers (and consequently becomes a single point of failure).
Is it possible to use AppFabric cache servers independently? In other words, can the individual clients choose where to store their key/values based on the available cache servers and would that decision be the same for all clients (the way it is with memcached).
NOTE: I do realize that more advanced features such as tagging would be broken without all the servers knowing about each other.
Are you viewing the shared configuration as a single point of failure? If you are using SQL Server as your configuration repository, then this shouldn't be an issue with a redundant SQL Server setup.
This approach would obviously loose you all of the benefits of using a distributed cache, however, if you really want to do this then simply don't use a shared configuration. When you configure a new AppFabric node create a new configuration file or database. Choosing an existing one basically says "add this new node to the existing cache cluster".