Amazon DynamoDB: First Impressions

An e-mail arrived this morning from Amazon Web Services (Aws):

It was a new feature announcement from Aws.

The new product is DynamoDB... a new NoSQL database engine for Amazon Web Services (Aws)

From the e-mail, it's described as "Amazon DynamoDB, a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability".

It has some interesting key points:

• Data on Solid State Drives (SSDs)
• Replicated data synchronously across multiple zones.
• Supports two types of primary keys: Hash Type and Hash and Range Type 
• JSON for data transport

This new product is a NoSQL database engine built into their cloud infrastructure (similar to SimpleDB as a product, but with some notable changes and upgrades).

From CTO Werner Vogels' DynamoDB blog post he states the differences between SimpleDB and DynamoDB: "While SimpleDB has been successful and powers the applications of many customers, it has some limitations that customers have consistently asked us to address." Listing: Domain scaling limitations, Predictability of Performance, and SimpleDB's Pricing complexity.


From the documentation, it appears to be similar to their existing  SimpleDB offering, but is designed for large scale needs (and predictable) performance. Most notably no limits or restrictions on database size, and automatic management of scalability across multiple servers.


What is NoSQL? 
According to Wikipedia's  NoSQL article:

In computing, NoSQL (sometimes expanded to "not only SQL") is a broad class of database management systems that differ from the classic model of the relational database management system (RDBMS) in some significant ways, most important being they do not use SQL as their query language.

DynamoDB Storage Model (1000 ft view)
From their documentation, each object (or item) is stored within a table, with the individual values within the item stored as attributes:

From Amazon DynamoDB (beta)

Getting Started
In order to get started with DynamoDB, you have to make sure you have a couple of things:

• Amazon Web Services developer account
• Your AWS account has to be set up to use Amazon DynamoDB
• Your AWS Access and Secret Key (in order to run the examples, or start your development project)

DynamoDB and .NET
The AWS SDK for .NET has been updated to contain samples for using DynamoDB with the .NET framework (fair warning if you have a previous version of the SDK you may have to remove it to install this one).

The SDK contains (basically) 4 samples:

• Data Model Sample - creation of a context, persistence of items using the context, and some queries against the context.
• Data Model Schema - Samples of objects that can be stored within DynamoDB. Specific would be the use attributes: DynamoDBTable that "Specifies that this object can be stored in DynamoDB". DynamoDBHashKey, DynamoDBProperty, and DynamoDBRangeKey to name a few.
• Document Model Sample - Demonstrates the document model. Shows creation of a table, and adding documents to a table, persistence, and querying from the model.
• Table Operations - Basic table operations: Contains, CreateTable, table status, table deletes.

These samples are available for VS 2008 and VS 2010. With my installation, the samples were located at C:\Program Files (x86)\AWS SDK for .NET\Samples\AmazonDynamoDB_Sample.

Pricing (as of 1/19/2012)
Notes About Amazon DynamoDB states it pretty well "pricing is based on actual write/read operations and not API calls (e.g. a query returning 100 results accounts for 100 ops and not 1 op)".

You pay a flat, hourly rate based on the capacity you reserve:

Throughput Capacity

Write Throughput: $0.01 per hour for every 10 units of Write Capacity

Read Throughput: $0.01 per hour for every 50 units of Read Capacity

The listed pricing (as of 1/19/2012) offers a free-pricing tier as well:

Free Tier*

As part of AWS’s Free Usage Tier, AWS customers can get started with Amazon DynamoDB for free. DynamoDB customers get 100 MB of free storage, as well 5 writes/second and 10 reads/second of ongoing throughput capacity.

Final Thoughts:
... What's missing: From CTO Werner Vogels' DynamoDB blog post one comment from Faraz points out one of the key components missing from DynamoDB's initial offering: "missing critical database pillar of snapshot backup and fast recovery system". Vogel's response: "we have a philosophy of launching with a minimal feature set and then quickly iterating while prioritizing based on customer feedback. Backup/Restore for DynamoDB will have high priority". While true, I'm still waiting for micro in VPC!

