Schlagwort: azure

How To Build Planet Scale Mobile App in Minutes with Xamarin and DocumentDB

Most mobile apps need to store data in the cloud, and #Azure DocumentDB is an awesome cloud database for mobile apps. It has everything a mobile developer needs, a fully managed NoSQL database as a service that scales on demand, and can bring your data where your users go around the globe — completely transparently to your application. Today we are excited to announce Azure DocumentDB SDK for Xamarin mobile platform, enabling mobile apps to interact directly with DocumentDB, without a middle-tier.

Here is what mobile developers get out of the box with DocumentDB:

Rich queries over schemaless data. DocumentDB stores data as schemaless JSON documents in heterogeneous collections, and offers rich and fast queries without the need to worry about schema or indexes.
Fast. Guaranteed. It takes only few milliseconds to read and write documents with DocumentDB. Developers can specify the throughput they need and DocumentDB will honor it with 99.99% SLA.
Limitless Scale. Your DocumentDB collections will grow as your app grows. You can start with small data size and 100s requests per second and grow to arbitrarily large, 10s and 100s of millions requests per second throughput, and petabytes of data.
Globally Distributed. Your mobile app users are on the go, often across the world. DocumentDB is a globally distributed database, and with just one click on a map it will bring the data wherever your users are.
Built-in rich authorization. With DocumentDB you can easy to implement popular patterns like per-user data, or multi-user shared data without custom complex authorization code.
Geo-spatial queries. Many mobile apps offer geo-contextual experiences today. With the first class support for geo-spatial types DocumentDB makes these experiences very easy to accomplish.
Binary attachments. Your app data often includes binary blobs. Native support for attachments makes it easier to use DocumentDB as one-stop shop for your app data.

Let's build an app together!

Step #1. Get Started

It&039;s easy to get started with DocumentDB, just go to Azure portal, create a new DocumentDB account,  go to the Quickstart tab, and download a Xamarin Forms todo list sample, already connected to your DocumentDB account. 

Or if you have an existing Xamarin app, you can just add this DocumentDB NuGet package. Today we support Xamarin.IOS, Xamarin.Android, as well as Xamarin Forms shared libraries.

Step #2. Work with data

Your data records are stored in DocumentDB as schemaless JSON documents in heterogeneous collections. You can store documents with different structures in the same collection.

In your Xamarin projects you can use language integtated queries over schemaless data:

Step #3. Add Users

Like many get started samples, the DocumentDB sample you downloaded above authenticates to the service using master key hardcoded in the app&039;s code. This is of course not a good idea for an app you intend to run anywhere except your local emulator. If an attacker gets a hold of the master key, all the data across your DocumentDB account is compromised.

Instead we want our app to only have access to the records for the logged in user. DocumentDB allows developers to grant application read or read/write access to all documents in a collection, a set of documents, or a specific document, depending on the needs.

Here is for example, how to modify our todo list app into a multi-user todolist app, a complete version of the sample is available here: 

Add Login to your app, using Facebook, Active Directory or any other provider.
Create a DocumentDB UserItems collection with /userId as a partition key. Specifying partition key for your collection allows DocumentDB to scale infinitely as the number of our app users growth, while offering fast queries.
Add DocumentDB Resource Token Broker, a simple Web API that authenticates the users and issues short lived tokens to the logged in users with access only to the documents within the user&039;s partition. In this example we host Resource Token Broker in App Service.
Modify the app to authenticate to Resource Token Broker with Facebook and request the resource tokens for the logged in Facebook user, then access users data in the UserItems collection.  

This diagram illustrates the solution. We are investigating eliminating the need for Resource Token Broker by supporting OAuth in DocumentDB first class, please upvote this uservoice item if you think it&039;s a good idea!

Now if we want two users get access to the same todolist, we just add additional permissions to the access token in Resource Token Broker. You can find the complete sample here.

Step #4. Scale on demand.

