Google Datastore and deep records

Question

I'm in the beginning of creating a website that uses Google Datastore to store information related to clients and I'm curious if the record is too deep for NoSQL or if I'm fine.

Essentially I'll be storing details about clients at a fitness business that get's fairly detailed.

A completely made up record example could be

{
  firstName : "Jon",
  lastName : "Doe",
  assessment : [
    {
      date: "2013-01-31",
      flexibility:
        {
          leftShoulder: "12 whatevers",
          rightShoulder: "15 somethings",
          ...etc...
        }
      strength:
        {
          legPress: "100lb",
          shoulderPress: "22lb",
          ...etc...
        }
      ...etc...
    },
    {
      date: "2013-02-28",
      flexibility:
        {
          leftShoulder: "13 whatevers",
          rightShoulder: "14 somethings",
          ...etc...
        }
      strength:
        {
          legPress: "110lb",
          shoulderPress: "25lb",
          ...etc...
        }
      ...etc...
    }
  ],
  appearance: [
    {
      date: "2013-04-12",
      image: "http://blah"
    }
    ...etc...
  ]
  ...lots of other sub items...
}

This record would exist long term for clients and could become a very large record over time. I've seen on MongoDB, which is also NoSQL, has a 16MB limit on a record. While this is is a large amount of space for text and is plenty for big records, I want to make sure this just doesn't indicate that I should be separating these out in regards to NoSQL.

Instead, should I be separating out assessment and appearance records into their own separate records, linked by a foreign key of some sort or does that defeat the purpose of NoSQL?

What is the best practice for designing potentially long term, deep NoSQL records.

Answer 1

Unlike MongoDB, Datastore is not JSON-based. It does not store arrays or dictionaries. UPDATE: As of 2016, it can store arrays and dictionaries.

You can build a certain hierarchy of entities, but it mostly limits their transaction context and gives them implicit parent links. Though it allows for fetching a top entity (record) and all entities that list it as a parent, it does not provide a cascade deletion (unless expressly specified).

What I'd recommend is a top-level entity, one entity per assessment, and one entity per appearance.

Should you want to fetch all (or top few) assessment entities, use an ancestor query. But remember that reads are paid for in AppEngine, and you should be careful with the number of entities you read (or write), or you'll quickly exhaust the free quota.