Aaron Stone wrote: > > Right, simply shard the tables that contain messages on a per-user basis. > Figuring out a sharding policy for shared mailboxes is probably the only > really hard part. It's otherwise totally standard practice. > > One technique I've seen is to have one common database and several users > databases. The common database holds configs, user-shard lookups, and any > other random not-user-associated data. The users databases contain all the > heavy stuff. If a shard gets too big, a resharding tool can move a user > from one database to another, verify their data, flip their common database > shard-lookup entry to the new database, and then clean up.
That's the exact use-case that I have in mind. Being able to move a user from one backend to another for me is a prime motive for this project. The only problem I have with Jon's idea of mailbox sharding is that I fear it's one bridge too far at this point. It sounds great, no doubt. But I can't see it happen in the near future unless someone starts to hire a google-class engineering team :-) So I'm not against mailbox sharding perse, but user-sharding is within our grasp at the moment, so I'd like to start with that. Once we have solid user-sharding in place I'm pretty sure we can revisit this discussion because by then we'll have a much better understanding of the problem domain. But first, let's get 2.4 ready, starting with 2.3.6! Almost there, we are. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
