[deleted]
How FriendFeed uses MySQL to store schema-less data
31–40 of 92 posts
Re: How FriendFeed uses MySQL to store schema-less data
#32Another interesting detail is that this is roughly the 4th iteration on the FriendFeed backend since we launched 17 months ago. If you look at the the graphs at the bottom of Bret's post, you can see that our previous system was about to die -- average pageview latency had increased from about 135ms to 260ms in less than a month! (not a good trend) This new design also accommodates some important upcoming features th…
Hi, is there any chance you could have a look at this comment:
http://news.ycombinator.com/item?id=497070
and let me know how you resolve this problem in practice? (Or correct my understanding if there is no problem really).
Re: How FriendFeed uses MySQL to store schema-less data
#33Earlier quoted context omitted.
Excuse my ignorance, but what's the Postgres solution to sharding?
It's to write efficient hash joins, partitioning and row versioning into your core database engine.
How do hash joins help with sharding? Surely once you go above a certain number of writes per second you're going to need to have more than one writable database server, at which point you need to start partitioning and better join algorithms aren't going to do anything to help.
Re: How FriendFeed uses MySQL to store schema-less data
#34Earlier quoted context omitted.
Actually, they do, e.g. http://highscalability.com/skype-plans-postgresql-scale-1-bi... MySQL is popular with startups though, so it's not surprising that there's a lot written about it. It's true that MySQL has some lame limitations, but I don't believe that there are any silver bullets out there. Google tried to switch their ads system from MySQL to a "real" database once, and it was basically a disaster and had to…
No, there are no silver bullets, but it seems to me that people reach for Mysql a bit too quickly, without considering the pros and cons. And while it's improving, Mysql has had many frustrating things in the past... to me it's always seemed like a "worse is better" kind of thing. Sure, it's "fast", but at what cost? Once you go to InnoDB, you lose that speed advantage. One thing that's not a tech tradeoff, and is ge…
Actually, Postgres doesn't have any great out-of-the-box solution for partitioning the database across machines. The usual suggestion is Slony, but that is no where near as robust and widely deployed as MySQL replication. The GPL licence for MySQL isn't really a problem for webapps anyway.
OTOH, Postgres does somewhat better than MySQL on a single box with multiple cores (it's fairly linear up to 8 CPU, which is much better than MySQL) - mainly because of the work Sun put into scaling it before they bought MySQL. (At least - that's according to some people from Sun who do a lot of performance work with both databases)
Re: How FriendFeed uses MySQL to store schema-less data
#35Earlier quoted context omitted.
It's to write efficient hash joins, partitioning and row versioning into your core database engine.
How do hash joins help with sharding? Surely once you go above a certain number of writes per second you're going to need to have more than one writable database server, at which point you need to start partitioning and better join algorithms aren't going to do anything to help.
If you can't hash join then you can't join over large datasets anyway, so sharding costs you nothing in that respect.
Right now, using off the shelf kit and doing nothing particularly clever, running a major commercial RDBMS you could do 10,000 commits/sec and handle 100T of data on a single instance. Sure it would cost you a pretty penny, but the thing is, unless running a database is the one competitive advantage your company has, you're better off keeping your people focussed on the thing that does make you money.
Re: How FriendFeed uses MySQL to store schema-less data
#36Earlier quoted context omitted.
It's really nice for not having to bring down the site for schema upgrades. All the other popular databases let you modify the schema online. This feature has been taken for granted for over a decade.
Indeed. This is not a RDBMS problem. Its a MySQL problem and the correct solution is to use a mature DB.
True in this case, but not always true, the issue often isn't upgrading the schema, it's that there can be no single schema that can hold the data because it varies on a per row basis. No RDBMS can deal with this well, no matter how mature, it's just not what they're designed for. This is trivial for an OODBMS which just stores raw objects, no matter their shape.
Re: How FriendFeed uses MySQL to store schema-less data
#37Earlier quoted context omitted.
It's really nice for not having to bring down the site for schema upgrades. All the other popular databases let you modify the schema online. This feature has been taken for granted for over a decade.
Indeed. This is not a RDBMS problem. Its a MySQL problem and the correct solution is to use a mature DB.
[deleted]
Re: How FriendFeed uses MySQL to store schema-less data
#38Earlier quoted context omitted.
Yeah. They actually explained that in the article too - the shard number = user_id % num_of_shards. So user 1 is on DB1, user 2 is on DB3, etc. If they have 10 shards, user 11 starts back on DB1 etc.
I don't understand how that scheme can work, since changing the number of shards changes the location of most users. e.g. we have 4 shards, so user 5 is on shard1. If we go to 6 shards, user5 is now on shard5. I guess it works with downtime to move the users, or another layer of indirection, where the newly created shards can "point back" to existing shards, but otherwise I don't see it. My understanding of sharding…
Hopefully they simplified things for the sake of brevity and they're using consistent hashing or some other predictable algorithm in practice.
Re: How FriendFeed uses MySQL to store schema-less data
#39Earlier quoted context omitted.
Yeah. They actually explained that in the article too - the shard number = user_id % num_of_shards. So user 1 is on DB1, user 2 is on DB3, etc. If they have 10 shards, user 11 starts back on DB1 etc.
I don't understand how that scheme can work, since changing the number of shards changes the location of most users. e.g. we have 4 shards, so user 5 is on shard1. If we go to 6 shards, user5 is now on shard5. I guess it works with downtime to move the users, or another layer of indirection, where the newly created shards can "point back" to existing shards, but otherwise I don't see it. My understanding of sharding…
You don't change the number of shards, you change the number of machines and re-balance the shards across them. Shard != machine.
12 shards on 1 machine
6 shards on 2 machines
4 shards on 3 machines
3 shards on 4 machines
2 shards on 6 machines
Re: How FriendFeed uses MySQL to store schema-less data
#40Earlier quoted context omitted.
I don't understand how that scheme can work, since changing the number of shards changes the location of most users. e.g. we have 4 shards, so user 5 is on shard1. If we go to 6 shards, user5 is now on shard5. I guess it works with downtime to move the users, or another layer of indirection, where the newly created shards can "point back" to existing shards, but otherwise I don't see it. My understanding of sharding…
You don't change the number of shards, you change the number of machines and re-balance the shards across them. Shard != machine. 12 shards on 1 machine 6 shards on 2 machines 4 shards on 3 machines 3 shards on 4 machines 2 shards on 6 machines And on and on...
Ah, OK. So you start with enough shards "for ever" and not change the number?
Edit: no wait. If you can split a shard across multiple machines, what's the benefit of having more than 1 shard? Why not have 1 shard split across 1000 machines?