Wow I'm learning today that Github used Redis for persistent data, now that they moved away :-) Anyway very happy that Redis helped to run such an important site. From the blog post it looks like that for certain things to move away from Redis was hard even if they are very skilled with MySQL, this is a good thing from the POV of Redis since it means that Redis allows to model certain things easily. However they want…
FWIW we went through a very similar process to that documented here by Github (~3 months ago). It was entirely due to operational reasons and nothing to with shortcomings in Redis itself. MySQL was the master record for 99% of our data while Redis was the master record for the other 1% (as it happens it was also a kind of activity stream). Having the single 'master' reference for our data reduced complexity to a degr…
Moving persistent data out of Redis
51–60 of 77 posts
Re: Moving persistent data out of Redis
#52I don't know why people use redis as an LRU cache. Its a terrible LRU cache. Its eviction algorithm isn't true LRU and does sampling which may cause new keys to get incorrectly convicted. LRU is also really slow being single threaded.
Also, 3.0 has a better LRU algorithm. https://redis.io/topics/lru-cache
Re: Moving persistent data out of Redis
#53Earlier quoted context omitted.
Pretty cool that redis was helping to host its own source code & development.
A lot of software help host their own source code and development. Just considering Github, 1. MySQL is hosted on Github. 2. I think they use elasticsearch and it is hosted on github. and lots of others Software is pretty cool like that!
Re: Moving persistent data out of Redis
#54Wonder why they didn't use Cassandra for this use case.
Re: Moving persistent data out of Redis
#55We've recently had to move away from redis for persistent data storage at work too - opting instead to write a service layer ontop of cassandra for storing data. Redis was tremendous in our journey up there - but one of the shortcomings is that it isn't as easy to scale-up as cassandra is if you haven't designed your system to scale-up on redis from when it was built (which we didn't) - instead of re-architecting for…
Somehow setting up a Redis cluster and doing whatever you have to do to distribute/shard your keys effectively (which afaik is not much) does sound a little more efficient than rewriting a clustered microservice in Go with a Cassandra backend. Redis clustering is actually quite easy.
Forgive me if I seem grumpy. My recent experiences have caused the "We had a minor issue, so we redid everything in a Totally Cool Super-Neato New Stack That Integrates All The Hiring Manager's Favorite Buzzwords!" perspective to become a bit grating.
Redis is one of the few new pieces of infrastructure over the last 10 years that's truly deserving of its position.
Re: Moving persistent data out of Redis
#56Wonder why they didn't use Cassandra for this use case.
Re: Moving persistent data out of Redis
#57Earlier quoted context omitted.
What should people use?
Memcached is a LRU cache.
http://stackoverflow.com/questions/10558465/memcached-vs-red...
http://www.infoworld.com/article/3063161/application-develop...
Re: Moving persistent data out of Redis
#58We've recently had to move away from redis for persistent data storage at work too - opting instead to write a service layer ontop of cassandra for storing data. Redis was tremendous in our journey up there - but one of the shortcomings is that it isn't as easy to scale-up as cassandra is if you haven't designed your system to scale-up on redis from when it was built (which we didn't) - instead of re-architecting for…
>instead of re-architecting for a redis-cluster setup, we decided to move the component to a clustered microservice written in go, that sits as a memory-cache & write buffer infront of cassandra for hot, highly mutated data. Somehow setting up a Redis cluster and doing whatever you have to do to distribute/shard your keys effectively (which afaik is not much) does sound a little more efficient than rewriting a cluste…
Re: Moving persistent data out of Redis
#59Can anybody here help me understand why many teams are using MySQL as a KV store? (Uber did it recently, so assuming many others probably did it too, network effect) I personally love MySQL. Just want to understand what makes MySQL a great KV store as opposed to more seemingly specialized systems like Redis?
MySQL also proved very good at scale, at Facebook, YouTube, Uber, etc. and there are a lot of people with experience running it.
Uber wrote a very good article about their switch, for them it was more about performance, though a little bit controversial.
Re: Moving persistent data out of Redis
#60Can anybody here help me understand why many teams are using MySQL as a KV store? (Uber did it recently, so assuming many others probably did it too, network effect) I personally love MySQL. Just want to understand what makes MySQL a great KV store as opposed to more seemingly specialized systems like Redis?
Its not, it just happens to be good enough, which matters a lot for operational expertise/costs/etc.
For example, you can store hundreds of millions of KV rows in an InnoDB table and still have <1-3ms response times on queries, while having persistence built in. Perfect is the enemy of good enough.