How to model entities in Google’s Datastore

Question

The Datastore used by Google’s App Engine, unlike a relational database engine, does not enforce schemas – instead of rows and columns, it stores entities with various properties. Nevertheless, should one still use a traditional database design?

For example, let’s say I have an application that tracks various rental vehicles. In a traditional database, I may have a Buses table, which tracks the length and number of seats for each bus in the fleet, and Trucks, which has a column for the load capacity and horsepower for each truck. Each bus and truck also has a color and license plate number. (If I want to normalize the database, I could break out these attributes in a Vehicle table).

In Google’s Datastore, I’d be tempted to simply store buses and trucks as Vehicle entities, as they share common properties, and add whatever properties are specific to the type of vehicle.

What are the advantages/disadvantages to using a traditional database model, where each Datastore entity represents a database table?

Is it more efficient to break large entities into smaller entities?

EDIT:

Also, any recommendations regarding which API to use: JDO, JPA or the Datastore low-level API?

Thanks!

Answer 1

This was a question that puzzled me for long. I think the way you would want to search on the entity later makes a significant difference in deciding a design model. Some thing that hurt me was that, in App Engine you can't use inequality filters on multiple properties of the same entity.

Eg: You can't query a 'Person' entity for age>20 and height<170 . Because age and height are different properties on the same entity.

I have used JDO for my application and it's working fine so far. I decided to use it since this book I had, provided many real-world examples of jdo queries in app engine.

I had to denormalize and split these properties to do the queries. You can watch the Bret Saltkin's video at Google I/O to get a better understanding of db design methods. I've done and entire cover-up of my experience with datastore modelling in Google app engine here.

Answer 2

If you are using Python, look at the PolyModel class. It provides a convenient way to denormalize your data, while still keeping some logic separations between different kinds. If you will have many kinds you can achieve the same result as a PolyModel using an Expando.

In general the size of an entity will have little impact on performance. The number of entities has a much larger performance impact. In other words, favor fewer entities.

As klausbyskov pointed out, do not think in terms of relational databases. Ultimately the performance of your app will probably suffer because you will need to make many additional queries and fetches. To understand some of the key differences check out the 'Mastering the Datastore' articles.

Answer 3

You should not be thinking about tables at all. Think about entities. The documentation states that:

Datastore entities are schemaless: Two entities of the same kind are not obligated to have the same properties, or use the same value types for the same properties. The application is responsible for ensuring that entities conform to a schema when needed.

The best performance is usually achieved by de-normalizing data. So you are probably better off with two distinct entity types, Bus and Truck and ignoring the fact that they share some properties.