-4

I am currently evaluating the fastest possible caching solutions that we can use among the Technologies in question. We know that while Redis and Hazelcast are caching solutions by their very intent and definition, and there is a clear stackoverflow link @ redis vs hazelcast, there is also the AWS S3 which may not be a caching solution but is nevertheless, a storage and retrieval service + it supports SQL as well which makes it in my opinion a qualifier in the race as well. Considering this, are there any forethoughts on comparing the three based on speed, volumes of data etc.?

Sheel Pancholi
  • 621
  • 11
  • 25
  • 1
    This is simply too broad to be answered in any practical way. redis vs hazelcast may be a meaningful comparison, but s3 would add an orange to an apple comparison. I'm sure before looking at s3 as a caching solution, you discarded ignite, infinispan, etc. – ernest_k May 30 '18 at 19:40
  • Thanks Ernest. I have echoed the same sentiment in my question too. The only reason why I included S3 into the picture was because S3's storage service coupled with the SQL capability on S3 in my opinion brings it back in the game with its support for data volumes and now the speed. – Sheel Pancholi May 30 '18 at 19:48
  • There's some overlap between S3 and the other two, but it's tenuous. Basic features such integration mechanisms (API vs driver/bundled member), distributed computing, partitioning, data locality, etc. are simply likely to make it extremely easy to choose (i.e, to eliminate one group). I may not be up to date about S3, but I can hardly imagine that it would perform in any way that justifies comparing it to something like hazelcast in its typical use-case and deployment. That said, I wouldn't even start comparing the two when it comes to permanent data storage. – ernest_k May 30 '18 at 20:01
  • Alright..I think that is a valuable input anyway for me as I might have gotten myself involved into this too deep and may have gone on the wrong track. When you say comparison of a caching solution like Redis/Hazelcast with a permanent storage solution like S3 does not make sense, I concur with you. It is only when the S3 gets a nitro boost with the SQL capability that I start to think about it. But I get your point, overall. – Sheel Pancholi May 30 '18 at 20:09
  • That's just my opinion, you may be having a fresher or more informed perspective. But when evaluating these kinds of solutions, I think it's advisable to focus on the primary objective of the alternatives, in light of the primary concern one is trying to address. That makes it much easier. – ernest_k May 30 '18 at 20:15

1 Answers1

1

Hazelcast also provides SQL alike capabilities - run queries to fetch data in a resultset. Technology wise, Hazelcast/Redis and S3 are fundamentally different; for the latter is a disk bound data store and that are proven/known to be significantly slower than their in-memory counterparts.

To put things in a logical perspective: S3 or any other disk bound data store can not match the performance of accessing data from in-memory data stores.

However, it is also a common practice to run Hazelcast on top of a disk bound data store to get performance boost. In such type of architectures, your applications basically always only interact with Hazelcast. One can then use Hazelcast tools to keep the cached data in sync with underlying database.

wildnez
  • 1,078
  • 1
  • 6
  • 10