Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How FriendFeed uses MySQL to store schema-less data

bret.appspot.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: How FriendFeed uses MySQL to store schema-less data

#51

Post by gnaritas »

mbreese wrote: post #44
jbert wrote: post #40

Earlier quoted context omitted.

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?

The above table wasn't too clear, but my understanding is that a shard exists on only a single machine, but that a single machine could host multiple shards.

Correct, you don't split shards across machines. Each machine hosts x number of shards.

Re: How FriendFeed uses MySQL to store schema-less data

#52

Post by richcollins »

antirez wrote: post #47

"However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs" Ok, just some hour ago I released the beta-3 of Redis ( http://code.google.com/p/redis/ if you care) and I'm near to feature-freeze with exactly with this goal. To make it rock solid (I'm going to use it in my start…

How is redis different from TokyoTyrant?

Re: How FriendFeed uses MySQL to store schema-less data

#53

Post by nostrademons »

ryanwaggoner wrote: post #45
nostrademons wrote: post #4

This is really interesting. We did something similar for GameClay. I stored game properties as JSON-encoded dicts stored in MogileFS, then had a "regular" MySQL table that would point to the MogileFS key for the file, then the Python code would just read it out, use a JSON library to parse it, and manipulate it as a Python object. We had normal MySQL indexes on all the game metadata that appeared in the UI, so if you…

This is really interesting...could you do the same thing using S3 instead of MogileFS? The advantage would be cost and simple scalability, especially if you're running on EC2 so you don't have to pay for all the back and forth transfer from EC2 to S3. Concerns might be latency issues and whether this would scale to billions of objects. Other than that, it would seem like you could run a pretty huge site off of just a…

Absolutely. It'd work with any sort of distributed filestorage. It wouldn't be too hard to wrap the S3 methods so that the API is consistent (the MogileFS API is basically a dict), so app code wouldn't even have to change.

We used Mogile over S3 mostly because I didn't realize there was no minimum monthly fee for S3.

Re: How FriendFeed uses MySQL to store schema-less data

#54

Post by antirez »

richcollins wrote: post #52
antirez wrote: post #47

"However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs" Ok, just some hour ago I released the beta-3 of Redis ( http://code.google.com/p/redis/ if you care) and I'm near to feature-freeze with exactly with this goal. To make it rock solid (I'm going to use it in my start…

How is redis different from TokyoTyrant?

it's higher level. Not a plain key value stuff. For instance as value you can have a list or a set, push/pop elements, ask the server for all the keys matching a given glob style pattern and so on. Most of this operations are atomic in order to make sure there are no race conditions.

You can read more about the difference between Redis and other key-value stores here: http://code.google.com/p/redis/wiki/FAQ

Basically the long term goal is to have something between a relational DB and a key-value DB. Not all the higher level features must be killed in order to be scalable.

Re: How FriendFeed uses MySQL to store schema-less data

#55

Post by wayne »

antirez wrote: post #47

"However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs" Ok, just some hour ago I released the beta-3 of Redis ( http://code.google.com/p/redis/ if you care) and I'm near to feature-freeze with exactly with this goal. To make it rock solid (I'm going to use it in my start…

Not to be a naysayer, but I don't know that there's a lot you can do except run it yourself on a large, popular site that people have heard of. Companies like FriendFeed will use memcached cause LiveJournal/Facebook use it, they'll use MySQL because just about every web startup uses it, but no matter how awesome a project is, they're not going to use something complex that a few developers or some other startup wrote that hasn't been battle-tested on a large, well-known site. It's too risky compared to writing another one yourself that you understand.

Re: How FriendFeed uses MySQL to store schema-less data

#56

Post by antirez »

wayne wrote: post #55
antirez wrote: post #47

"However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs" Ok, just some hour ago I released the beta-3 of Redis ( http://code.google.com/p/redis/ if you care) and I'm near to feature-freeze with exactly with this goal. To make it rock solid (I'm going to use it in my start…

Not to be a naysayer, but I don't know that there's a lot you can do except run it yourself on a large, popular site that people have heard of. Companies like FriendFeed will use memcached cause LiveJournal/Facebook use it, they'll use MySQL because just about every web startup uses it, but no matter how awesome a project is, they're not going to use something complex that a few developers or some other startup wrote…

ok this sounds like I can have this goals:

1) Take Redis simple enough so that a single developer can understand the implementation in little time.

2) Run Redis on my own large sites. The problem is that while this sites are really large they are famous only in Italy. One example is http://oknotizie.alice.it

3) In the future when Redis will be stable and some little startup will start using it for real work try to collect success stories and write it in the front page of the project.

Re: How FriendFeed uses MySQL to store schema-less data

#57

Post by aaronblohowiak »

apgwoz wrote: post #29
jbert wrote: post #22

Earlier 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…

I don't see how this scheme can scale simply for the reason that there's no built in balancer. What's to stop shardN from becoming overwhelmed when all the power users end up there, while shardN-1 has no activity?

Edge-Case YAGNI. Have lots of shards, put multiple shards on each machine, shuffle the shards around as necessary. Rinse. Repeat.

Re: How FriendFeed uses MySQL to store schema-less data

#58

Post by jbert »

gnaritas wrote: post #51
mbreese wrote: post #44

Earlier quoted context omitted.

The above table wasn't too clear, but my understanding is that a shard exists on only a single machine, but that a single machine could host multiple shards.

Correct, you don't split shards across machines. Each machine hosts x number of shards.

OK, but # of shards is fixed "for ever" under the modulus scheme? You pick it once, when you first shard and then you're looking at downtime to adjust it?

In order to split across multiple dbs, you're looking at creating say 100/1000 dbs in our initial split (when you've got maybe 2-3 machines). And that number then caps the number of machines you can scale to without adding another layer (sharding-shards) or having downtime?

