WEBVTT
00:00:00.000 --> 00:00:03.440
>> All right. Hi everyone, thanks for coming.
00:00:03.680 --> 00:00:05.880
My name is Aleksey Sevateyev,
00:00:05.880 --> 00:00:08.360
I'm a senior program manager for Azure Cosmos DB.
00:00:08.360 --> 00:00:10.745
And today, I'm going to tell you all about it.
00:00:10.745 --> 00:00:13.915
I'm going to give you an overview of
00:00:13.915 --> 00:00:17.850
various capabilities that the prodcut supports.
00:00:17.850 --> 00:00:21.945
Now what is Azure Cosmos DB?
00:00:21.945 --> 00:00:23.610
We position it as
00:00:23.610 --> 00:00:26.950
a globally distributed multi-model database
00:00:26.950 --> 00:00:30.725
of the service by Microsoft.
00:00:30.725 --> 00:00:33.800
We support multiple APIs,
00:00:33.800 --> 00:00:36.830
that is multiple ways to write and read your data.
00:00:36.830 --> 00:00:38.635
We support multiple models,
00:00:38.635 --> 00:00:42.144
and we operate on top of Azure infrastructure.
00:00:42.144 --> 00:00:44.370
We are ring zero Azure service.
00:00:44.370 --> 00:00:45.900
That means, that we are in
00:00:45.900 --> 00:00:49.665
every single Azure region, 42 currently.
00:00:49.665 --> 00:00:52.380
That's more than Amazon and Google combined.
00:00:52.380 --> 00:00:54.625
Whenever the new region gets added,
00:00:54.625 --> 00:00:57.825
Cosmos DB will be there by default.
00:00:57.825 --> 00:01:02.380
So, underneath the covers,
00:01:02.380 --> 00:01:04.935
on top of this Azure infrastructure,
00:01:04.935 --> 00:01:06.885
what we've built is called,
00:01:06.885 --> 00:01:09.765
ARS, Atom Record Sequence Schema.
00:01:09.765 --> 00:01:12.860
This schema essentially holds all the data.
00:01:12.860 --> 00:01:15.250
And that data is represented in
00:01:15.250 --> 00:01:17.965
multiple data models that we currently support,
00:01:17.965 --> 00:01:20.925
which is key-value pair,column-family,
00:01:20.925 --> 00:01:22.450
document and graph.
00:01:22.450 --> 00:01:24.600
And this models are covered currently
00:01:24.600 --> 00:01:28.335
by five APIs that you see here on this screen.
00:01:28.335 --> 00:01:33.210
Table API essentially covers key-value pair data model.
00:01:33.210 --> 00:01:35.220
It used to be called Azure Table Storage.
00:01:35.220 --> 00:01:39.000
Now it's folded into Azure Cosmos DB family,
00:01:39.000 --> 00:01:42.480
and Casandra API that covers
00:01:42.480 --> 00:01:44.970
column-family data model and
00:01:44.970 --> 00:01:48.140
SQL API and Mongo DB API covered document data model.
00:01:48.140 --> 00:01:50.065
They store the data in
00:01:50.065 --> 00:01:54.660
JSON documents and Gremlin covers the graph data model.
00:01:54.660 --> 00:01:56.410
Why this is important,
00:01:56.410 --> 00:01:59.290
is because those APIs
00:01:59.290 --> 00:02:01.690
are ultimately going to be interoperable.
00:02:01.690 --> 00:02:04.400
You will be able to write the data with one
00:02:04.400 --> 00:02:06.960
of them and read the data with any other.
00:02:06.960 --> 00:02:11.035
Currently, SQL API and Gremlin API and interoperable.
00:02:11.035 --> 00:02:13.700
So, you can write the data with SQL and
00:02:13.700 --> 00:02:16.610
read it with Gremlin in the form of a graph.
00:02:16.610 --> 00:02:19.260
Visualize it for your users.
00:02:19.260 --> 00:02:23.420
Now, what we provide
00:02:23.420 --> 00:02:26.650
underneath using all this infrastructure,
00:02:26.650 --> 00:02:27.980
all the resources that we've built
00:02:27.980 --> 00:02:30.660
is Turnkey Global Distribution.
00:02:30.660 --> 00:02:33.310
You can come to Azure portal,
00:02:33.310 --> 00:02:36.475
deploy your data and within a click of a button,
00:02:36.475 --> 00:02:39.520
distributed across the globe.
00:02:39.520 --> 00:02:43.850
To all 42 regions If you want or just to one or two,
00:02:43.850 --> 00:02:46.240
depending on how many regions you
00:02:46.240 --> 00:02:48.905
need to color for your users.
00:02:48.905 --> 00:02:50.940
Why this is important is because
00:02:50.940 --> 00:02:52.990
users can be anywhere and that in
00:02:52.990 --> 00:02:55.040
order for them to get the lowest latency
00:02:55.040 --> 00:02:56.660
and the highest throughput,
00:02:56.660 --> 00:02:58.455
you need to deploy the data
00:02:58.455 --> 00:03:02.200
near wherever your users are, right?
00:03:02.200 --> 00:03:05.685
And all those DB providers got capability.
00:03:05.685 --> 00:03:07.895
Essentially, all of your data
00:03:07.895 --> 00:03:10.180
can be made globally distributed or
00:03:10.180 --> 00:03:15.220
it can be simply hosted in one particular region.
00:03:16.650 --> 00:03:20.425
We provide elastic scale out of
00:03:20.425 --> 00:03:23.130
throughput and storage independently.
00:03:23.130 --> 00:03:23.970
And this is important.
00:03:23.970 --> 00:03:25.455
Because sometimes, you need
00:03:25.455 --> 00:03:27.240
a lot of throughput for example for
00:03:27.240 --> 00:03:29.650
notification applications that modify
00:03:29.650 --> 00:03:31.545
a lot of users at once.
00:03:31.545 --> 00:03:34.500
But they don't need to have a lot of storage.
00:03:34.500 --> 00:03:36.155
So, you can have that here.
00:03:36.155 --> 00:03:37.860
Or you can have an application
00:03:37.860 --> 00:03:40.020
that requires to store a lot of data like
00:03:40.020 --> 00:03:42.090
archival applications or
00:03:42.090 --> 00:03:44.555
document management applications but they barely
00:03:44.555 --> 00:03:47.080
have any users and
00:03:47.080 --> 00:03:49.870
you don't want to pay for a lot of throughput therefore.
00:03:49.870 --> 00:03:51.935
So, you can have that too here.
00:03:51.935 --> 00:03:55.320
Some of competition actually does not provide
00:03:55.320 --> 00:03:56.900
this capability because they simply deploy
00:03:56.900 --> 00:03:58.895
the data in the visual machines.
00:03:58.895 --> 00:04:00.700
And therefore, you are limited to
00:04:00.700 --> 00:04:02.990
the configuration of actual virtual machine.
00:04:02.990 --> 00:04:04.410
If you have some throughput, you
00:04:04.410 --> 00:04:05.440
will have some storage too.
00:04:05.440 --> 00:04:07.390
If you have some storage, you will have some throughput,
00:04:07.390 --> 00:04:08.695
and you pay for all of that.
00:04:08.695 --> 00:04:10.390
In Cosmos DB, those two things are
00:04:10.390 --> 00:04:13.220
completely independent of each other.
00:04:14.250 --> 00:04:17.550
We provide you guarantee low latency of
00:04:17.550 --> 00:04:19.000
less than 10 millisecond for
00:04:19.000 --> 00:04:21.625
a one kilobyte document read.
00:04:21.625 --> 00:04:25.390
And less than 15 milliseconds
00:04:25.390 --> 00:04:28.485
for one kilobyte document write.
00:04:28.485 --> 00:04:32.855
Therefore, if you increase the size of the documents,
00:04:32.855 --> 00:04:34.000
the latencies will grow.
00:04:34.000 --> 00:04:39.465
But this is the benchmark that we actually subscribe for,
00:04:39.465 --> 00:04:41.780
and we give you the SLA on
00:04:41.780 --> 00:04:46.990
this latencies out of any of the regions that we support.
00:04:46.990 --> 00:04:49.970
We also have other SLAs.
00:04:49.970 --> 00:04:53.185
For example, there's SLA on consistency.
00:04:53.185 --> 00:04:56.910
We provide you five well-defined consistency models.
00:04:56.910 --> 00:04:59.540
it's three more than Typical,
00:04:59.540 --> 00:05:01.714
Eventual, and Strong consistency.
00:05:01.714 --> 00:05:06.375
In fact, what we found is that users
00:05:06.375 --> 00:05:08.540
typically choose Session consistency
00:05:08.540 --> 00:05:10.950
because it's the easiest one to use.
00:05:10.950 --> 00:05:13.555
Session consistency is similar to strong but
00:05:13.555 --> 00:05:17.195
within the confines of a Single session.
00:05:17.195 --> 00:05:19.320
If you have a data access layer
00:05:19.320 --> 00:05:20.720
that connects to the database,
00:05:20.720 --> 00:05:21.760
it will be a single Session.
00:05:21.760 --> 00:05:23.000
If you have a device that connects
00:05:23.000 --> 00:05:25.090
with Cosmos DB it will be a single Session.
00:05:25.090 --> 00:05:27.205
So, it actually makes sense to provide
00:05:27.205 --> 00:05:29.830
Session consistency in most cases and not Strong,
00:05:29.830 --> 00:05:32.480
because Strong is super expensive.
00:05:32.480 --> 00:05:34.060
It needs to replicate the data
00:05:34.060 --> 00:05:37.985
before the data becomes available for reads.
00:05:37.985 --> 00:05:40.620
The other two that we support are Bounded-stateless.
00:05:40.620 --> 00:05:44.635
It's something in between Strong and Session.
00:05:44.635 --> 00:05:47.860
Essentially it gives you a strong consistency but within
00:05:47.860 --> 00:05:49.890
a certain period of time or
00:05:49.890 --> 00:05:52.680
a certain number of updates of the data.
00:05:52.680 --> 00:05:56.470
So, certain interval of time defined by you or
00:05:56.470 --> 00:05:58.660
a certain number of updates or prefixes as
00:05:58.660 --> 00:06:01.435
we call them defined by you on the portal.
00:06:01.435 --> 00:06:04.750
Also, we support Consistent prefix consistency model
00:06:04.750 --> 00:06:07.365
which is essentially similar to Eventual,
00:06:07.365 --> 00:06:09.880
but at least it gives you the ability
00:06:09.880 --> 00:06:13.365
to write and read the data in predefined order.
00:06:13.365 --> 00:06:15.575
Your reads will never be
00:06:15.575 --> 00:06:18.565
out of order compared to your writes.
00:06:18.565 --> 00:06:21.720
With Eventual, anything goes and you
00:06:21.720 --> 00:06:23.685
can read the data in any particular order
00:06:23.685 --> 00:06:25.900
whenever it becomes available.
00:06:26.870 --> 00:06:29.745
Now, we also provide
00:06:29.745 --> 00:06:32.065
SLAs in addition to the ones that I have mentioned
00:06:32.065 --> 00:06:34.315
on high-availability which is
00:06:34.315 --> 00:06:37.120
four-nines of availability out
00:06:37.120 --> 00:06:39.060
of a single region five-nines
00:06:39.060 --> 00:06:42.175
if you actually increase the number of regions
00:06:42.175 --> 00:06:44.410
with the second region were you're able
00:06:44.410 --> 00:06:46.300
to provide five-nines of availability.
00:06:46.300 --> 00:06:49.210
That's literally just a few minutes of downtime
00:06:49.210 --> 00:06:52.915
within a year that we allow the service to be down.
00:06:52.915 --> 00:06:56.150
If it goes above that,
00:06:56.150 --> 00:06:58.235
then you can simply demand your money back.
00:06:58.235 --> 00:07:00.220
And we actually do return the money
00:07:00.220 --> 00:07:02.675
back in case any of these SLAs are broken.
00:07:02.675 --> 00:07:07.940
And also, there's also an SLA on throughput.
00:07:07.940 --> 00:07:09.795
Throughput is something that you pay for.
00:07:09.795 --> 00:07:11.740
Therefore, we do provide you SLA
00:07:11.740 --> 00:07:14.890
that within the provision throughput that you have,
00:07:14.890 --> 00:07:16.450
you will definitely have it every single
00:07:16.450 --> 00:07:18.920
second when your service operates.
00:07:18.920 --> 00:07:21.430
And if it goes below that,
00:07:21.430 --> 00:07:23.165
and you see that you are being throttled.
00:07:23.165 --> 00:07:27.660
Again, you can demand the money back on that.
00:07:28.700 --> 00:07:31.320
Now, we handle any kind of data.
00:07:31.320 --> 00:07:33.745
This is no SQL data, database, right?
00:07:33.745 --> 00:07:36.705
It's not relational even though we have SQL API,
00:07:36.705 --> 00:07:40.730
we allow you to specify your documents or
00:07:40.730 --> 00:07:42.690
the format of the documents when you write
00:07:42.690 --> 00:07:45.145
them in whatever shape and form.
00:07:45.145 --> 00:07:47.805
You can mix and match them in your collections.
00:07:47.805 --> 00:07:51.480
You can infer the schema on the read if you like,
00:07:51.480 --> 00:07:54.300
but we don't mandate any particular schema.
00:07:54.300 --> 00:07:57.670
Therefore, it's super fast to ingest the data.
00:07:57.670 --> 00:07:59.000
You can mix and match them
00:07:59.000 --> 00:08:01.415
in a small number of collections,
00:08:01.415 --> 00:08:03.430
and you can read them as you please.
00:08:03.430 --> 00:08:06.500
And you can infer the data on the read.
00:08:08.510 --> 00:08:13.575
Now, we also provide very comprehensive security.
00:08:13.575 --> 00:08:17.475
We encrypt the data at rest and in flight.
00:08:17.475 --> 00:08:20.740
In flight, it's encrypted with TLS 1.2.
00:08:20.740 --> 00:08:23.515
At Rest, It's encrypted with
00:08:23.515 --> 00:08:27.125
the key that we generate upon creation of your account.
00:08:27.125 --> 00:08:30.185
And will soon be able to provide you
00:08:30.185 --> 00:08:32.850
the bring your own key capabilities as well,
00:08:32.850 --> 00:08:35.680
if you want to encrypt it with your own key.
00:08:36.380 --> 00:08:40.945
We also provide a number of certifications,
00:08:40.945 --> 00:08:45.755
where PCI keeper compliance [inaudible] Type one and Type two,
00:08:45.755 --> 00:08:48.095
European Union Model closes.
00:08:48.095 --> 00:08:51.535
It's pretty large and comprehensive set
00:08:51.535 --> 00:08:54.600
of compliance certifications that we have.
00:08:56.140 --> 00:08:58.510
Now, let me give you one example.
00:08:58.510 --> 00:09:00.630
This is an example of the architecture
00:09:00.630 --> 00:09:02.790
that Next Games and
00:09:02.790 --> 00:09:07.860
Finnish gaming company uses for the game called,
00:09:07.860 --> 00:09:10.575
"Walking Dead, no man's land",
00:09:10.575 --> 00:09:14.370
and Cosmo DB here is used as
00:09:14.370 --> 00:09:17.320
a single database for a bunch
00:09:17.320 --> 00:09:21.135
of application servers that they run.
00:09:21.135 --> 00:09:23.150
Web servers essentially, that
00:09:23.150 --> 00:09:24.960
they run in different regions.
00:09:24.960 --> 00:09:27.685
It automatically load balances itself.
00:09:27.685 --> 00:09:29.870
You only have to deploy it once.
00:09:29.870 --> 00:09:31.820
If you want to increase the number of regions,
00:09:31.820 --> 00:09:35.270
you can do that, but you don't have to.
00:09:35.270 --> 00:09:39.860
Essentially, your clients that
00:09:39.860 --> 00:09:41.680
read the data from Cosmos DB will
00:09:41.680 --> 00:09:44.490
determine what is the nearest location
00:09:44.490 --> 00:09:48.570
for the regions where your data resides, right?
00:09:48.570 --> 00:09:50.420
And Azure Traffic Manager here is
00:09:50.420 --> 00:09:52.460
only shown because there needs to
00:09:52.460 --> 00:09:53.700
be some sort of
00:09:53.700 --> 00:09:55.010
traffic management happening
00:09:55.010 --> 00:09:56.480
before the application service.
00:09:56.480 --> 00:09:59.640
Application servers do not have to be separated from
00:09:59.640 --> 00:10:01.210
the database by some sort of
00:10:01.210 --> 00:10:03.155
a load balancer or traffic manager,
00:10:03.155 --> 00:10:05.820
Cosmos DB takes care of that.
00:10:06.550 --> 00:10:10.275
Another pattern that Next Game uses is
00:10:10.275 --> 00:10:14.710
the ability to store the data that is super important.
00:10:14.710 --> 00:10:18.540
The user data, the main game
00:10:18.540 --> 00:10:23.560
data set in Cosmos DB while other things like textures,
00:10:23.560 --> 00:10:29.685
videos, images are stored in a very cheap blob storage.
00:10:29.685 --> 00:10:33.085
And that can be stored through Azure CDN.
00:10:33.085 --> 00:10:35.450
Cosmos DB doesn't need its own CDN.
00:10:35.450 --> 00:10:38.890
It's actually a CDN of its own for the data, right?
00:10:38.890 --> 00:10:42.410
And then you can use the integration
00:10:42.410 --> 00:10:44.215
with HDinsight which is
00:10:44.215 --> 00:10:46.480
Microsoft's implementation of Hadoop.
00:10:46.480 --> 00:10:47.940
It's a Hortonwork's distribution
00:10:47.940 --> 00:10:49.855
that Microsoft adopted for Azure.
00:10:49.855 --> 00:10:52.420
And you can also use Azure functions to
00:10:52.420 --> 00:10:55.470
create your own sever-less applications
00:10:55.470 --> 00:10:56.590
based on your database.
00:10:56.590 --> 00:10:58.440
So, whenever something changes in the database,
00:10:58.440 --> 00:11:01.115
it can trigger Azure function
00:11:01.115 --> 00:11:03.305
in which you can describe your applications logic.
00:11:03.305 --> 00:11:05.800
So, you don't have to deploy additional VMs.
00:11:05.800 --> 00:11:09.240
We have the integration for Azure functions available.
00:11:09.240 --> 00:11:13.110
We also have integration with Spark available as well,
00:11:13.110 --> 00:11:14.280
if you want to distribute
00:11:14.280 --> 00:11:16.940
your application of logic through
00:11:16.940 --> 00:11:21.575
Spark worker nodes that can reside next to Cosmos DB.
00:11:21.575 --> 00:11:23.435
So in this particular example,
00:11:23.435 --> 00:11:25.260
they use Azure functions to call
00:11:25.260 --> 00:11:26.940
the Azure notification hub to
00:11:26.940 --> 00:11:30.265
notify the users that something happened in the game.
00:11:30.265 --> 00:11:33.260
One of their friends signed up or they got signed
00:11:33.260 --> 00:11:36.285
off or something happened with the game itself.
00:11:36.285 --> 00:11:37.560
For example, certain event
00:11:37.560 --> 00:11:39.570
happened within the game and they get
00:11:39.570 --> 00:11:43.800
notified if they don't necessarily watch the game screen.
00:11:43.800 --> 00:11:46.250
So, Azure Notification Hub provides
00:11:46.250 --> 00:11:49.105
you integration with IOS and Android
00:11:49.105 --> 00:11:55.270
push mechanisms That is all I have.
00:11:55.270 --> 00:12:00.815
Any questions? No? All good?
00:12:00.815 --> 00:12:03.580
Thanks for coming. Thank you very much.