DocumentDb a NoSQL document database-as-a-service

Microsoft Azure DocumentDB is a highly-scalable NoSQL document database-as-a-service that offers rich querying over schema-free data, helps deliver configurable and reliable performance, and enables rapid development, all through a managed platform backed by the power and reach of Microsoft Azure. DocumentDB is the right solution for web and mobile applications when predictable throughput, low latency, and a schema-free data model are key requirements. DocumentDB delivers schema flexibility and rich indexing via a native JSON data model, and includes multi-document transactional support with integrated JavaScript. In other words, DocumentDB is the right solution for web and mobile applications when predictable throughput, low latency, and a schema-free data model are key requirements.

DocumentDB === Database ???
DocumentDB is a NoSQL document oriented database that stores data in JSON format. DocumentDB supports nested, self-contained-data structures that can be queried through a rich DocumentDB SQL query grammar. DocumentDB provides high performance transactional processing of server side JavaScript through stored procedures, triggers, and user defined functions. The database also supports developer tunable consistency levels with associated performance levels.

What about tables in DocumentDB like an RDBMS?
No, DocumentDB stores data in collections of JSON documents. DocumentDB allows applications to store arbitrary JSON documents without schema definition or hints. Data is immediately available for query through the DocumentDB SQL query interface.

What Data types to choose?
The primitive data types supported in DocumentDB are the same as JSON. JSON has a simple type system that consists of Strings, Numbers (IEEE754 double precision), and Booleans - true and false and Nulls. More complex data types like DateTime, Guid, Int64, and Geometry can be represented both in JSON and DocumentDB through the creation of nested objects using the { } operator and arrays using the [ ] operator.

Transactions in DocumentDB?
DocumentDB supports language-integrated transactions via JavaScript stored procedures and triggers. All database operations inside scripts are executed under snapshot isolation scoped to the collection. A snapshot of the document versions (ETags) is taken at the start of the transaction and committed only if the script succeeds. If the JavaScript throws an error, the transaction is rolled back. DocumentDB also supports stored procedures, which provide an efficient means to batch inserts. By developing a simple JavaScript stored procedure that accepts and inserts documents, you can perform bulk inserts. This has the added benefit that the bulk insert will be performed as a transaction, leaving the collection in a consistent state. DocumentDB supports cross-document transactions expressed as JavaScript stored procedures and triggers. Transactions are scoped to a single collection and executed with ACID semantics as all or nothing isolated from other concurrently executing code and user requests. If exceptions are thrown through the server side execution of JavaScript application code, the entire transaction is rolled back.

When to use DocumentDB?
DocumentDB is a good choice for new web and mobile applications where scale, performance, and the ability to query over schema-free data is important. DocumentDB lends itself to rapid development and supporting the continuous iteration of application data models. Applications that manage user generated content and data are common use cases for DocumentDB.

DocumentDB sounds promising but it is missing some key pieces like:
  • Point in time backup & restore option - who will trust building any application of value on DocumentDB if you can't "easily" & "reliably" go back in time & restore a snapshot. Think of application logic corrupting data, inadvertent deletion of records/database or malicious user deleting/corrupting the data. You are out of luck without a point in time backup/restore.
  • A developer has to pay even if they just want to try it out because there is no development emulator. That's a strong "barrier to entry". There are many other "Free" options to try instead.
  • DocumentDB does not offer a separate service emulator, an emulator is always useful for unit testing.


Comments are closed