Live data from Hacker News

Moving persistent data out of Redis

githubengineering.com

31–40 of 77 posts

Re: Moving persistent data out of Redis

#31
post #10
post #3

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…

[deleted]

Re: Moving persistent data out of Redis

#32
post #3

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…

That's a bit suprising and I think sad. One would expect Github would have at least reached out and informed and thanked you at the very least if not tried to support your project in some active way.

Whenever this comes up on the HN the perspective is quickly shifted to the developer's choice of license but there are no expectations. But let's shift the perspective to the other side. Surely startups and others using open source projects for commercial reasons even if not obligated legally or not expected to by the developers have some ecosystem responsibility to try to contribute back when they can in some meaningful way.

Acquiring open source projects or hiring developers are 'influence plays' to gain control and should not be the only way for commerical projects to contribute.

Re: Moving persistent data out of Redis

#33

Can 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?

All the tooling around SQL databases that allow you to easily setup fixtures, backups/restores, monitoring,viewing data etc. Also you can scale wide through read slaves easily.

Re: Moving persistent data out of Redis

#34
post #3

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…

That's a bit suprising and I think sad. One would expect Github would have at least reached out and informed and thanked you at the very least if not tried to support your project in some active way. Whenever this comes up on the HN the perspective is quickly shifted to the developer's choice of license but there are no expectations. But let's shift the perspective to the other side. Surely startups and others using…

I understand your POV, and I thank you for your comment, but mine is actually opposite and I want to explain why. I consider Redis, even if the license is different, kinda of the old "Public Domain", that you grab it and do whatever you want, without also expecting much if not what you see the project direction and activity is. However Github I think was the very first big site using Redis and clearly stating it, when it was in beta, so they did a very bold thing and helped Redis a lot to grow up. Github current CEO even wrote the first Redis-based queue system that provided Redis with an huge popularity boost. And they are still using Redis even if no longer for durable data, so it's a 7 years symbiosis going forward. Even if we never exchanged much infos, I think it's fine, I actually think it's the hackers way :-)

Re: Moving persistent data out of Redis

#35
I 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.

Re: Moving persistent data out of Redis

#36
Activity streams are such a common use case. It is very interesting that Soundcloud chose to do something different: https://developers.soundcloud.com/blog/roshi-a-crdt-system-f...

Assembling the inbox on demand is quite interesting. I don't quite understand the querying and operations involved with Roshi for doing that.

Re: Moving persistent data out of Redis

#37
post #13
post #2

I wonder if this will allow better scaling of GitHub enterprise. We are pegging our usage; if we could we would migrate everything to Gitlab Enterprise (which we also have) which seems to have better scalability.

How can we help you move to GitLab EE? (As you indicated it scales to 100k users so that shouldn't we the problem)

Does GitLab really handle 100k users? Where is this indicated?

https://gitlab.com/gitlab-org/gitlab-ce/issues/26405#note_20...

Re: Moving persistent data out of Redis

#38
post #37
post #13

Earlier quoted context omitted.

How can we help you move to GitLab EE? (As you indicated it scales to 100k users so that shouldn't we the problem)

Does GitLab really handle 100k users? Where is this indicated? https://gitlab.com/gitlab-org/gitlab-ce/issues/26405#note_20...

Thanks for asking. The issue you referred to talks about users on a single machine. Unlike GitHub you can run a cluster of application servers with GitLab https://about.gitlab.com/high-availability/

Some of our users have 25k+ users on their cluster. We know GitLab can scale to 100k users because we run GitLab Enterprise Edition without modifications on GitLab.com

GitLab.com currently has much more than 100k users and the performance leaves much to be desired https://gitlab.com/gitlab-com/infrastructure/issues/947

But we're comfortable that you can run 100k users on a cluster of machines without much tuning.

Re: Moving persistent data out of Redis

#39
post #38
post #37

Earlier quoted context omitted.

Does GitLab really handle 100k users? Where is this indicated? https://gitlab.com/gitlab-org/gitlab-ce/issues/26405#note_20...

Thanks for asking. The issue you referred to talks about users on a single machine. Unlike GitHub you can run a cluster of application servers with GitLab https://about.gitlab.com/high-availability/ Some of our users have 25k+ users on their cluster. We know GitLab can scale to 100k users because we run GitLab Enterprise Edition without modifications on GitLab.com GitLab.com currently has much more than 100k users an…

can you share how many machines handles gitlab.com currently?

Re: Moving persistent data out of Redis

#40
post #10

Earlier quoted context omitted.

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…

just asking for some info, but how do you make sure that multiple of your db systems are in sync (specifically interested in MySql and elasticsearch)? Hope it's alright to ask you that.

Where I work we use several different MySQL replicas in production, where we don't expect them to be in sync.

So long as the source of truth (Master MySQL node) is up to date, it's okay.

For example, if we show a user how much money is in their account on every page, we can run query that on a replica, since it's fine if this is a few seconds delayed. However, immediately after an action changed their balance, on a confirmation screen, we'd want to show the value from Master.

It's entirely possible that any place elasticsearch is being used just don't need consistency.

Post reply on HN