Comments on: NoSQL and content management http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/ Ramblings on the technology of content management Tue, 30 Aug 2011 15:38:33 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Matt Browne http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-16360 Matt Browne Tue, 30 Aug 2011 15:38:33 +0000 http://blog.technologyofcontent.com/?p=216#comment-16360 <p><a href="#comment-16341" rel="nofollow">@justin:</a> Just wanted to say an overdue thank-you for the explanation - that definitely helps clarify things, and makes a lot of sense.</p> @justin: Just wanted to say an overdue thank-you for the explanation – that definitely helps clarify things, and makes a lot of sense.

]]> By: justin http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-16341 justin Fri, 20 May 2011 10:17:53 +0000 http://blog.technologyofcontent.com/?p=216#comment-16341 <p>My suggestion is that <em>everything</em> goes into the document database, including all the versioning information, and whatever is needed for queries goes into the graph database, which probably does not include large blobs (send these off to your full text search), and not old versions. It might in some cases be a performance optimisation to have everything in the graph database though, just so you could answer queries without referring back to the document database at all.</p> <p>You could argue it is a complication, but the document database is very simple, and is mainly aimed at versioning and being system of record, while the graph database answers queries on the current version, which seems a clean separation to me.</p> My suggestion is that everything goes into the document database, including all the versioning information, and whatever is needed for queries goes into the graph database, which probably does not include large blobs (send these off to your full text search), and not old versions. It might in some cases be a performance optimisation to have everything in the graph database though, just so you could answer queries without referring back to the document database at all.

You could argue it is a complication, but the document database is very simple, and is mainly aimed at versioning and being system of record, while the graph database answers queries on the current version, which seems a clean separation to me.

]]> By: Matt Browne http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-16340 Matt Browne Wed, 18 May 2011 00:22:26 +0000 http://blog.technologyofcontent.com/?p=216#comment-16340 <p>Very interesting, thoughtful, and informative post - thank you.</p> <p>One question - when you say, "Direct, nondenormalized graph database backends, with the raw content stored in a document store," I'm wondering what exactly would be stored in the graph database versus the document store.</p> <p>It seems that everything could be stored in the graph database, including large blobs like the body of an article...</p> <p>Are you suggesting that the "properties" like would go in the document database (e.g. title, body, date published, etc.) and "relations" (e.g. author, tags, etc) would go in the graph database?</p> <p>It seems like a nice idea in principle (combining two database technologies to get the strengths of both) but wouldn't it complicate things to have the data for the same entity split across two separate databases?</p> <p>It's entirely possible that I'm misunderstanding you - in any case, I'd be really curious to hear your comments on this.</p> Very interesting, thoughtful, and informative post – thank you.

One question – when you say, “Direct, nondenormalized graph database backends, with the raw content stored in a document store,” I’m wondering what exactly would be stored in the graph database versus the document store.

It seems that everything could be stored in the graph database, including large blobs like the body of an article…

Are you suggesting that the “properties” like would go in the document database (e.g. title, body, date published, etc.) and “relations” (e.g. author, tags, etc) would go in the graph database?

It seems like a nice idea in principle (combining two database technologies to get the strengths of both) but wouldn’t it complicate things to have the data for the same entity split across two separate databases?

