also, what's high-end about an in-ram database? It's all cheap commodity parts; my cost for a full on 8 core box with 32GiB ram is well under $1500, and around two amps of (American 120v) power. This is decidedly low-end, until you get, you know, a few marketing guys and 3 vars in the mix and start paying double for hardware put together by people who don't believe that ESD is a problem.

It's awesome that you can get servers like that for those prices these days. One of my customers recently purchased a similarly configured PowerEdge.

What is high-end about the database is you are trying to get high-end performance. Having all the data in RAM is the "close to the hardware" part of getting that performance. Having multiple computers is the parallelism part of that performance. Having virutualization sticks a software layer between MySQL and the RAM, and if you have other VMs running on the hardware, then any performance numbers will be dependent on what the other VMs are doing. Of course, if you have all the NDB nodes running as VMs on the same machine, then that will never be as fast as one NDB node running native on that same machine.

If you are using the virtualization environment as a way to partition customers, consider that MySQL already does this well. A web hosting shop can have a singkle MySQL server and give each customers a database or databases and a user / pass to access only their own stuff.

well, if you needed 32GiB ram, sure. But most things don't need 32GiB of ram, and it just doesn't make any sense to host servers with less ram than that.

So yeah, a dedicated server would be better, but probably not all that much better than a properly configured virtual, and the virtual is a whole lot cheaper.

The database that I am trying to work into a master-slave replication environment currently has a 500 GB InnoDB file. ( I think since some cleanup was done, the database no longer has that much data in it, but the InnoDB file doesn't shrink. We could dump / undump it to get a clean InnoDB, but it takes 24 hours to dump it and about that to read it in, and we can't be down for multiple days.)

If the virtual nodes are on the same hardware, you also loose the parallelization speedup and the reliability from redundancy, but you have them spread accross physical machines I presume ?

All that said, your setup is probably good enough to learn on and do some testing. I wish I had some real-world load to throw at it.

I think you are right that you could sell NDB MySQL as a service; there is a demand for it, particularly the reliability and allways-up aspects, I think. I think that for people who want more performance, you would do better selling a set of pre-configured machines to deliver to them, and some consulting time, perhaps in partnership with someone who specializes in MySQL performance tuning.

I think that could be pretty lucretive. It would all be a matter of getting the setup down pat and then finding those customers (the hard part).