Comment by RyanZAG | Hacker News Reader

Comment by RyanZAG | Hacker News Reader

I'm fairly amazed by some of the choices - in particular the single huge user table that is hit on every profile page view to map url to shard. I'm guessing it has hot backups and similar - but wow - talk about a single point of failure. I guess having it like that actually makes it easier. If it fails, it should be trivial to get it back up quickly on a backup machine.

The whole setup seems a lot simpler than nearly every 'web scale' solution I've heard discussed.

EDIT: I'm not saying that is a bad thing - it's a good thing. Most of the articles around scaling on HN often deal with very complex Cassandra style technical solutions. This article is the opposite with a very 'just do it the simplest way' feel to it. One big mysql table for all users (probably with some memcache in front) is the sort of thing you can put together in an hour or two - yet it is the very core of their system.

I (and I bet a lot of other engineers reading HN) try to focus too much on perfect implementations - if someone asked me to design the shard look-up for something as heavily hit as this, I'd probably reach for a distributed in-memory DB with broadcasted updates - and I'd probably be wrong to do so. The mysql/memcache approach is just going to be simpler to keep running.

You don't really want to get into the alternatives. It's pretty common to shard everything but the core user data (email, PBKDF2, username) and scale that with slaves and vertical upgrades. SSDs can take you a long way if you're fastidious about offloading everything else off the machine responsible for keeping user accounts consistent.

The alternatives aren't nice.

I agree. Usually it is better to scale vertically on the user data. Even if it seems painful. The alternatives like partitioning are not really that easy either. There is pain involved as well.

I think, of the existing solutions, one is not better than the other. The choice in the end is which one fits best with your team and infrastructure, and specially which disadvantages are you willing to put up with.

One table for users is a no-brainer. The outer limit on table size is ~7 billion rows.

And that's just not a very big table these days.

That’s not what they’re doing. They are sharding horizontally on the user. ID’s are 64 bits with the db location (logical shard id) in the first 16 bits. This will allow anyone with an ID to go to the right db for querying, granted they have logical to physical shard mappings.

From the article:

User table is unsharded. They just use a big database and have a uniqueness constraint on user name and email. Inserting a User will fail if it isn’t unique. Then they do a lot of writes in their sharded database.

Get the user name from the URL. Go to the single huge database to find the user ID.

I believe the parent is correct.

I see. We tackle the same issue by having a redis keyspace with emails. It can get pretty huge without any problems.

This might be a silly thing to ask, but why don't they save their data in flat files on a shared filesystem?

They wouldn't need Memcached, since the OS caches files anyway; replication with rsync becomes easy; they don't need transactions anyway; and they wouldn't have so much software to manage.

Storing, tracking and managing billions of tiny files directly on a file system is a nightmare

What about it is a nightmare?

Isn't storing, tracking, and managing billions of entries done directly in a database anyway?

Its a real pain when you want to inspect the files, delete or copy them.

Try taking 300,000 files and copy them somewhere. Then copy 1 file which has the size of the 300,000 combined. The single file is MUCH faster (its also why we usually do a tar operation before copying stuff if its already compressed). Any database that's not a toy will usually lay the 300,000 records out in a single file (depending on settings, sizes and filesystem limits).

The 300,000 files end up sitting all over the drive and disk seeks kill you at run-time. This may not be true for a SSD but I don't have any evidence to to suggest this or otherwise.

Even if the physical storage is fine with this I suspect you may run into filesystem issues when you lay out millions if not hundreds of millions of files over a directory and then hit it hard.

I have played with 1,000,000 files before when playing with crawling/indexing things and it becomes a real management pain. It may seem cleaner to lay each out as a singe file but in the long run if you hit a large size the benefits aren't worth it.

In addition,

It doesn't have good querying utilities. You'd have to build your own indexer and query engine. Since you can't put billions of files in a single directory, you'd have to split them into a directory tree. That alone requires some basic indexing functionality and rebalancing tools (in case a single directory grows too large or too small). This is without any more sophisticated querying capabilities like “where X=val” where X isn't the object ID/filename.

Write performance is going to be very very horrible.

Existing tools around managing, backing up and restoration, performance optimisation and monitoring aren't suitable for handling huge number of small files as well as a subset of them (give certain criteria related to the data itself)

You could build specialized tools to resolve all of these issues, but in the end, you'd end up with some kind of database after hundreds of man-years anyway.

Since they're MySQL pros, they could put that on a MySQL Cluster and get high availability (up to 30 or so machines in the cluster, use a larger replica count, on top of drive mirroring, etc.) Also, it's a read-heavy workload, so hide it behind memcached.

Reply on news.ycombinator.com