Comments for Technology of Content

Comment on NoSQL and content management by Matt Browne

Matt Browne — Tue, 30 Aug 2011 15:38:33 +0000

@justin: Just wanted to say an overdue thank-you for the explanation - that definitely helps clarify things, and makes a lot of sense.

Comment on Search, SQL, NoSQL, Persistence by Bill Cava » Blog Archive » search as nosql

Bill Cava » Blog Archive » search as nosql — Wed, 24 Aug 2011 02:31:22 +0000

[...] Just found Justin Cormack’s fantastic blog post on Search, SQL, NoSQL, Persistence. It’s a great [...]

Comment on Re-architecting for the ‘green’ cloud and lower costs by markwilson.it » Re-architecting for the cloud and lower costs

markwilson.it » Re-architecting for the cloud and lower costs — Thu, 21 Jul 2011 12:29:37 +0000

[...] Justin has published his slides but he’s looking at ways to increase the scalability of our existing cloud applications. One idea is to build out parallel computing systems with many power-efficient CPUs (e.g. ARM chips) but Amdahl’s law kicks in so there is no real performance boost by building out – in fact, the line is almost linear so there is no compelling argument. [...]

Comment on JSON vs XML by Robert

Robert — Thu, 09 Jun 2011 16:02:17 +0000

JSON is for data XML is for documents

It really doesn't have to be any harder than that.

Comment on Scripting languages grow up by justin

justin — Sat, 28 May 2011 21:13:49 +0000

Actually I see awk as a text processing language rather than a general scripting language. Of course it influenced later scripting languages.

Comment on Scripting languages grow up by paurea

paurea — Sat, 28 May 2011 18:57:06 +0000

awk 1977. And I am sure there were others before.

Comment on Scripting languages grow up by justin

justin — Sat, 28 May 2011 09:52:10 +0000

Thanks, corrected that.

Comment on Scripting languages grow up by Isaac Gouy

Isaac Gouy — Fri, 27 May 2011 19:45:27 +0000

since Tcl began in 1988<

REXX March 20th, 1979

http://www.rexxla.org/rexxlang/ http://en.wikipedia.org/wiki/REXX

Comment on NoSQL and content management by justin

justin — Fri, 20 May 2011 10:17:53 +0000

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.

Comment on NoSQL and content management by Matt Browne

Matt Browne — Wed, 18 May 2011 00:22:26 +0000

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.