[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rhq-devel
Subject:    long term scalability thoughts
From:       ian.springer () redhat ! com (Ian Springer)
Date:       2011-08-11 15:40:26
Message-ID: 4E43F7EA.9040303 () redhat ! com
[Download RAW message or body]


> > The key thing to take away though is that
> > a flexible infrastructure is being put in place that allows users to
> > plug in different back ends with different performance and scalability
> > characteristics.
> > 
> The unstated trade-off is what? manageability? Otherwise why not just go with only \
> the most performant, scalable option? 
> 

I tend to agree that making the back-end storage mechanism 
pluggable/configurable for the various subsystems may not be worth it, 
since it adds more permutations to maintain and support, particularly if 
the NoSQL mechanism has equivalent or superior performance even at 
smaller scales. However, the one reason I could see doing it is if using 
the NoSQL mechanisms requires additional work for the user to install 
and configure. For example, if a user with a small scale environment had 
to spend extra time installing and configuring Mongo, on top of the 
usual time to install a DB, Servers, and Agents, then that user might 
not be thrilled. I think if we start switching certain subsystems to use 
NoSQL storage mechanisms, we should ideally bundle that software with 
the RHQ distribution and automatically install and configure it within 
the Server installer. Of course, there could be additional steps that 
users with large environments could optionally perform like adding 
additional nodes to Mongo on machines not running RHQ Servers.


[prev in list] [next in list] [prev in thread] [next in thread]