DocumentDB is a managed database as a service. As your user base grows, you don&039;t need to worry about provisioning VMs or increasing cores. All you need to tell DocumentDB is how many operations per second (throughput) your app needs. You can specify the throughput via portal Scale tab using a measure of throughput called Request Units per second (RUs). For example, a read operation on a 1KB document requires 1 RU. You can also add alerts for "Throughput" metric to monitor the traffic growth and programmatically change the throughput as alerts fire.

  

Step #5. Go Planet Scale!

As your app gains popularity, you may acquire users accross the globe. Or may be you just don&039;t want to be caught of guard if a meteorite strkes the Azure data centers where you created your DocumentDB collection. Go to Azure portal, your DocumentDB account, and with a click on a map, make your data continuously replicate to any number of regions accross the world. This ensures your data is available whereever your users are, and you can add failover policies to be prepared for the rainy day.

We hope you find this blog and samples useful to take advantage of DocumentDB in your Xamarin application. Similar pattern can be used in Cordova apps using DocumentDB JavaScript SDK, as well as native iOS / Android apps using DocumentDB REST APIs.

As always, let us know how we are doing and what improvements you&039;d like to see going forward for DocumentDB through UserVoice, StackOverflow azure-documentdb, or Twitter @DocumentDB.
Quelle: Azure

Total Cost of (Non) Ownership of a NoSQL database service in 2016

Earlier today we published a paper Total Cost of (Non) Ownership (TCO) of a NoSQL Database Cloud Servce. TCO is an important consideration when choosing your NoSQL database, and customers often overlook many factors impacting the TCO. In the paper we compare TCO of running NoSQL databases in the following scenarios:

OSS NoSQL database like Cassandra or MongoDB hosted on-premises
OSS NoSQL database hosted on #Azure Virtual Machines
Using a managed NoSQL database as a service such as Azure DocumentDB.

To minimize our bias, we leveraged scenarios from other publications whenever possible.

In part 1 of our TCO paper, we explore an end-to-end gaming scenario from a similar paper NoSQL TCO analysis published by Amazon. We kept scenario parameters and assumptions unchanged and used the same methodology for computing the TCO for OSS NoSQL databases on-premise and on virtual machines. Of course in our paper we used Azure Virtual Machines. The scenario explores an online game that is based on a movie, and involves three different levels of game popularity: the time before the movie is released (low usage), the first month after the movie releases (high usage), and subsequent usage (medium usage), with different volume of transactions and data stored during each stage, as listed in the chart below.

The results of our analysis are fairly consistent with AWS paper. Once all the relevant TCO considerations taken into account, the managed cloud services like DocumentDB and DynamoDB can be five to ten times more cost effective than their OSS counter-parts running on-premises or virtual machines.

 The following factors make managed NoSQL cloud services like DocumentDB more cost effective than their OSS counter-parts running on-premises or virtual machines:

No NoSQL administration dev/ops required. Because DocumentDB is a managed cloud service, you do not need to employ a dev/ops team to handle deployments, maintenance, scale, patching and other day-to-day tasks required with an OSS NoSQL cluster hosted on-premises or on cloud infrastructure.
Superior elasticity. DocumentDB throughput can be scaled up and down within seconds, allowing you to reduce the cost of ownership during non-peak times. OSS NoSQL clusters deployed on cloud infrastructure offer limited elasticity, and on-premises deployments are not elastic.
Economy of scale. Managed services like DocumentDB are operating really large number of nodes, and are able to pass on savings to the customer.
Cloud optimized. Managed services like DocumentDB take full advantage of the cloud. OSS NoSQL databases at the moment are not optimized for specific cloud providers. For example, OSS NoSQL software is unaware of the differences between a node going down vs a routine image upgrade, or the fact that premium disk is already three-way replicated.

The TCO for Azure DocumentDB and AWS DynamoDB in this moderate scenario were comparable, with Azure DocumentDB slightly (~10%) cheaper due to lower costs for write requests.

Quantitative comparison

One challenge with the approach taken in Amazon’s whitepaper is the number of assumptions (often not explicitly articulated) made about the cost of running OSS NoSQL database. To start with, the paper does not mention which OSS NoSQL database is being used for comparison. It is difficult to imagine that the TCO of running two very different NoSQL database engines such as Cassandra or MongoDB for the same scenario would be exactly the same. However, we think Amazon’s methodology maintains its important qualitative merit, this concern non-withstanding.

