On Dec 19, 2008, at 11:49 AM, Roy Lyseng wrote:
>
>
> Tim Soderstrom wrote:
>> On Dec 19, 2008, at 10:29 AM, Brian Aker wrote:
>>> Hi!
>>>
>>> On Dec 19, 2008, at 1:33 AM, Roy Lyseng wrote:
>>>
>>>> Is it not easier to limit that on a tablespace level?
>>>> Assign one tablespace per user with some fixed maximum disk space.
>>>> Make sure that a user only sees the database objects (schemata,
>>>> tables, tablespaces, ...) that (s)he has access to. (hopefully
>>>> this is already implemented in MySQL/Drizzle - I did not check...)
>>>
>>>
>>> Except for the disk space limitations, I am 90% sure I could write
>>> a module that did this today. The only thing I could not control
>>> is the Innodb buffer size... for that I believe I need Innodb to
>>> be able to handle multiple contexts.
>> I'd say controlling the buffer pool is more important really.
>> Without that, another user can thrash the buffer pool with a few
>> silly queries and make it painful for the rest of the users on the
>> system.
>
> For even better control, fire up a Solaris zone and a database
> instance inside it. Then you can control IP, disk quota, memory
> usage, CPU, etc, and probably simpler than partitioning the database
> server...
Yeah, but that's basically virtualizing or user-mode segmentation type
stuff it sounds like. We can do that today but there's overhead in
managing all that. And MySQL starts competing with itself for
resources. What if you have, say, 200 customers on one box, for
instance. That's a ton of VMs or slices to mess around with. Granted,
the solution works today and it's less complicated than inventing a
new way of doing something like this, but you take a pretty big
penalty for doing that I'd say.
Tim S.