... "pure local emulation is not available".  However, there is an open-source project to provide this emulation for SimpleDB: fakesdb (a fake version of Amazon's SimpleDB for local/integration testing).

... JSON is used for sending data and for responses, but it is not used as the native storage schema (from
Notes About Amazon DynamoDB).

... DynamoDB vs. Cassandra

Resources:
Amazon Web Services
Amazon DynamoDB
NoSQL
What is Amazon DynamoDB?
AWS SDK for .NET
SimpleDB
micro in VPC
Notes About Amazon DynamoDB
DynamoDB vs. Cassandra

Snippet Editor

I found this little snippet editor on CodePlex.

http://snippeteditor.codeplex.com/

This comes in handy if you're working a ton with snippets, or if you have any complex snippets out there that you need to edit.

It's handy, and simple to use.

Csla 3.5.1 on DnrTV

Rocky Lhotka has just posted on his blog about the release of the dnrTV (Dot Net Rocks TV) episodes on CSLA .NET 3.5.1

You can read his blog post about it here:
http://www.lhotka.net/weblog/CSLANETOnDNRTV.aspx

You can view the show (it's in two parts), by clicking on these links:
Rocky Lhotka on CSLA .NET 3.5 Part 1
Rocky Lhotka on CSLA .NET 3.5 Part 2

This is the link to the Csla home page: http://www.lhotka.net/cslanet/Default.aspx

Reflection performance and Delegate.CreateDelegate

For those out there that work on Enterprise level .NET applications, using reflection is a necessity.

While avoiding (inappropriate) use of reflection is always a goal for an enterprise developer, making the right decisions when it's use is required is paramount.

While reading up on the Csla forum, I ran across a post that referenced this blog article on "Making reflection fly and exploring delegates".

It makes a great suggestion and something to consider as an alternate to using MethodInfo, so I thought I would pass it along.

http://msmvps.com/blogs/jon_skeet/archive/2008/08/09/making-reflection-fly-and-exploring-delegates.aspx

Generic and Concrete: Is this grease and water?

When developing software: can the application architecture be generic, and at the same time contain concrete business logic? Would this design be analogous to grease and water?

Designing a flexible enterprise application requires both, so the answer should obviously be no: generic architecture and concrete business logic are not like grease and water., but somehow these concepts often get treated like they are.

Based upon that idea, here are some guidelines for making sure the application architecture is generic while still containing the concrete business logic successful applications require:

Use a application framework

Using a framework for your application pretty much always makes sense. Unless your developing a basic button to database application you will want to seperate the logical layers of the application, while providing a basic set of conceptual building blocks.

These conceptual building blocks are the generic portion of your application. They create the foundation on which to build your concrete business layer.

Build state into your framework

So many times people make a really common mistake in their pursuit of a business application's library.

They forget that the business layer needs to know the state of the object: Does the object represent a new set of data? Is this data already in the database, and needs to be updated? Does this object persist data at all?

All important questions, right? No one would ever make this mistake.

Has anyone seen this type of logic in a SQL proc before?
IF EXISTS (SELECT * FROM dbo.Person WHERE PersonID = @PersonID)
UPDATE dbo.Person
SET [First] = @First
,Middle = @Middle
,[Last] = @Last
WHERE PersonID = @PersonID
ELSE
INSERT INTO dbo.Person([First],Middle,[Last]) VALUES(@First, @Middle, @Last

Here, the developer moved the decision of the state of the data (and therefore the object that was the source of the data) to the stored procedure.

Why is state important to your business framework? And how does this keep my application architecture generic?

Future topics on the same subject:

Build business validation into your framework

Build security into your framework

Remember: Not all specific specific concepts can be generic entities

Make sure the framework follows the OOP paradigm