In the second section of our whitepaper we attempt to address this concern, and provide more precise quantitative comparison for more specific scenarios. We examine three scenarios:

Ingesting one million records/second
A balanced 50/50 read/write workload
Ingesting one million records/second in regular bursts

We compare the TCO for these micro-scenarios when using the following NoSQL databases: Azure DocumentDB, Amazon DynamoDB, and OSS Cassandra on Azure D14v2 Linux Virtual Machines, a popular NoSQL choice for high data volume scenarios. In order to run tests with Cassandra, we utilize the open source Cassandra-stress command included in the open source PerfKit Benchmarker.

Hourly TCO results depicted in the chart above are consistent with the observations in Part 1, with few additional quantitative findings:

DocumentDB TCO is comparable to that of OSS Cassandra running on Azure D14v2 VMs for scenarios involving high sustained pre-dominantly write workloads with low storage needs (i.e. local SSD on the Cassandra nodes is sufficient). For example, 1M writes with a time to live (TTL) less than three hours, or most writes are updates. Cassandra is famous for its good performance for such scenarios and in the early stages of product development is often seen very attractive for this reason. However, the non-trivial dev/ops cost component brings the total cost of ownership of Cassandra deployment higher.
If more storage is needed, or the workload involves a balanced read / write mix, or the workload is bursty, DocumentDB TCO can be up to 4 time lower than OSS Cassandra running on Azure VMs. Cassandra's TCO is higher in these scenarios due to non-trivial dev/ops cost for administration of Cassandra clusters and Cassandra&039;s lack of awareness of the underlying cloud platform. DocumentDB TCO is lower thanks to superior elasticity and lower cost for reads and queries thanks to low overhead auto-indexing.
DocumentDB is up to two to three times cheaper than DynamoDB for high volume workloads we examined. Thanks to predictable performance guaranteed by both offerings, these numbers can be verified by simply comparing the public retail price pages. DocumentDB offers write optimized low overhead indexing by default making queries more efficient without worrying about secondary indexes. DocumentDB writes are significantly less expensive for high throughput workloads.

In conclusion, we’d like to add that TCO is only one (albeit an important one) consideration when choosing NoSQL database. Each of these products compared shines in its own way. Product capabilities, ease of development, support, community and other factors need to be taken into account when making a decision. The paper includes briend overview of DocumentDB functionality.

On the community front, we applaud MongoDB and Cassandra projects for creating significant community around their offerings. In order to make Azure a better place for these communities we recently offered protocol level support for MongoDB API as part of DocumentDB offering, and are encouraged with the feedback received to date from MongoDB developers. DocumentDB customers can now take advantage of the MongoDB API community expertise, as well as not worry about locking in into proprietary APIs, a common concern with PaaS services.

As always, let us know how we are doing and what improvements you&039;d like to see going forward for DocumentDB through UserVoice, StackOverflow azure-documentdb, or Twitter @DocumentDB.
Quelle: Azure

Azure DocumentDB updates: quick start experience, backup and restore, and firewall support

Over the past couple weeks we released a number of improvements to the developer experience and capabilities of #Azure DocumentDB. We added a new quick start experience helping you to get up and running with a working app on DocumentDB in seconds. We launched a preview for backup/restore and inbound firewall capabilities, as well as released numerous runtime improvements including expanded support for geospatial types.

Quick start

One important characteristic of any service is the time it takes to get a working app up and running. We released a new quick start experience that gives you a personalized ready-to-run sample app connected to your newly created DocumentDB account in seconds. Create a new DocumentDB account and click on the quick start menu item in your existing account and give it a try.

For accounts with MongoDB API support, we had added a handy code snippet for all major platforms, with all the necessary configuration to get you started, including what connection string to use.

Backup and restore

