The NoSQL movement continues to gain momentum. I don’t see these systems as replacing relational systems for all applications but it is also crystal clear that relational systems are a poor choice for some workloads. See One Size Does Not Fit All for my take on the different types of systems that make up the structured storage market.
The Amazon Web Services entrant in the NoSQL market segment is SimpleDB. I’ve posted on SimpleDB in the past starting back in 2007 Amazon SimpleDB Announced and more recently in I Love Eventual Consistency but… I recently came across a book by Prabhakar Chaganti and Rich Helms on SimpleDB.
Wait a second, I know that name. Rich and I worked together more than 20 years ago at the IBM Toronto Software Lab where he was Chief Image Technology Architect and I was lead architect on DB2. It’s been a long time.
The book, Amazon SimpleDB Developers Guide is a detailed guide for developers with examples in PHP, Java, and Python. Very recent features like BatchPutAttributes() are covered. Towards the end of the book, the authors show an application of Memcached with SimpleDB. The table of contents:
Preface
Chapter 1: Getting to Know SimpleDB
Chapter 2: Getting Started with SimpleDB
Chapter 3: SimpleDB versus RDBMS
Chapter 4: The SimpleDB Data Model
Chapter 5: Data Types
Chapter 6: Querying
Chapter 7: Storing Data on S3
Chapter 8: Tuning and Usage Costs
Chapter 9: Caching
Chapter 10: Parallel Processing
Index
SimpleDB really does have a developer guide from the Amazon Web Services SimpleDB team but more examples and more data is always good. If you interested in SimpleDB, check out: Amazon SimpleDB Developers Guide.
–jrh
b: http://blog.mvdirona.com / http://perspectives.mvdirona.com
For low latency locks, a Paxos based locking service is the right answer. For very high frequency, low latency locks, using a paxos to elect a lock server and then routing all lock requests through that single server is the right answer. On server failure, elect another.
For even higher frequency, low latency locks, shard the lock space and elect a leader for each.
for low latency locks, the conditional put solution in SimpleDB (or similar service) seems easy and functional.
–jrh
jrh@mvdirona.com
Hey, James, while you’re talking about SimpleDB, let me ask you something. It surprises me that neither Amazon SimpleDB nor Google App Engine datastore can increment a counter in a single, quick call with a very brief lock (like "update t set c = c + 1" in SQL). The workarounds I see in the forums are inefficient and kind of sad (spinning on a conditional put in SimpleDB, using two slow roundtrip calls bundled in a transaction in App Engine and compensating for the slowness by sharding counters).
I realize that the lock required for an increment might make the SimpleDB designers want to discourage it (despite it being a relatively common use case), but is the conditional put (or Google’s sharding counters) the right solution? I’m not sure that it is. What are your thoughts?