introduction to azure documentdb
TRANSCRIPT
Introduction to DocumentDBBy Ike Ellis
Agenda
• Introduction
• Configuration
• Finding and Saving a Document• Two APIs
• Advanced Querying
• Stored Procedures, Triggers, Functions
Introduction
• Loose Outline• JSON Document
• Collections
• Different APIs• Python
• REST
• SQL
• .NET/LINQ
• Not available in all regions• Central US, West US, North Europe, West Europe
JSON Document• Standard for passing data between a server and a web application
• Replacement for XML
• Hierarchical
• Terse
• Simple data types
DocumentDB in the landscape
Database
Account
A database account is associated with one or more capacity units representing
provisioned document storage and throughput, a set of databases and blob storage.
You can create one or more database accounts using your Azure subscription. Each
database account has a unique DNS name.
Database A database is a logical container of document storage partitioned across collections.
Collection A collection is a container of JSON documents and associated JavaScript application
logic. Queries and transactions are scoped to collections.
DocumentDB Limits
• Max Document Size – 512K
• DocumentDB Account – 100 databases per account * 10GB each = 1TB
Configuration
• Configured with the new portal (try preview)
• Switch Location to Western US (or wherever)
Once Created
• Get your DocumentDB URI and Key• Needed in code to begin saving documents
Testing Connectivity
Demo
Modeling Data - RDBMS
SELECT p.FirstName, p.LastName, a.City, cd.DetailFROM Person p JOIN ContactDetail cd ON cd.PersonId = p.IdJOIN ContactDetailType on cdtON cdt.Id = cd.TypeIdJOIN Address a ON a.PersonId = p.Id
Modeling in DocumentDB{
"id": "1",
"firstName": "Thomas",
"lastName": "Andersen",
"addresses": [
{
"line1": "100 Some Street",
"line2": "Unit 1",
"city": "Seattle",
"state": "WA",
"zip": 98012
}
],
"contactDetails": [
{"email: "[email protected]"},
{"phone": "+1 555 555-5555", "extension": 5555}
]
}
Reading is one operation
Writing is one operation
No assembly de-assembly
When to embed
• There are contains relationships between entities.
• There are one-to-few relationships between entities.
• There is embedded data that changes infrequently.
• There is embedded data won't grow without bound.
• There is embedded data that is integral to data in a document.
Examples of when not to embed
• Like a blog post comments or customer orders for the enterprise
Common Error
Local clock is not synced to Azure
Pricing
ConsistencyConsistency Level Description TradeOff
Strong a write is only visible after it is committed durably by the majority quorum of replicas
Absolute guarantees on data consistency, but offers the lowest level of read and write performance.
Bounded staleness a write is only visible after it is committed durably by the majority quorum of replicas
more predictable behavior for read consistency while offering the lowest latency writes
Session ability to read your own writes. . A read request for session consistency is issued against a replica that can serve the client requested version (part of the session cookie).
predictable read data consistency for a session while offering the lowest latency writes. Reads are also low latency as except in the rare cases, the read will be served by a single replica.
Eventual Eventual consistency is the weakest form of consistency wherein a client may get the values which are older than the ones it had seen before
the weakest read consistency but offers the lowest latency for both reads and writes
Indexing
• Everything is indexed by default
• Opt-in or out at collection creation
• Range – Good for numbers that need where filters with >=, >, <, <=
• Hash – Good for strings
Ike Ellis
• Crafting Bytes• Small Software Studio• Modern web, mobile, Azure, SQL Server• Looking for future teammates!
• Book: Developing Azure Solutions
• www.craftingbytes.com
• blog.ikeellis.com
• www.ikeellis.com
• Ike Ellis, MVP
• @ike_ellis
• 619.922.9801