Amazon SimpleDB: Ideal for Social and Mobile Applications?

Summary: As a developer, look at SimpleDB as an XML document.  Use it for social apps like Facebook and mobile applications.

Amazon SimpleDB stores accessible data in the Amazon cloud.  It is not a traditional relational database.

Amazon is one of the biggest digital stores online, selling physical products and also digital services as this one, since ecommerce is really popular now a days, with people even investing money in things like bitcoin, that you can store in physical wallets as the one in these Ledger Nano S vs Trezor reviews, Amazon took advantage of this and start selling this products online as well.

Alan Williamson makes the case for renaming the service to Amazon Registry to better describe his view of the service. I think this is close, but not quite right.  Google calls its datastore BigTable.  If I was doing the naming for Amazon, I might call SimpleDB “BigDocument.”As a developer, the way I look at SimpleDB is as a set of arbitrarily large XML documents.  The data is hierarchical, easily changed, and does not need to match within each element. Those are all advantages!

SimpleDB implements a hierarchy of Domains, items, and attributes.
I could have a domain called Users.
Users contains items which have an item name and a list of attributes.
Attributes are a set of Name/Value pairs.

For the Users domain, I want to carry a unique id per user, the timestamp that they added the application and the last time they access the app.
That looks something like:

Domain: User
———–Items: Unique Identifier(user_id)

When a user takes an action, I would want a different data store.  We can consider a hypothetical game of Rock/paper/scissors to be played between 2 people.
One person has a turn and
1. Chooses an opponent
2. Chooses rock, paper, scissors
The opponent is notified and chooses rock, paper, or scissors and the game winner is decided.

Thus far, when I’ve used SimpleDB, I’ve created a separate Domain for this.  Call it GameTurns.

Domain: GameTurns
———–Items: Unique Identifier (player1+player2+date_time_stamp_
———————-Player1 selection (Rock,paper, scissors, none)
———————-Player2 selection (Rock,paper, scissors, none)

When Player1 logs in, I would check the GameTurns Domain for game results or new challenges.
Domain queries take the form:
select output_list
from domain_name
[where expression]
[limit limit]

When I am using Facebook or another social site, I will have a unique_id that for this query I will call ‘current_user_id’.
So I could try:
select * from GameTurns where Player1_id=’current_user_id’
select * from GameTurns where Player1_id=’current_user_id’ or Player2_id=’current_user_id’

One of the limits of SimpleDB is that there are 100 Domains per account.  That does not seem like a lot.  And there is a general assumption of associating a domain with a table in a database.
But Items within a domain do NOT need to match in format or content.  So my GameDomain could contains items of type User and type GameTurn.

Domain: GameDomain
———–Items: Unique Identifier(user_id)
———————-type: (user)
———–Items: Unique Identifier (player1+player2+date_time_stamp_
———————-type: (gameturn)
———————-Player1 selection (Rock,paper, scissors, none)
———————-Player2 selection (Rock,paper, scissors, none)

So in this case, rather than having 2 domains, I’ve introduced a new attribute called type for the item.  Type can either be user or gameturn.

Now my query would look like:
select * from GameDomain where type=’gameturn’ and Player1_id=’current_user_id’
select * from GameTurns where  type=’gameturn’ and ( Player1_id=’current_user_id’ or Player2_id=’current_user_id’)

I did not cover the idea that attributes can have multiple values.  That can come in handy for items like products that have user ratings.  There may be no ratings or there may be multiple.  That should be easy to envision within an XML document. AN even easier example is a book with multiple authors.  That’s a typical XML example.

In social applications like Facebook, you can get user profile info based on a user id.  SimpleDB makes a good datastore for user ids.  As with the example, most social applications are based on the concept of users interacting with each other. By  uniquely identifying a transaction based on user ids and timestamps, you can use SimpleDB as an effective lookup for user activity.  User1+User2+timestamp = Unique transaction id.

The same holds true for mobile.  In the case of Android, when SimpleDB returns XML data the adapter concept works well for handling and displaying that data.  (More on that in a separate post).

For mobile applications, SimpleDB can stand on its own.  The client is the device.  SimpleDB is the remote datastore.  There is no need for a web hosting service.

3 thoughts on “Amazon SimpleDB: Ideal for Social and Mobile Applications?

  1. Hi.
    I enjoyed your intro to using simple db on android. I was wondering if you could write an entry or give more details about how you achieve this on android, setting it up, making the calls, handling the results etc. The reason I say this is I’m trying to use it myself and am finding those things hard. I am sure there will be others that would find it useful too.


  2. Clive thanks for the comment. I developed my own library for accessing SimpleDB with the intention of extending it and releasing it. I have not had the time to do that yet. But Alan Williamson has released a very simple free SimpleDB class. I have not tried it, but I believe this will work on Android.


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