CLI on server part 2

Greg Hinkle greghinkle at gmail.com
Tue Jan 11 16:31:25 UTC 2011


To add some historical perspective...

We considered several content management stores, JCR repositories and SCMs before deciding to keep bundle and package data in the db. This data did not place untenable load on the database even when considering thousands of packages read by hundreds of machines and certainly scripts would have a negligible impact. We considered other stores more for the value of their client interfaces than because of the versioning they offer. It would be useful to let someone manage packages by committing to git or copying a file to WebDAV... but then you're still likely to have to track the versions and access control and host of other things in the relational store. 

In other words this data is linked to other parts of the persistence model. Referential integrity is important as is transactional access. If you store a bundle, script or package in an on-disk SCM how do you ensure referential integrity to the installed version, the resource its deployed to, etc.? Then consider backups, clustering and recovery... right now it's as simple as having a valid RDBMS backup strategy, but as soon as you introduce a separate store you'll have to back that up. Then what happens if your SCM get's out of sync with the related records in the DB? If you cluster with a cluster file system then you have to install, monitor and maintain that store and deal with network setup, host OS differences, etc.

It can certainly be done, but make sure to consider all the work and what you're really getting out of switching the storage. At the time, since I thought the client access was the most valuable part, I just considered putting a JCR and WebDAV front-end on the store instead. You could use the db to get data around the cluster and have a lazy local file system cache to reduce reads on a db that may be in a different data center without having to worry about the rest of it.


The event store, as well as all other metrics, are somewhat of a different beast entirely. They have a much higher potential txn rate and a simpler relational model with less severe consequences for consistency. Many would consider eventually consistent and partitioned storage of this data just fine... but would you want inconsistent views of the package or bundle your deploying or the values of a configuration... or a script your executing? Oops we just deployed the wrong version of the app to the node in the other datacenter :)


-Greg


On Jan 11, 2011, at 10:58 AM, John Mazzitelli wrote:

> 
> On 01/11/2011 10:34 AM, Alan Santos wrote:
>> Are you speaking of integration in general or to address the needs of a
>> content store?  If the latter, I'm surprised to see splunk in that context.
> 
> splunk has come up in the past as a possible solution to our events 
> storage problem.
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list