Not trying to offend you, really.
No offense taken, Trausti. Really.
But how about getting big before planning sharding ?
Agreed, at least as far as 'we won't need to do it for a good long
while.' I was just saying that sharding rather than clustering is the
eventual path we'll take. Much of that decision is based on another
decision: deploying on EC2.
You can get really big with just tweaking mysql on a 4 core server and
then you can have loads of memory and eventually you can keep
everything in memory. Then you can cache the site, and then you can
put varnish cache in front. I work on a site with more than 1.5
million individuals visiting each and every day, not distributed
evenly, and for the most part it is a single mysql server, single web
server and varnish cache. This setup replaced 14 squid servers that
used to be in front.
Understood. And thanks for the numbers. I've got a lot more
investigating / benchmarking to do before I know what our 'break point'
will be. Most of the usage of the site I'm working on now will be
updates rather than reads. I know that MySQL is optimized for reads,
and there's lots of numbers out there for that but I haven't seen as as
much about the update side of the performance.
(We actually have everything with fail over and more setup, but mostly
to keep things simpler). With the setup we have, we can grow a lot
bigger before we need to increase anything.
Thanks much for your reply. I appreciate it!