Amazon announced SDB late last week. I have been using it under NDA for a bit and have written a Ruby API for it. I have opened up a
RubyForge project to deposit the code and will be doing so in the upcoming days.
There has been a lot of chatter on the internets about SDB over the last few days. Some of it correct. Some of it not. Some say it
"takes on the relational database" while others say it
"removes the database scaling wall" or it
"lets you run some calculations on your data." TechCrunch, of all places, says it "
takes on Oracle and IBM" (/me chuckles). .......Plll-e-e-ease, people. You are missing it.
SDB is NOT a real-time or transaction db (that's got to be 95% of the DBs out there). SDB doesn't have transactions and has "eventual consistency". This means if you query for a record that was updated, it may or may not give you back the updated version you just stored.
Eventually, they promise to give back the updated version - they
promise. SDB, today, would be a really poor choice for data store where a user interacts with a UI. ( IE: "What do you mean my order can't be found?! I just paid you on the last screen with my credit card!" ) SDB doesn't do joins (across domains) or ANSI SQL.
SDB is still a very, very useful tool to put in your belt for your EC2 cluster. Here's the real-deal. Amazon is giving their users Google's 'BigTable' for their EC2 cluster. This is a massive read-mostly hash database, a tuplespace, a directory, warehousing, reporting, search indices or metadata system that can be layered on S3. It fits well where the data is write-once-in-while but read-mostly.
If you really want an eye-opener on what Amazon intends this for then read up on Google's
MapReduce and
BigTable. Then go back and read the docs for EC2 / SDB and your brain will :click => :bingo
