“NoSQL technologies” interview with John Clapperton
Happy New Year!
We start in the new year with a topic we covered already in 2009: “NoSQL technologies”.
I asked this time John Clapperton for his opinion. John Clapperton BSc CEng MBCS CITP is proprietor and author of the ‘VOSS’ virtual object storage system, which extends Smalltalk with integrated database management, providing transparent access and transaction processing of persistent, versioned, Smalltalk objects. Previously, John has worked on database applications and research at Standard Telephones & Cables, Unilever Research, Acorn Computers and Deductive Systems.
RVZ: John, are object databases “NoSQL” technologies?:
John Clapperton:: The absence of SQL in “NoSQL” databases is less an a priori choice than a consequence of their simplified schema capability, imposed in the interests of higher performance, being unable to support the full set of SQL language constructs. It does not follow, therefore, that object databases from which SQL has been excluded for the opposite reason, as a language unable to address their more general representational capabilities, should be automatically included in the NoSQL classification.
A person thinking of adopting a NoSQL database will have certain capabilities in mind, so the question is really “Might an object database have ‘NoSQL’ capabilities?”
These include:
1) Data partition (which is application dependent).
2) Optimistic locking (which helps only if most accesses are read-only).
3) Relaxation of ACID transaction rules by:
4) Fast navigational access to arbitrary data structures.
and in principle, an object database is capable of any or all of these.
The characteristics of an object database are its ability to manage arbitrarily complex object structures and to represent relationships by explicit named references. These have the potential for better performance by, respectively, reducing the required number of file writes for (de-normalised) data structures, and fast navigation of direct references instead of relational joins. However, against that must be set the cost of serialising arbitrary object structures for durable storage and instantiating the same on retrieval, compared with the simpler handling of pre-defined rows in a relational database.
Normalisation of behaviour, encapsulated in class definitions in language persistence odbms such as Logic Arts’ VOSS for Smalltalk, reducing implicit replication in application programs and queries, may have an advantage in NoSQL applications, but it’s not clear to me how significant that might be, given that its benefit is in managing complexity whereas NoSQL applications tend to be simpler.
