semi-confused about semi-relational

I’m reading a 2012 google paper about Spanner.  I saw Spanner described somewhere as “semi-relational” and wanted to read more.  The paper I’m reading is “Spanner: Google’s Globally-Distributed Database” .

Early on, in page 4, is this paragraph:

“Spanner’s data model is not purely relational, in that  rows must have names. More precisely, every table is required to have an ordered set of one or more primary-key columns. This requirement is where Spanner still looks like a key-value store: the primary keys form the name for a row, and each table defines a mapping from the primary-key columns to the non-primary-key columns.  A row has existence only if some value (even if it is NULL) is defined for the row’s keys. Imposing this structure is useful because it lets applications control data locality through their choices of keys.”

This made no sense to me.  It’s not purely relational because every table needs a primary key?  In relational theory, every relation is required to have at least one candidate key.  Is this confusion between “logical” relational theory and current implementations that allow duplicate rows in tables?  Maybe because it’s an *ordered* set, is that the point?

To me, the not-relational part to me sounds like the fact that primary keys can include NULLs.

Or are they really referring to the fact that data are grouped somewhat hierarchically?  (As explained later in the paper.)  That would make more sense to me.

Anyway, those first three sentences confuse me.  But I’m new to a lot of this.  I’m just a simple caveman.  Your modern ways confuse me.  I’m not arguing that Spanner is purely relational, just saying that I don’t get those first three sentences.  Maybe someone can explain them to me.


3 Responses to “semi-confused about semi-relational”

  1. Justin Swanhart Says:

    I think it refers to the fact that spanner doesn’t technically support joins, but instead has a hierarchical data model where the child rows are packed with the parent rows (at least as I recall, using columnar format).

  2. ben Says:

    Hi Justin – that makes sense. It’s such a well-written paper, maybe it’s just that that one paragraph is not well-written. I thought maybe I was missing something… It just made me wonder whether it was me, or that the person who wrote that paragraph (there are over 20 authors credited on the paper) didn’t get it right.

  3. flyredeagle Says:

    I am also an old men, and these kids never learned at school that IMS was substantially invented for billing the apollo project ….

    The topology is substantially a set of trees, probably not connected as of 2012, the industrial secret is that they are probably working to go for foreign keys after the paper.

    Two further links of copycats claiming this same semi-relational claim (have these people red the same document ?) :

    nosql + hierarchical :

    Same hierarchical json alike api structure that maps the DB behind

    But is substantially speculations about industrial secrets they don’t really want to tell and we are yet 2 years behind of what they told us.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: