Hacker News Reader

Comment by RyanZAG | Hacker News Reader

I was under the impression they use it more as a sharded "key-values" store?

ie. no joins - the part of the database that makes it relational.

I concur. In our shop we also use MySQL without the joins. That's like an efficient key-value store, but there must be a better solution somewhere: all the joins are done in client code, and caching too. That's a great amount of error-prone code that probably shouldn't be necessary.

"all the joins are done in client code"

What's the point of joining in the application level? If you're going to join, why not do it in the database? That should be both faster and more convenient (unless your schemas aren't relational at all, in which case I don't see why you'd use a relational database)

Data for User A is on server 9, and data for User B is on server 43. Joins across servers is not really supported in mysql.

Another issue is connections between DB servers. Generally you want your DB server to be as fast as possible, so having it handle the connections to other servers slows everything down. If you offload the DB server connections to your web server, you can easily scale by just adding more web servers and having each DB server handle only its own data.

The best solution would be some type of 'mysql proxy' that could run on every web server that would transparently handle the joins between all the different mysql data servers. I think I saw a project attempting to do this awhile back, but didn't really keep track.

This is because join negatively impact the scalability of a DB: - When huge amount of traffic hits your DB, out of the most commonly run-out resources - CPU, Memory, and IO - CPU is usually the one that runs out first. And Join uses quite a bit of CPU. - When you have a lot of data and have to partition it, you will feel so lucky if you don't have to deal with distributed joins.

Reply on news.ycombinator.com