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.