Re: How FriendFeed uses MySQL to store schema-less data

#59

Post by aristus »

antirez wrote: post #56
wayne wrote: post #55

Earlier quoted context omitted.

Not to be a naysayer, but I don't know that there's a lot you can do except run it yourself on a large, popular site that people have heard of. Companies like FriendFeed will use memcached cause LiveJournal/Facebook use it, they'll use MySQL because just about every web startup uses it, but no matter how awesome a project is, they're not going to use something complex that a few developers or some other startup wrote…

ok this sounds like I can have this goals: 1) Take Redis simple enough so that a single developer can understand the implementation in little time. 2) Run Redis on my own large sites. The problem is that while this sites are really large they are famous only in Italy. One example is http://oknotizie.alice.it 3) In the future when Redis will be stable and some little startup will start using it for real work try to co…

I've been evaluating databases recently. It doesn't matter if the site is not well-known in the US as long as you can post traffic numbers. TokyoTyrant is Japanese, after all.

Also these help:

   * able to handle large (>200GB) datasets
   * client libraries for top N languages
   * easy way to write client libs (eg simple protocol, a C library, etc)
   * connection pooling and/or cheap connections
   * easy to install on Mac, Linux and Windows development machines
   * repl (this is not much of a problem with Python & Ruby)
   * stable dump / restore format
One problem for you is that MySQL plus serialize() basically does these already, with 10+ years of testing on top. Your system has to do a lot more to make it worth the risk.

Re: How FriendFeed uses MySQL to store schema-less data

#60

Post by antirez »

aristus wrote: post #59
antirez wrote: post #56

Earlier quoted context omitted.

ok this sounds like I can have this goals: 1) Take Redis simple enough so that a single developer can understand the implementation in little time. 2) Run Redis on my own large sites. The problem is that while this sites are really large they are famous only in Italy. One example is http://oknotizie.alice.it 3) In the future when Redis will be stable and some little startup will start using it for real work try to co…

I've been evaluating databases recently. It doesn't matter if the site is not well-known in the US as long as you can post traffic numbers. TokyoTyrant is Japanese, after all. Also these help: * able to handle large (>200GB) datasets * client libraries for top N languages * easy way to write client libs (eg simple protocol, a C library, etc) * connection pooling and/or cheap connections * easy to install on Mac, Linu…

Agreed on most of the points... about MySQL, I developed Redis just because MySQL does not scale enough with given kind of datasets :)
Post reply on HN