[MUSIC]
Hi, my name is Kirill Gavrylyuk and today I want to talk about love.
Love between our planet scale, NoSQL database as a service,
DocumentDB and mobile developers.
And today we're using Xamarin.
As with all enduring relationships,
our love is based on few tangible traits.
Our DocumentDB is a NoSQL database.
You can store any data in it.
You don't have to define the schema,
you don't need to worry about indexes.
You get rich queries, fast queries, and you can use variety of APIs.
You can use SQL Stamina, SQL Index for queries.
You can use Java Script.
You can use Mongol APIs which will support at the product level.
Azure DocumentDB is a manage service,
so you do not need to worry about VMs and cores.
You just need to tell us what's do you want?
And we scale you and there are no limits to that.
It's a fast database, so your data will be served
in less than ten milliseconds in the same data center.
It's a global scale database.
Which means that you can take your data and
we'll replicate it across 38 or more regions across the world.
So that, any user anywhere on the planet of your app can get the data.
It's a same low latency.
And DocumentDB offer is a number of features that
are especially interesting for mobile developers.
For example, geo spatial queries built-in and supported.
As well as binding attachments.
Let's dive in into the demo.
It's easy to get started with DocumentDB.
In fact, you don't even need to sign up for Azure.
You can download our free emulator and
start working with the community on your local desktop.
You don't even have to be connected to the network.
But if you happen to have an Azure account,
you can create DocumentDB in Azure portal.
By finding us in the left navigation pane and clicking ADD.
And giving your first DocumentDB account, a name.
And telling where you want it to be located.
Now, I already created a DocumentDB account.
And if you create one, at the beginning,
we greet you with a quick start.
To make your day a little better we have a number of platforms that
you can work with DocumentDB from.
In our case, we're building a mobile app and we are using Xamarin.
Document DB stores data in collections.
And you can store any types of data,
any data structures in the same collection.
So lets create.
In our quick start we're gonna create an items collection.
And then, Download a ready to run
app that has already pre-configured to talk to your collection.
Once you download the app,
it's already connected to my app demo account.
And as many of the hello world apps that you seen as of late,
it is a to do list.
A modern day hello world, where I can go and add tasks.
And if I go back and look at my Document Explorer.
I can see that I need to get milks.
I need to get multiple types of milk.
That's great.
Now as it often happens with mobile apps
we want to ship out versions, many versions, one after another.
And sometimes we change data with which our app works with.
DocumentDB is in our SQL database.
So it doesn't require you to specify schema and
it makes it very easy to deal with multiple versions.
So let me do just that.
Let me sort my app and go and modify, and add more property.
I want to get organized and I want my To Do Items to have a priority.
Let's say, let's add a field priority.
Let's give it a type, int.
We want our app to work with the previous data, so
in the client we declare int nullable.
And we'll, because I want to be super organized,
I want my priority to be always one.
Just like I do in real life, everything is priority one. Great.
So let's launch our app again.
And let's give myself a new task.
Now let's take a look what happens at the back end.
Notice that we did not change anything in our back end.
So let's refresh.
And as you can see we have now our second item.
And our second item has the field priority, priority one.
While as the first one, did not have anything.
I did not have to touch the back end at all.
My app talks directly to the database and stores data structures.
Result getting about schema or indexes.
And I still enjoy good, rich queries.
And I can change, modify and can work with stan versions of my app,
all there working with the same DocumentDB collection.
Now with that, DocumentDB is a manage service.
So I can, when I add my collections,
I don't need to worry about cores or VMs.
I just need to tell DocumentDB that I want a collection with this
initial size of data.
And this will grow, can grow after once you provision your collection.
And this amount of throughput, let's add 250,000 request units.
And one request unit is sufficient to perform one read request
of 1K document.
And once you set this throughput,
every operation has consume certain amount of request units.
And it's constant through time, one lead request consumes one request
unit today, tomorrow, until the end of time.
This collection allows you to perform
quarter of million request units request per second.
That's a lot.
And just like that,
just clicking OK button I can provision that much capacity.
Well, here I have a collection that simulate an IoT scenario.
Where devices are sending us request at millions request per minute.
And at the same time look at the latency we are offering and
serving data with less than two milliseconds latency.
Regardless of rate, that's another important
characteristic of DocumentDB, low latency.
So DocumentDB gives you limitless throughput guarantees with.
And offers low latency and
at the same time you can offers the same low latency around the world.
Just by clicking on a Map, I can bring my collection in any of the 38
other regions that is ever increasing number around the world.
So that all my users,
no matter where they are, enjoys the same low latency.
Moreover, I can use the same functionality to offer high
availability for my collections.
So that, no matter what happens in a given region,
my data is always available at low latency to all of my users.
I can schedule failover policies, programmatically or
manually through this lead.
Right here I have an example of a collection that is distributed
across the world.
And look, whether it's Central US, or
whether it's Japan, I have the same low latency for each.
Here we are writing to a single region, so
we have low latency in Central US for Writes.
And slightly higher in Japan because we need to cross a continent.
There are configurations that enable to you multi-region writes
with DocumentDB.
I just summarized for
you several things that you can do with DocumentDB.
But let's do something specific to mobile.
Lets open another app.
Here I have another mobile app that gives me the list of
earthquakes in any geographical region.
In this case around Seattle.
So, just like that I can enter and specify any polygon.
And request earthquakes in this region.
And I can see that there are some earthquakes still happening
even in Seattle.
But look, on the program model side
this is all I need to do to query for these earthquakes.
We support natively use spatial queries in DocumentDB including our
link provider for .NET.
So, in your Xamarin application you can just write,
quake.location within polygon.
And these methods already provided to you.
You don't need to do.
Your quake and your polygon, they're just geospatial types.
You don't need to write any code for this just these two lines.
And you get geospatial queries efficient.
Get you anything within a very popular
mobile scenario within a given duration, within the given polygon,
get me some geospatial data.
You just saw in a nutshell DocumentDB and
how to use it with mobile apps.
Do try our samples.
Do take a look at our documentation.
And just look us up and start playing with it.
You don't need to sign up for Azure, use the Azure DocumentDB Emulator.
Or if you already have an Azure account check us out at
portal.azure.com.
[MUSIC]