It’s entirely possible that I’m misunderstanding you – in any case, I’d be really curious to hear your comments on this.

]]> By: Brussels JUG » FOSDEM 2010 – Retrospect http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-5552 Brussels JUG » FOSDEM 2010 – Retrospect Wed, 31 Mar 2010 13:17:04 +0000 http://blog.technologyofcontent.com/?p=216#comment-5552 <p>[...] free software event in Brussels: http://ileriseviye.org/blog/?p=2884 NoSQL and content management: http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/ Report from FOSDEM 2010: http://developer.yahoo.net/blog/archives/2010/02/fosdem_2010.html Womoz [...]</p> [...] free software event in Brussels: http://ileriseviye.org/blog/?p=2884 NoSQL and content management: http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/ Report from FOSDEM 2010: http://developer.yahoo.net/blog/archives/2010/02/fosdem_2010.html Womoz [...]

]]> By: justin http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-4713 justin Tue, 23 Feb 2010 04:14:37 +0000 http://blog.technologyofcontent.com/?p=216#comment-4713 <p><a href="#comment-4695" rel="nofollow">@Matt Hamilton:</a> Thanks for reminding me - had forgotten that Zope had done that while I write this while I was writing this. It has always been an interesting framework.</p> @Matt Hamilton: Thanks for reminding me – had forgotten that Zope had done that while I write this while I was writing this. It has always been an interesting framework.

]]> By: Matt Hamilton http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-4695 Matt Hamilton Mon, 22 Feb 2010 08:01:41 +0000 http://blog.technologyofcontent.com/?p=216#comment-4695 <p>One CMS system worth mentioning here is Plone. It is built upon Zope, which has been doing NoSQL for over a decade now.</p> <p>Plone sort of fits between points 3 and 4 above in your article. The ZODB is a persistent object store which natively stores objects (ie no need for an ORM). It is transactional, had MVCC and can be easily clustered.</p> <p>Plone has a couple of content type systems. Archetypes is the older one with a richer set of widgets. You can draw up a whole information model in a UML editor and get it converted into a set of installable content types, complete with all relations and containment heirarchy.</p> <p>Dexterity is the new content type system and socked the problem that CCK and most other systems have of being unable to easily switch from a web based point and click method for building types and creating them in code on the filesystem (so they can be versioned in your VCS).</p> <p>-Matt</p> One CMS system worth mentioning here is Plone. It is built upon Zope, which has been doing NoSQL for over a decade now.

Plone sort of fits between points 3 and 4 above in your article. The ZODB is a persistent object store which natively stores objects (ie no need for an ORM). It is transactional, had MVCC and can be easily clustered.

Plone has a couple of content type systems. Archetypes is the older one with a richer set of widgets. You can draw up a whole information model in a UML editor and get it converted into a set of installable content types, complete with all relations and containment heirarchy.

Dexterity is the new content type system and socked the problem that CCK and most other systems have of being unable to easily switch from a web based point and click method for building types and creating them in code on the filesystem (so they can be versioned in your VCS).

-Matt

]]> By: NoSQL and content management – Technology of Content | Drakz Free Online Service http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-4538 NoSQL and content management – Technology of Content | Drakz Free Online Service Mon, 15 Feb 2010 17:40:02 +0000 http://blog.technologyofcontent.com/?p=216#comment-4538 <p>[...] from: NoSQL and content management – Technology of Content Share and [...]</p> [...] from: NoSQL and content management – Technology of Content Share and [...]

]]> By: NoSQL and content management – Technology of Content | Drakz Free Online Service http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-4535 NoSQL and content management – Technology of Content | Drakz Free Online Service Mon, 15 Feb 2010 15:44:14 +0000 http://blog.technologyofcontent.com/?p=216#comment-4535 <p>[...] NoSQL and content management – Technology of Content Share and [...]</p> [...] NoSQL and content management – Technology of Content Share and [...]

]]> By: Michael Kowalski http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-4534 Michael Kowalski Mon, 15 Feb 2010 14:40:56 +0000 http://blog.technologyofcontent.com/?p=216#comment-4534 <p>I've been puzzling over this stuff a lot recently as well, and this is a better analysis of the pros and cons than I could have managed. The attractions of moving to a model that maps more closely to the content management domain are obvious. You hit the nail on the head with this line though: "the sweet spot in a few years once the products mature".</p> I’ve been puzzling over this stuff a lot recently as well, and this is a better analysis of the pros and cons than I could have managed. The attractions of moving to a model that maps more closely to the content management domain are obvious. You hit the nail on the head with this line though: “the sweet spot in a few years once the products mature”.

]]> By: Most Tweeted Articles by Distributed Systems Experts: MrTweet http://blog.technologyofcontent.com/2010/02/nosql-and-content-management/comment-page-1/#comment-4525 Most Tweeted Articles by Distributed Systems Experts: MrTweet Mon, 15 Feb 2010 11:02:22 +0000 http://blog.technologyofcontent.com/?p=216#comment-4525 <p><strong>Your article was most tweeted by Distributed Systems experts in the Twitterverse...</strong></p> <p>Come see other top popular articles surfaced by Distributed Systems experts!...</p> Your article was most tweeted by Distributed Systems experts in the Twitterverse…

Come see other top popular articles surfaced by Distributed Systems experts!…

]]>