Re: CMS tutorials

J C Lawrence <[email protected]> Sun, 21 Dec 2003 21:23:36 -0500
Newsgroups gmane.comp.cms.general
Message-ID <[email protected]>
On Mon, 22 Dec 2003 02:45:14 +0100 
Bastian Gerhard <[email protected]> wrote:

> I'd also recommend to store binary objects as BLOBs in the database,
> although I have not seen any RDBMS handling them well either.  Storing
> them in the filesystem often does not work under certain
> circumstances: Just keep redundancy and cluster environments in
> mind... 

I've not found a problem for my loads.  There are several cluster
filesystems readily available to handle the distributed and redundant
cases, as well as things like snapshotting for transactionally clean
backups.  Most of the rest of the time when transactional consistency is
not required is trivially framed, tools like rsync do the job just fine.

> It is much easier to mirror and backup a database than a filesystem -
> not only for security reasons. 

I'd argue strongly here.  A proper set of capability models and a
snapshotting filesystem works wonders for this space and if well
constructed reduces the number of possible threat vectors over a
DB/protocol exchange.  I currently do this on a regular basis with a few
hundred Gig and quarter TB setups.

> Implementing an RDBMS/CMS into an existing cluster environment whereas
> binary objects are being stored in the filesystem can be a non-trivial
> job.

Aye.  The real problem and concern is write/lock synchronisation along
with transactional coherence across the cluster.  The problems get
really ugly if you're in a write-heavy environment with strong and
fine-grained coherency requirements.  The coarse grained locking of most
filesystems implementation makes that space an utter bear.  You can
escape a lot of it using a clustered filesystem with snapshot support if
you don't need fine-grained updates and can afford the snapshot
overheads:

  Have all writes commit to a private point and have all nodes read from
  a fixed filesystem (eg symlink to a mountpoint).  Then periodically
  snapshot the write point and sync out the new level to the top of the
  clients.  You then snapshot that or move the symlink to point the
  clients at the new level...

That said, again depending on your read/write behaviour (eg appending is
the simple case), if you build out from a clustered filesystem which
natively supports the fine grained locking then many of the problems
can pretty much fall out.  Cluster XFS is particularly interesting in
this space.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email protected]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
--
http://cms-list.org/
please trim your posts.