To sum up: AWS Elasticache is meant as a Read/WRITE data cache (sitting in front a DB), while MemoryDB is a durable DB (ie data is durable, no transaction is lost in the event of a failure). Just like AWS Elasticache, AWS MemoryDB stores all its data in memory. But for WRITEs, Elasticache replicates its data to replicas asynchrounously, while MemoryDB waits for its transaction logs to be replicated across AZs before acknowledging back to the client the success of the WRITE operation.
I would call Amazon MemoryDB the worst Service I have used to date. All documentation, videos, specs is all buzzwords, not much actually useful things. I encourage anyone who is on the way of researching MemoryDB in 2022 to give up, and give AWS a couple of years to write decent docs. I find this extremely concerning
AWS: please work on your documentations so we can easily use your amazing products. The documents are too verbose and it always takes me long time to finally get started, normally takes more than twice time than GCP.
One hour video named "deep dive" that barely scratches the surface and gives incomplete, misleading information. It's not all about latencies and number of ops. One distinct feature of Redis that makes it stand out is its ability to run Lua scripts in sort of transactional manner. The problem with that is that this doesn't scale horizontally as well as they tell you in this video. All your transactional logic must be executed on a single shard to benefit from this consistency model. So it's not as nearly as simple as "add more servers" as they claim. There is also no information about recovery guarantees. "Fast recovery" - what does that even mean? What will happen specifically? How quickly my DB will get back online in case of a failure? Is it milliseconds, seconds, minutes? Will the process of recovery be transparent to DB client? No real information, just marketing stuff.
![AWS re:Invent 2021 - Deep dive on Amazon Timestream [REPEAT]](http://i.ytimg.com/vi/QjMZaKkq8YM/mqdefault.jpg)
![AWS re:Invent 2021 - Deep dive on Amazon Timestream [REPEAT]](/img/tr.png)
To sum up:
AWS Elasticache is meant as a Read/WRITE data cache (sitting in front a DB), while MemoryDB is a durable DB (ie data is durable, no transaction is lost in the event of a failure).
Just like AWS Elasticache, AWS MemoryDB stores all its data in memory. But for WRITEs, Elasticache replicates its data to replicas asynchrounously, while MemoryDB waits for its transaction logs to be replicated across AZs before acknowledging back to the client the success of the WRITE operation.
Thanks Mahesh, it was great session.👍
Awesome presentation Jon, thanks a lot!
Thank god that everything is so SUPER EASY
I would call Amazon MemoryDB the worst Service I have used to date. All documentation, videos, specs is all buzzwords, not much actually useful things.
I encourage anyone who is on the way of researching MemoryDB in 2022 to give up, and give AWS a couple of years to write decent docs.
I find this extremely concerning
AWS: please work on your documentations so we can easily use your amazing products. The documents are too verbose and it always takes me long time to finally get started, normally takes more than twice time than GCP.
One hour video named "deep dive" that barely scratches the surface and gives incomplete, misleading information. It's not all about latencies and number of ops. One distinct feature of Redis that makes it stand out is its ability to run Lua scripts in sort of transactional manner. The problem with that is that this doesn't scale horizontally as well as they tell you in this video. All your transactional logic must be executed on a single shard to benefit from this consistency model. So it's not as nearly as simple as "add more servers" as they claim.
There is also no information about recovery guarantees. "Fast recovery" - what does that even mean? What will happen specifically? How quickly my DB will get back online in case of a failure? Is it milliseconds, seconds, minutes? Will the process of recovery be transparent to DB client? No real information, just marketing stuff.
Thanks for sharing your feedback. I've ensured your voice is heard by sending it off to our service team for review. ^RF