Home/ Questions/Q 353361
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T11:49:22+00:00

I’m working on early designs for an application that needs to start out small

  • 0

I’m working on early designs for an application that needs to start out small but be highly scalable. I’m particularly worried about the user database, which in this case will have a high INSERT and UPDATE load, and is unlikely to survive long on a single master.

(Although my question isn’t tied to any particular RDBMS, for the record, we’ll be using MySQL, and MySQL Cluster doesn’t really meet our needs, so we need to roll our own solution on this one using stock MySQL + InnoDB.)

I’m considering a strategy of distributing users amongst MySQL masters based on a hash of their username (plus an unknown-to-user salt just as added insurance against any funny games). I’ve seen solutions like this used successfully before, but I’ve never designed/implemented it myself.

What I’d like some input on is:

1) Suitable hashing algorithms. I expect SHA-1 or even MD5 would work just fine for this, since cryptographic security really isn’t the goal, but I’m not sure if there might be other algorithms out there that might have desirable properties for this sort of problem. Something a little faster might be nice, too.

2) Any major caveats anyone can think of. (I’m already very conscious of the potential connection pool problem, as well as the fun in adding new masters to the pool and migrating affected users.)

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problem with a hash based solution is moving users. Consider the following scenario – you have 3 users and 3 servers. User A has a hash that results in their connection being allocated to server A by your software, User B connects to server B, User C connections to server C. What happens if server B goes down, or you want to migrate user B to a new server, D, because server B is overloaded – you can’t, because your software is coded to take a hash of the username, and connect to a server based on that has.

    Also you’ll have the problem of distribution – the hashes for users A, B and C may well resolve to server A, so servers B and C are sitting idle.

    Personally I’d replicate the user-database table amongst all of the servers, then randomly connect to a server at startup, find what their actual database server is, and continue at that point. That way you can move users easily and, if you replicate data between at least two servers, you have redundancy should a server fall over.

    • 0