DocumentDB is built with high availability and global distribution at its core – it allows you to scale throughput across multiple Azure regions along with policy driven failover and transparent multi-homing APIs. As a database system offering 99.99 availability SLAs, all the writes in DocumentDB are durably committed by a quorum of replicas within a local data center, and replicated across all the regions associated with your DocumentDB account.

DocumentDB also automatically takes backup of all your data at regular intervals. The backups are taken without affecting the performance or availability of your database operations. All your backups are stored separately in another storage service and are further globally replicated for resiliency against regional disasters. Customers can now request to restore their databases and collections from a backup by contacting Azure support. Below is an illustration of periodic backups to GRS Azure Storage performed by DocumentDB for all entities.

Learn more about backup and restore for DocumentDB.

Firewall support

Due to popular customer request, we recently offered support for IP filtering and firewall rules in DocumentDB for both DocumentDB and MongoDB APIs. Customers can configure their DocumentDB account to allow traffic only from a specified list of the individual IP addresses and IP address ranges. Once this configuration is applied, all requests originating from machines outside this allowed list will be blocked by DocumentDB. The connection processing flow for the IP-based access control is described in the following diagram.

Learn more about DocumentDB firewall support.

Expanded geospatial support

With a recent service update, Azure DocumentDB now supports geospatial indexing and querying of Polygon and LineString objects, in addition to the Point object. DocumentDB can automatically detect GeoJSON fragments that contain Polygon and LineString objects within your documents, and index them for efficient spatial proximity queries.

Spatial querying of Polygon and LineString objects is commonly used to detect "geo-fences" in IoT, telematics, gaming, and mobile applications. You can enable or disable spatial indexing by changing the indexing policy on a per-collection basis. Read more about working with geospatial data in DocumentDB.

 

We hope you find this new functionality useful as you build your solutions on top of DocumentDB. As always, let us know how we are doing and what improvements you'd like to see going forward through UserVoice,  StackOverflow azure-documentdb, or Twitter @DocumentDB.
Quelle: Azure

DocumentDB updates in the Azure Portal: New metrics blade and improved collections management

Recently we released several updates to the #Azure DocumentDB portal experience. We added a new consolidated metrics experience with several new metrics available including new availability, throughput, consistency, and latency metrics which allows you to track how DocumentDB is meeting its SLA's. We also streamlined collection management by surfacing all collection operations and experiences on the left navigation bar, and eliminated excessive horizontal scrolling.

New metrics blade and SLA metrics

Azure DocumentDB is a globally distributed managed NoSQL database as a service that offers 99.99% guarantees for availability, throughput, <10ms read latency and <15ms write latency at 99th percentile, and guarantees 100% consistency.  We believe it is important for you to know how the service is performing against these guarantees. We also heard how important it is for you to have all metrics information readily available without browsing through multiple windows. In response to this feedback, we have added several new metrics to reflect service performance vs SLA, as well as introduced a new at-a-glance metrics experience for DocumentDB collections. If you click on the Metrics node under Collections, you will see all metrics DocumentDB provides for each of your collections on a single surface, including:

Actual collection availability vs. SLA
Requests rate grouped by status code
Consumed and provisioned throughput capacity measured in Request Units/second, as well as percentage of requests exceeding capacity
Observed latency in the regions where your collection is located
Percentage of requests that met consistency guarantees
Storage consumed vs. capacity

You can also zoom in and navigate to the standard metrics experience for the individual charts via zoom-in gesture.

Streamlined collections management

DocumentDB stores data in collections, and majority of your time working with DocumentDB is spent working with collections. With this portal change, we bring collections front and center in the portal experience and eliminate the excessive horizontal scrolling you used to encounter when working in the portal.

The overview blade now provides one-click access to collections, as well as "Add Collection" command.
All collection management experiences and tools are now available on the left navigation menu.
With this update, we eliminated the need for horizontal scrolling when working with DocumentDB in Azure portal.

We hope these new features will make your time in the Azure portal more efficient and provide you with the monitoring information that’s most important to you. As always, let us know how we are doing and what improvements you&039;d like to see going forward through Uservoice,  StackOverflow azure-documentdb, or Twitter @documentdb.
Quelle: Azure