IGNITE Nov 2021 Azure Cosmos DB updates - Episode 32

hi everyone welcome azure cosmos tv live tv uh episode 32 ignite roundup uh i'm mark brown and i'm joined with huge chunk of our program management team uh this week that are uh all here gonna talk about uh all the great stuff we released this week i mean it's kind of a a testament when we get together like this for ignites and builds how many how many folks are on the show it just says there's a lot of a lot of features that came out a lot of people working on stuff and uh so if you missed any of uh the announcements this week blog posts anything sessions uh we're gonna have we're gonna wrap it all up for you here uh in the next hour and uh welcome everyone how's everyone doing okay good to see you so uh first off i want to talk about uh partial document update uh let's start right there that was a big one uh and seranya you and your team worked on that um for quite some time and uh and now it's ga it's out yes mark and we're very excited to um uh break it to ga this ignite uh patch enduring call but it's technically termed as partial document update uh essentially user was number one item today wherein the clients customers were asking for being able to push down uh only partial uh specific properties or specific changes in the document to be sent over the buyer as opposed to doing a full documentary place uh which is what was the uh state before right yep so uh diving uh quickly into the feature here uh we we would support this for the sql api right now and uh we support single patch uh updates wherein we can send across a path and i'll show you how that looks like and the property that needs to be changed and the value of the prop right so either we could do single or we could do multiple patches on the same document at one call conditional patches wherein we pass a sql predicate precondition and so depending on the uh true or false of the precondition either if it's a single patch or it's a multiple patch or it's a transactional patch we support that bulk patches uh all of those can be uh performed based on the precondition so uh that's just a quick round up there uh we support uh sdks on java.net javascript of course rest and also on stone props some of the key highlights as you see on the screen on the one slider is uh it's a non-trivial implementation at the back end right wherein in a multi-master or multi-region right scenarios uh how can we enable automatic and transparent conflict resolutions uh today for example we use the last writer wins resolution by default or a custom conflict resolution that one can write but essentially all of these resolutions work at the item level for example if there are two documents where we are patching two different parts and we are trying to write them across regions only one of those will succeed based on the last writer when or the custom conflict resolution with patch we would support automatic and transparent conflict resolutions uh at the path level merges as opposed to the whole document uh level so that's really the demo that we will see uh just now that's pretty cool that uh that you can use that to do basically conflict merging uh in a multi-region right scenario that's uh it that has the potential to kind of drastically simplify the types of conflict resolution that you would have to write and handle uh when you're doing that uh which is really remarkable i think that's great because kind of what you have today in last writer wins is just more or less just brutal uh it's it's like hey i'm here last uh whatever i don't care what you had in there before it's gone now uh so and then writing but writing conflict resolution policies is complicated so this is the potential to really make that a much easier process for folks absolutely uh the uber idea here is also uh what is the real benefit for customers clients developers is really what we like to say as developer productivity in terms of uh hey you can now avoid doing say occ checks or extra read uh probably process documents do a local patch and do a full document replace pass the whole document over the network payload uh so all of those are significantly reduced right so uh so that's uh probably the biggest uh benefit of patch the way we want to position it we do not want to position or even you would notice if you're using patch that is not really about cost optimization or are you optimization and this uh i want to just def uh highlight that it's not just for cosmos database uh patches in general at the back end it's very compute intensive right you look at other complete products and market patches are actually more expensive so uh i want to say that in our case it's not going to be more and especially if you're doing multiple batches with single calls then you'll realize more benefits but if your reason to use patches to reduce costs then probably that's not the best use i've been saying that to folks as well is this is not a this is not a bomb for poor document design if you've got large documents and highly asymmetric update patterns uh you need to shred the document uh and put the static properties in another document and then the ones that update with high concurrency and another in a separate document and then do updates on that um that's the yeah patch does it replace good design very nicely yeah so here's uh the quick demo that we'll see uh hopefully you can see my screen and this is a cosmos db account got a collection container and it has bunch of items each item is a very trivial simplistic item having x and y coordinates we're going to paint a picture on the canvas and for picture we need colors so we are having our g and b values for those colors right so currently as you see uh r g and b are zero so if you're reading uh this document for a particular color you would get the color black so uh in this collection we do have about 15 000 documents each for one pixel so if i'm running uh a front-end xaml file uh this is going to read from the collection we just saw and each pixel in the xaml file will represent one item in from the document so let's just load this as you see it's reading from documents so we put in a background of green and the fact that you're seeing uh black here means that we are actually reading from the back end uh database and we see black so with this let's just minimize this and let me go back and tell you what we're trying to see and do here [Music] we have for three clients uh from different parts of the world like east u.s central india and east asia so you see these three climbs and then we're going to go ahead and run uh patch operations from each of these clients and let's keep all this side by side so we can see how things work and each client updating one of the three colors are g and b so we'll see that for a same document paths are not conflicted the three unique paths uh you see three properties are g and b but they're being concurrently patched from across the world in uh from different data centers right so while we're waiting for this let's go ahead and kick this off and get this started and then we should see as the patches progress the colors will start appearing on our canvas because they are being read from the back end and uh for the sake of this demo just to show concurrent conflicts coming through we are patching red as you see from top to bottom so uh at this point we started red before the other patches so it's got a head start and we'll see that patches are for the red colors are coming from top down the green is also being patched from top down as we see uh and uh the value blue for the color blue is being patched from bottoms to top to ensure that we do see more conflicts as we see here the pa the point that i do want to highlight it's not that we're going to use patches for multi-region globally distributed databases all the time but this proves a very strong point that of between a part level conflict business and uh item level conflict had we chosen an item uh or had we done it using an item level or a replace operation we did take a screenshot of that right so i'm just going to pull back the powerpoint deck that you just saw that if we were using the last title wins with an item level conflict feed you would see at some points when there's conflicts there's only one of the two colors which will succeed that means either the document has red or document has blue or green etc so see kind of a patchy picture of monolith that you see here however in our demo hopefully once these patches are going through so as you see the red has completely patched now there is uh simultaneous patches between blue and green so that's the second part of the picture that's going through and soon we should see the whole image completely yeah looking better already yeah this is very cool so lots of cool uh capabilities in there uh being able to patch multiple properties at the same time uh whether it's adding a new property or updating uh or setting a property uh removing a property i saw there was an increment uh option in there that's very cool if you wanna i'm guessing that's for if you wanna do a counter of some sort or or like if say you're aggregating uh like i have a scenario where i i store sales order aggregates in a customer record you could just simply just call increment on that patch it that's pretty cool i probably can update my demo to use that um and then you can also because uh these all operate uh within a single partition you can also enlist these in using transactional batch as well is that correct right so uh we've got this uh the documentation out as well so if you see our docs on the dark page we support multiple operations as um mark jason you did add and set and we have an faq between what's really the difference between add and set it really adds on for an array value so let you take a look at that and uh replace remove and increment is plus or minus x so we do increment and decrement so uh those are the operations that we support today and uh if you look at the supported modes as i said we support a single patch multiple batch conditional patch transactional handbook very cool so let's go back and quickly see the demo completed so here you see a fully uh uh fully patched mona lisa and that brings us to the close of what we're here to show that's awesome thanks thanks patch i would request all of you to try it give us feedback and uh looking forward to seeing you use it great thank you so much uh seranya that was awesome uh next up uh let's talk to theo uh you've been busy sir i know with uh your uh apache managed instance oh gosh how many say this right it's azure managed instance for apache cassandra did i did i get it right yep that's right okay oh yeah all right so let's talk oh here before i do that uh if folks want to check out uh our blog post this is the roundup blog post uh that nikisha and our team puts out uh this is a good place to start so you can get links to all of the other announcements we've gotten here and then within there we've got links to docs and all that other stuff so i'll just put that up there for a sec uh let you go um sorry theo i didn't mean interrupt are you with me sure yeah no i'm here oh yeah yeah no go go ahead it was hypnotized by that demo it was just so creative yeah that was a brilliant demo surrounding i don't know if you're still there well done thanks thanks to you yeah okay uh yeah so i'm so distracted that was brilliant yeah so um yeah azure managed instance for apache cassandra is uh generally available um so uh along along with the release along with the ga of the the service well i guess first of all for anybody who doesn't know um azure managed instance for apache cassandra is a managed service for open source cassandra uh it reuses the cosmos db control plane but it doesn't have any uh back end dependencies on on cosmos db it's built by our team um and that's what it is it's really really as simple as that it runs uh apache cassandra has various uh deployment operations scaling operations maintenance operations and so on and it's it's exactly what it says on the tin it's a managed service for apache cassandra so now we've ga the service um and that's bundled along with a few features so we now have a customer managed keys so customers can um encrypt data on disk with their own keys and rotate them uh we now have availability zones for in the regions that support availability zones um we also are integrated with azure monitor for metrics and diagnostic logging i'll show that in a minute and we have backup and restore as well we have an sla of course as most uh as all ga services do um it is available um in all public regions of course it's always uh subject to capacity and availability and so on um we have some additional skus but up until uh at the end of uh public preview we only have one default sku and users can now select the number of disks that are attached to each each node in the cluster and we've enhanced the portal a little bit so uh let me just um segue and and and show that uh so i just have a few clusters already uh deployed here and one of the main things we've done is just added a data center uh tab so previously you couldn't see the cluster information but now you can view uh your um data centers when they're up from running um and then um you can see the status of of nodes and and different skus you can see here i've got two different regions i've got two different skus as well so maybe you've got two different regions um um where you want a skew a lower skew a cheaper skew uh in one region maybe that acts as your backup but it's an active it's obviously an active backup and then you have a more popular um beefier uh sku in your other region um and so you can do that and that's perfectly fine um and then the other thing we've changed uh is the create experience so that's been changed slightly um so we've now split this into um cluster and data center so you fill in your cluster information first and then you go through there and you can add availability zones if you want and then as we said we've got um different skus these are based on the uh vm uh skus uh and uh you can select the number of disks um uh per node and so we have that there um and then the other thing i wanted to just pull out quickly or to just show um is that as i've said we are integrated to azure metrics so you can select from a bunch of metrics here these will grow over time but now uh there are some useful ones there and you can visualize those as you would with any any service that's uh using uh azure monitor and we also have diagnostic logging uh as well as you can go through there and run queries um based on uh cassandra server operations but also audit operations as well and that might be things like logging or cql operations and so on so that's fully integrated as well wow this is really when you say fully managed it is seriously fully managed i mean you've got lots of instrumentation in here it's the integration is just beautiful uh in there that's uh that's this is really awesome uh i would think for customers that wanna i mean i think that's why we created it is to help customers bring their workloads into azure uh and if they're working on cassandra they can um they can start here i guess right yeah and i just said earlier on i was i think i was so mesmerized by the demo before that i clicked on a data center in cluster that hadn't come up yet so this is what the the view looks like because you know about different nodes and and so on so yeah it's it's taking shape as a as a managed service but of course you can interact with it as though it were self-hosted as well so the goal that we're going for here is to um like i said on on the last show that i was on it's kind of like a semi-automatic right semi-auto shift and we provide a lot of automation but you can take over the controls as well if you want yeah and with all that integration with v-net i mean you could essentially if you're running clusters on-prem you can connect via express route and then tunnel that into your v-net and your subnets so that you can essentially run these clusters that are replicating uh in a hybrid environment essentially right so and that's great uh people can then go and start at their own pace start migrating workloads if they're trying to get those onboarded into the cloud so this is quite remarkable that's i love this this is really really really really nice yeah it's great and i love that it's a unique in that sense it's this is the only managed service i know of that that can do hybrid deployments so you're connecting to something that's self-hosted or on on-premise yeah so yeah i mean again i always say have a look at our documentation um and let us know if you what you think is what you see gaps there or things that you want to be added we're always happy for feedback and contributions as well so take a look at that of course you've got the sla published uh so um that's what that is and you can um you can see that online as well um so that i mean that's it for for managed instance i feel i feel bad that i didn't have a uh quite as exciting a demo as uh cerania but but yeah that's that's what we've got yeah the other feature um so i'm kind of shifting into another product now just in case you're not noticing this is a cosmos db uh and of course it's cassandra api um and we've just released in public preview uh server side retry so for those of you who don't know or maybe you don't know about cosmos db uh cosmos db uh is provisioned with request units and if you consume too many requests units at any given moment you're going to be rate limited uh and so this can sometimes be a problem it's also very good as well it makes profi capacity and provisioning very easy and deterministic but you'll get rate limits and you'll get errors and so on so we have this feature which uh um um the core api and also mongodb api already has and we've now added this in public preview into cassandra so you can just uh enable it here uh and then that will just retry up to uh 60 seconds worth of um retries and then it will timeout after that so it gives you a little bit more like a normal server behavior and that that's been in put into public preview now and the docs are up there for that so you can go and read that and find out how to enable that how to set that up the different ways of enabling it and what it's useful for very cool yeah that's uh i think gonna be welcomed by lots of folks i know users love it when they're trying to ingest large amounts of data is they're not quite sure what to do with a 429 because when they do this on vms it just kind of uh they just they just see increased latency as the request kind of queue up there and this will help kind of mimic that behavior for uh for cassandra users so all right very cool thank you so much theo this is good stuff uh next up uh the fun just keeps coming here we got rodrigo and he's gonna talk about uh some cool new stuff with synapse link and um this is i know another feature that oh i love that i'm hallucinating now looking at rodrigo's screen there uh put it on your your slide there that's yours i think that's you rodrigo isn't it i think so all right yeah so there we go my screen yeah now i can see it all right all right so uh a custom partitioning uh preview uh yeah walk us through this okay let's go so the snaps link when we announced the netlink last week last year we we only allowed it analytical sort to have horizontal partitioning meaning that we are not using your transactional store transactional store partition key for analytical store partitioning and this was a challenge for customers with really big data volumes right so what we are announcing this week now we are allowing customers to use their spark clusters so it's not fully managed it's customer managed and they can create their own version of an analytical store dedicated they can create their own partition store using the key they want right so let's say here in this hypothetical scenario we have a customer that is ingesting iot data and the device id is the partition key for transaction store and we know that an analytical source isn't partitioned by device id or nothing else but we use an analytical store to create your custom partition store and let's say this customer needs to use date as a partition key these will address a scenario where this customer is frequently using dates in their to filter as a filter in their queries right but what if we this customer they also need to read data by state or something like that they can create another partition star so there isn't a limit they can create multiple partition stores and of course it depends on their business cases and requirements right and what are the benefits to use this capability right so the first one it's really obvious we're gonna when you're reading data from your partition store we we use scan less columnar files less data right so your queries will run faster that's pretty obvious that's the first benefit but we also have benefits for some specific scenarios like heavy updates and deletes workloads because this will create the the log of transactions that happen your transactional store they are replicated to your analytical store but when we create a partition store we're gonna only represent the last state of the data so we will have here in partition store the last version of your data and this is really helpful to speed up your queries yep customer queries so this is like uh doing with what we would do like materialized views in row store where you would use like a change feed listen for data being written or updated and then copy it into another container with a different partition key and use that to serve queries this is basically the same thing but it's done at the analytical store level yeah so and also customers know today that when we are out of syncing their transactional store data with analytical store no ru's are being used and here analytical store is the source for the partition store again no rus are being used right and of course when customers are reading from an analytical or partition store again no our users are being used so we have cleared this cost benefit for the customers got it i also want to mention that customers with slow data ingestion and we are still defining what is all data but something like 50 gigabytes per day it would create some small files in analytical store and again when we run our jobs to create a partition store we're going to compress this data so again a benefit for customers speeding up the their queries performance right so i'm gonna leave my presentation now and i'm gonna navigate to the browser let's see how it works so first we have to define the partition job so we have can you see with my screen yep just making it a little larger for folks yes so how to define the partitioning the custom partitioning job uh we need to use the our our olap connector right and to inform what is the linkage service this is this is the the synapse workspace studio so spa we define it before the linked service here in the the data tab also our container and we are executing the partitioning and here is is are the new uh options we have for this comment so we we can define the keys it would have been a keys yes you can use more than one you can use redate and state in the same partition schema or you can create another partition store just by state and we have good practices about partitioning in our documentation so this is our documentation here a lot of information the same diagram i was showing you before and we have as an example this partition strategies section it will be very useful for customers to decide when to use composite keys or multiple keys that will create multiple partition stores so going back here this because the custom partition will be created in the same azure data lake store account used by synapse workspace and there you can define your base f so it's fully customizable and you can use whatever you want what it what is easier for the customer right so but you need to define what is the base path oh what if i won't they run the exactly the same job for another base path we are going to create another partition so and this is some uh configuration that customers need to fine-tune for their environment they may define the maximum number of records per file right so best thing best suggestion here is to do a plc and try a couple of different values and see what works better for each workload it depends on the queries you're running right so i have a simple query here reading from this job that i run before right and but i'm not using not using the partition so i'm just using analytical sort simple analytical sort right and this job this query this simple query we have something like 10 gigabytes in this data set it took four minutes and nine seconds to run four minutes and nine cents all right so as you can see one of the jobs it had to execute along almost 8 000 tasks to get to this return here 162 blah blah blah that's the the maximum in that date but if we use exactly the same query but one difference using the partition store right but exactly the same query it runs in 31 seconds and do you remember that we the the the heaviest job was doing almost 8 000 tasks now we had 158 so that's quite a remarkable improvement in performance and latency there i guess the question is is um how do you decide whether or not it's more efficient or cheaper to do to do it this way versus running having a long-running job is is there a way to can you balance or measure performance and cost uh using this yeah so we are working on benchmarks and so on but my suggestion needs to do a plc especially because when customers when they write once read many for sure it will make a difference and it will save costs we have in our blog post that was a great question mark i have here our blog post talking about it and a lot of details and we have a quote from a customer the austra australian energy market market operator and they highlight how custom partition was essential to provide performance insights in their for their internal stakeholders right so our suggestion is to do a uh to run a plc right but for scenarios when you write one's read many it's really useful i also want to call out that when you're reading no two things i want to call it first how often should you also relate it to your question mark how often should we run this job yeah it's custom managed so if you need to keep on taking reports from this data maybe once per hour once per half an hour or maybe it's a job it's a report that you you only need by the end of the month so run it once per month i see but i have a scenario where data is being ingested all of the time and i run this job what happens with the tail of the data that is ingested after the last execution of the job so this is a common question we have from our first customers so when we are reading from uh the partition star we will also read the tale from analytical store meaning that you you always have the same results okay and i want to close my my section with another pretty small slide with our limitations today we have uh we we are in a public preview and for now it's it works on spark 2.4 only so when you deploy a synapse spark cluster you can define if you're gonna use spark 2.4 or three so today we are supporting only a spark 2.4 but of course we are working to to support three also synapse sql serverless can't read partition store yet and of course we are working on that it's coming soon and synapse link is available for circle api and mongodb api today and it's not but custom partition isn't supported for mobile db api right now and we are also working on that for more information we have this akams link yep for our documentation and i also suggest the our blog post with more information about it where we have two other last two last information we also announced synapse link compatibility with azure cosmos zb serverless right so now we you can use also you can you also can use azure synapse link with cosmb serverless and we are now supporting full-fidelity schema for sql api accounts before before this announcement it was sql api accounts were were always well-defined schema so we are bringing more flexibility for our customers right sounds like i need to get you on the show uh more rodrigo there's a lot of stuff you got going on here man yes well this should just just show here these two last information they they can take a maybe an hour all right you know what i got an empty slot for uh later this month uh let's talk after the show i want to get you back on i want i want you to show this to people so they can get and learn more about this let's uh thanks a bunch rodrigo this is a ton of great stuff uh i appreciate you coming on and showing us uh let's keep on trucking here next up we've got tim and tim's going to talk about indexing metrics how you doing tim not too bad great to be here today mark yeah so um this week at ignite we were happy to announce new indexing metrics for cosmos db and the purpose of the indexing metrics in cosmos db are to show you which indexes your query used as well as which indexes that your query could potentially benefit from so the index metrics basically have four components here the utilize single indexes potential single indexes as well as the utilized composite indexes and potential composite indexes now with the utilize index we can say basically with certainty that the query that you're looking at the index metrics for use that specific index path so in a lot of cases if you have a slow query one of the first things you'll do is add on a new index the index metrics is a great way to verify that the index that you added on was actually used in your query in the past you actually had to guess this based on the query metrics and there wasn't a way to conclusively know now by looking at the utilize index pass that you can know for sure whether a new uh index whether it's a single index or a range index or a composite index was used by the query now in addition to the utilize indexes we also show you potential indexes in the index metrics and you should think of these as recommendations from the cosmos db query engine as indexes that are likely to improve your query performance now for a lot of these it's it's not 100 chance that will improve your query performance like of course there may be some recommendations that just based on the nature of your data don't improve performance all that much um but we believe based on the way that the query engine uses indexes that those index paths will substantially improve uh query performance if you go and add them so that would surface them and the potential index paths here's a quick example of what that looks like the index metrics are available in the net and java sdk so if you're using the latest version of each of those and you look in the response after running the query you're going to see a new index matrix value and it's just a string value that that looks like this and the two components are the utilized single indexes and obviously potential single indexes as well as utilize composite indexes and potential composite indexes so in this case if you let's say ran a query with the default indexing policy it would have used these specific index paths here and then the index metrics would show these recommended composite indexes where we say okay if you go and add on um these composite indexes we expect that you'll be able to even further improve query performance so since we've done a nice introduction in the future we'll switch over to a quick demo that i have where i'll show you what the output looks like for a sample account that i've set up so jump into the portal now we'll show a cosmo cd account that i've set up where i've ingested a few gigabytes of uh of data and this data has the default index everything policy with one slight modification we've added on a composite index on job and timestamp both with the ascending order um so i guess since we've covered the indexing policy we'll go and look at the specific items within this container here's an example here basically it's just uh data for different employees at a fictional company so it has a id a name address a job and so on and a timestamp value so i'll jump over to this quick demo that i've written here basically what what this demo does is it connects to that cosmos tv account and runs this super super simple query here we can zoom in a little further so that's easy to see uh we're basically getting the uh top 20 developers sorted by by timestamp and what we'll do as we go through the query results is we'll just go print out the index metrics for each page as well as the ru charge for each page so i'll go ahead and run that one and of course this query is going to utilize that composite index that we already have on job and timestamp so this is a great way to confirm that we can confirm that this query utilize that composite index on job and timestamp i go and modify the query slightly uh now i filter.name i'll change it filter down java i'll change it to filter on name and i'll i'll say where name is equal to mark brown uh if i go and run this one obviously i don't have a composite index on name and timestamp we do however have uh our index everything policy set um so this what this uh index metrics now we're going to show is a recommended index on name and time stamp so if i zoom into the just the first page first uh page they're all the same on each page but if i just zoom into the first page we can see that for that particular page the query costs 14 are used uh it's used the index pass name and timestamp which were already there because we had a slash star index everything policy but the query engine has also recommended indexes on name and timestamp with a composite index so we should expect because this index impact score is high if we go and add on this composite index we are highly likely to see a substantial impact on query performance that's awesome you know i like i monitor stack overflow uh pretty much daily for questions and stuff and that's a very common question like uh would i benefit from an index by the potential single or or uh composite for this type of query and this kind of data and it's always well either i come back and ask you uh or it's like hey uh kind of hard to know unless you try uh and what you're saying here is now they can basically answer their own question um by just turning this on and then looking at what's coming what's being emitted in the response object uh for this is that that's what that's exactly right now it's it's good to call out that there's not a guarantee that this is going to be like a a huge impact in performance right if you want to add on the composite index uh so just as if you were coming up with your own indexes to use like you should still try them out and test out their impact on performance um in most cases the worst case scenario is that we just don't use the index and it doesn't change performance um so you don't really stand a lot to lose here but that being said you don't want to go on and add on indexes like crazy because that does have an impact on write charge so right use these recommendations as a starting point but definitely try them out and i mean see the impact they have on great performance now this is great that at least we're providing at least more guidance and help for folks to be able to figure out uh where could they where could they get better performance on their queries at least uh with the addition of indexes in there so yeah man yeah very cool uh question here in fact i got a bunch of in my comments as well uh uh tim are there is there any plan to add utilize indexes option in the portal yeah that's a great point um so right now this is supported in the net sdk and the java sdk and that's the only way that these are accessible adding it to the portal is on our long term roadmap for sure because a lot of customers maybe they they don't use those specific languages or maybe they're they're not developers and they they don't write code in their day-to-day job but they still want to optimize the indexing policy so it's definitely planned on the long-term roadmap but for now you'll want to stick to the sdks for using this feature all right cool thank you so much uh i just had let me go through some of these questions in here uh huh all right well here's one it's not really about anything any plans for implementing cypher support in cosmos tv uh i don't think so uh not really on our on our road map uh that i've seen um i think i've seen a user voice ask for that but i don't think it's gathered a whole lot of votes there so uh so uh no not uh not on our current uh roadmap here uh let's see just a comment kudo for partial update will solve so much issues in performance yes very exciting partial updates i'm definitely going to go and start rewriting a bunch of my samples to start using it because it could be a huge help comment from greg moyer here i would love to see compression of the data i store in cosmos db that would save enormous costs for those that have large volumes of data uh well we already compressed data um when we store it i think uh i know we've had major performance improvements with uh recently with kind of the newer newer api version there where we're doing better on the compression uh but yeah thank you for your comment we're definitely always working on making uh data more uh efficient in storage there uh another comment here i'm a very big fan of azure cosmos db currently started my project on it it's exciting exciting to see in production well thank you very much um we're definitely excited that you're that you're excited with that um well here's a here's a controversial question are there plans to return back notebooks and cosmos tv uh deb you want to take that one since uh sure uh thanks for that question uh yes um very hard at work bringing notebooks back so uh you should be able to be we'll expect to see that in the future yep we're working on it believe me we're working on it we'll get that back soon so okay uh moving on here we've got uh deb you're gonna be talking about our new throughput advisor this is another very cool uh little feature uh just like things like indexing metrics these really these things kind of help kind of take some of the rough edges off provide good guidance for folks that are trying to build and and and in some cases do kind of capacity planning and and budgeting for their applications so yeah talk let's talk about what uh what you guys got what you got here cool thanks mark so one of the most common questions we get from customers when it comes to throughput is should i use auto scale or should i use manual which one gives me the best cost and performance for the workload uh so what we're excited to announce uh this week is we have two new azure advisor recommendations that analyze your existing workloads on cosmos tv and actually recommend which setting autoscale or manual will be the best for you in terms of your to help you best utilize your throughput and get the most cost savings uh so to see it in action here i have two collections uh this first collection here i set it to use auto scale throughput the scale between 400 and 4 000 are used so i want to know as a user is auto scale actually saving me money or should i be using some other setting like manual throughput at the same time i have another collection here which i currently have set to manual throughput but i have this question should i be really using auto scale for this collection uh so to answer these questions before our recommendations what you typically have to do is you'll go to insights which i can find right down here and you'll filter to the collection that you're interested in so filter to collection one so again this is the one i currently have provisioned as autoscale and the benchmark that we always want to look at is normalized ru consumption normalizer consumption is a metric between zero to 100 which basically tells you how much of your ru's have you actually used so the closer to 100 the higher utilization you have when it comes to choosing between auto scale and manual the magic cutoff point is 66 for this so if your average utilization across all the hours in the uh month averages to 66 or higher that means you're actually using your throughput quite a bit so auto scale really isn't going to help you too much on cost because you're always going to be scaled super high in contrast if your utilization averages to something lower but you still have vocational peaks where you hit 100 then auto scale will help you save by automatically scaling to the minimum when it's not in use so for this collection let's zoom in on the normalized ru consumption and if i zoom in and look at it it looks like for actually quite a period of time i was either very close to 100 percent or exactly 100 percent with a couple hours of idle time uh so prior to our azure advisors you'd probably would download this file look at the average for each hour calculate see if it's greater or less than 66 uh but now with our new azure advisor recommendations which you can get to again same context in your cosmos db account just click on advisor recommendations you can see i have a couple here for my account and go to cost and indeed i have one recommendation that's encouraging me to configure manual throughput instead of auto scale on my resource and when i scroll down it's exactly this exactly this collection one here uh so what the advisor does behind the scenes is about once a day it looks at your actual usage your actual utilization uh figures out that average for you and estimates what you would save if you moved to the other setting so here because my average utilization of my max are used is so high around 80 percent i'm typically scaled to around 3000 rds anyway so uh so that uh recommendation is telling me if i can switch back to four thousand dollar use of manual throughput i'll be able to save around five hundred and thirty dollars a month that's cool yes sir really hoping to take the guesswork out of it um so uh i highly encourage you to take a look at the azure advisor recommendations if you haven't already um we also have the core laylee core over the the complimenting one uh uh currently using manual throughput and should you use auto scale or not so for this one i've got collection two over here um and you can take a look and see in the consumption it kind of looks auto-scale-ish but to know for sure we can go to our recommendations again and if auto scale is a good fit you'll see something like this so basically for every hour in the past seven days we analyze how much does it cost to provision that static manual throughput for the hour if you had enabled auto scale what would cosmosdb had scaled you to based on your usage uh figure out the cost for each hour and then if you can save a non-trivial amount by moving to auto scale then we showed the recommendation here um so inclusion we're really hoping uh if we've sent out i think there's like over a hundred thousand like collections that we sent this recommendation to they're always ongoing and they update once a day so if you haven't taken a look in a while i highly recommend go to your account click on your advisors and see if you can realize any cost savings uh today yeah awesome great uh thanks so much deb this is uh like i said it's all the stuff we're doing is like for years now to try to make people as efficient as possible on cosmos with um you know things like serverless and auto scale and all those although all the stuff we're doing this is just kind of all along that same vein uh and in fact uh i want to move over to thomas now uh because we've got even more stuff uh to kind of help people manage uh cost on cosmos uh thomas let's talk about uh let's talk about the cost governance stuff uh that we released this week absolutely thanks mark uh i just want to take a couple of minutes here to switch gears and to uh to talk about another you know great feature we just announced at ignite and as you just mentioned that one is really about cost management and cost governance so the problem we are solving here is uh cosmos db users will sometimes see unexpected charges and and that can sometimes happen for brand new customers brand new users who are you know new to the platform due to the service and they just get started and they don't necessarily understand all the all the impacts all the cost impacts of the changes they are making on their accounts uh now if you are using cosmos db in provision throughput mode as opposed to serverless mode most of the charges you will see will come from well the amount of throughput you have provisioned across your account right and so the approach we have taken in order to let you know better control your costs is to give you a way uh to put a hard limit on the total amount of throughput you will be allowed to provision across your account okay so essentially we give you a way to set what we could call a throughput budget right so you you set up a budget you say i really don't want to be allowed to exceed x areas per second of throughput across my account and any any configuration change that will that may exceed that budget will be blocked by the service so let me just quickly show you what this looks like it's really simple really yeah um here i have a cosmos db account with uh two containers belonging to the same database the first container is provisioned at 400 are used a second at 600 rus let's say i want to put a limit on the on the additional throughput i may be allowed to provision here on my account so now what i can do as you can see we have a new entry here on the left side menu which is cost management and so if i go here i will see two things first i will see a summary of what's the total amount of throughput that is currently provisioned on my account so we show you a very nice breakdown per but at the per database per container so here i see kind of a synthetic view of you know all the resources i have on my account 400 600 that means that right now i have a total throughput of 1000 ios per second provision on my account you can also see the number of regions that account here it's just uh deployed in one region uh obviously if i were deployed in two regions then we would multiply that number by two right because as a reminder for our viewers here um when you add regions uh to your cosmos account we project the same amount of throughput in all the regions you have yeah you know i was going to ask that question like okay i sounds like you can stop from provisioning or increasing throughput but what if i add a region because i so many times people are coming to be surprised like hey i created an account and now my bills double and i'm like did you add another region they're like yeah and i'm like well that that also requires compute to run as well so uh yeah that's cool very very common scenario as you just mentioned yeah customers and again new customers right customers who are new to the platform they don't necessarily grasp all the ins and outs of cosmos db and they don't necessarily understand that whether you have a region you add throughput you are provisioning more throughput on your account and you will be charged accordingly okay um so yeah the first section here shows you the total throughput that is probably on the account and then on the bottom you can set a limit on that total report by default right now the limit is disabled on our user's account but i can activate that obviously i cannot set the limit below what is currently provisioned right so i wouldn't be able to set a limit below 1000 right now but i can set any limit i want otherwise also as a convenience we show you a quick cost estimate uh you know based on the the number of reus that you that you want us to limit uh just for you to you know to give an idea what's the maximum cost that would be involved in uh in the throughput that we are allowed to provision um that's pretty much it right i just have to hit save here and and at the bottom and this would this would just be deployed or applied to your account just to to to save some time i have a another account where uh uh where the total is already applied here at 1000 that account is actually configured in the exact same way the first account i was showing you before if we go here to the data explorer i see i have one database two containers here the first uh container being at 400 iu the second one 600 ru so i am i am really at the limit i have set i have 1 000 i use of total throughput right now and so yeah all right well let's let's see so let's try setting it to let's leave about 100 to increase to 500 uh well you know this is not enough you see a very uh obvious error message we don't even let you know start the operation we say we tell you very explicitly well you have set the total throughput to 1000 this update is not possible because you would have increased the total to 1100 and you can always go to cost management back there to increase the limit if you want uh so that's that's the error you are seeing i would see the exact same error if i was trying here to add a new connection if i was trying to add the region uh and even if i if i was if i was trying to do those changes through our sdks right through what we call the data plane the exact same error would come back saying hey you have a throughput limit on your account and you cannot exceed that limit does it work on the does it work against the rp as well yeah absolutely so so we we have made sure that we have locked all the ways for our users to to make any configuration change that would increase the throughput all right so i can't sneak it in using some cli or i don't know it's pretty it's pretty hot i should say before i finish i also wanted to mention that this is a very nice feature for our 3d customers right because if you are using cosmos even 3tr mode you get the first 1000 iris per second of throughput for free and you want to make sure that that that will remain free right so you want to make sure that you will not be allowed to exceed that amount of throughput provisions across your account and until now we didn't have a good way for our customers to actually lock their accounts i mean that kind of that kind of configuration wasn't possible so what's possible now here i am on a uh free tier account as you can see the free discount here is opted in i can similarly go to the cost management uh blade that new section that we have introduced and here that first option which was grayed out in the other account here is is possible that that's basically that option is just a shortcut saying well please limit the total throughput to whatever is is granted by the free tier okay so right now it's 1000 may increase in the future who knows but that that option we always make sure that uh at least in terms of the the throughput you will provision on your account uh your three year account will remain free that's so important i mean a lot of obviously the new our newest customers are going to use that free tier just to try and uh don't want them to get shocked or surprised by hey why isn't this free when you said it was free so now they can lock it down keep it free and stay free so uh yeah fantastic absolutely that's pretty much it i mean it's a very simple feature i believe it's a very powerful feature uh in the amount of things it lets you do or rather it doesn't let you do uh so i would encourage you know all our customers obviously to have a look i would strongly encourage our brand new customers to enable the throughput limit uh just to make sure that you are you're on the on a happy track as you are making your your first journey yeah well great thomas thank you so much uh more good stuff uh last we've got justine uh and she's gonna talk about uh the new logic apps standard connector for cosmos tv did i did i say that right yeah that's right thanks mark so today i'm so excited to show everybody the new it's a built-in connector for cosmos db on logic app standard and what that means is because it's built in it's actually running in the same process as the logic apps run time so this is in contrast to the existing manage connector which some of you may have used um that connector is actually running in a separate process so this because it's a built-in connector it avoids a network call and that translates to lower latency and increased performance and it also allows you to have much higher throughput so this built-in connector is really targeted at those high throughput really business critical scenarios um so i'm going to show you a couple of the operations that we have available and i'll do that by walking through a sample workflow that i have so i'll just pop into my inventory demo and this this demo workflow really shows a super traditional workflow that you might find on logic apps um basically it's triggered by the customs2b change feed so we have our first trigger here this is that um what really kicks off the workflow i'm listening to a products database and i've set up an orders container so this is going to be an inventory tracking system anytime a new order comes in we want to check do we have the available inventory to serve this this request and then we want to react to that so i have my trigger based on this orders container the next thing that i'm going to want to do is i'm going to want to read and see if i have that product in stock so this is reading out to a separate container which is my products container and you'll see for my item id and my partition key i'm actually parsing the content data that was passed in as the the document that triggered this workflow so i'll just switch into code view so it's a little bit easier to see um logic apps offers expressions that you can use to parse out certain things so here i'm looking at my trigger outputs the body content data and product id this is kind of complicated um all of it is explained in a beautiful how-to guide um which i i believe that we'll be linking to as well um so now that i have the all of my parameters i can go ahead and read this item i've just added a sample helper action here which will parse the json coming out of my item so basically that item that i found um if you don't want to use the expressions to dynamically read your values each time you can use a super easy parse json step and all that i've done here is provide the json schema of my document that i expect to get so that i can easily use those values later on in my workflow this document for my products is really basic it just has the product id and it has that quantity property here so then i can go into my condition step and i can do two things first i want to check the status code again the status code was parsed out of the body in the step above and i want to make sure that my status code is equal to okay was i able to find this document um and next i want to check the quantity so if quantity is greater than zero that's good means i have inventory to serve this request and i can go to the true path and i can create and update an item so again we're looking at our products container and i'm actually writing that same item back to cosmos db um i'm taking that that item id that i parsed in a step above and i'm also taking the quantity so you can see here we're using another expression giving to us by logic apps to do a simple subtraction so you can see it's really powerful to use cosmos db actions with built-in logic apps features to really easily build out a workflow without any code but what happens if i didn't have enough inventory to serve maybe i want to send an email so in this example i'm sending myself a sample email just showing what product id i'm talking about and what's the quantity remaining so to show an example of this workflow in action let's switch over to my cosmos tv account and here i have a bunch of orders in my orders collection let's go ahead and create a new order um just paste that in there oops let's not have copied correctly okay so now we have order 20 and let's go ahead and do one more order so i happen to know for this certain product product one that i'm trying to submit orders for there's only one quantity remaining so if we go back to our inventory demo and we look at all of the runs in the run history we should see two new runs here and you can see i've just received an email telling me that my quantity remaining is zero so yeah so i'll have to go and uh make sure that i've restocked the service always all these requests such a popular store um this shows you like the integration um really some table stakes features for logic apps really great integration with third party um you know sending an email for instance is really easy with no code but showing the power of some of our cousins to be triggers and actions um i want to mention a couple other actions that i didn't cover in this demo we also have the ability to query for documents using a sql query um that you can type right in as a parameter and you can also use those variables like i was showing the dynamic content um we also have the ability to delete an item and a really exciting action which is to create or update many items in bulk and this really contrasts with the single um create or update an item action which i showed in this demo because it is really targeted for high throughput scenarios so say you want to process hundreds or thousands of documents this bulk support is going to leverage the bulk capabilities of the sdk which is what the connector is running on under the hood and really give you the best um the best throughput that you can achieve there's one other thing that i wanted to mention about this connector and that's really just to highlight once again it's really built for scale so i'm going to click into my second workflow this workflow is similar but much simpler it just has a trigger i have an events database and an event container and then i'm going to be essentially copying those events that i've created into a new container called copy events um but what i want to show you about this i was running a sample console application earlier which just writes about a thousand documents a second into cosmos db so if we go into application insights we can actually see how many executions were um how many executions we had and really the performance how long each workflow is taking so here i'm going to add a couple metrics let's look for the event stream workflow count and let's add one more metric which is going to be the job execution duration and i'll just highlight this is one of the runs that i was doing earlier and i'll just highlight some key points so you can see i was inserting documents at about a thousand a second but of course the trigger batches those so you're not getting one execution per document it's going to process a bunch of them at one time um and you can see i had about 100 executions and each of them was relatively relatively fast so i hope that this excites you to try the new built-in connector um and thank you so much yeah that's really awesome i mean with the performance you're talking about there i mean you could really use this to kind of build like bespoke data migration or data loading uh yeah definitely types of connectors in there yeah and the trigger is actually built using the exact same extension that azure functions uses so you can expect a similar throughput and scale and copying collection migrating data is definitely one of the use cases that this now with logic apps on the hosting side do they have is there like t-shirt sizing for kind of the scale and how you can scale those up like say you get in there and you're like okay i think i want to see if i can go a little faster uh can you just easily kind of scale it up with no downtime yeah um so i actually don't know about the downtime aspect of it but there are definitely different sizes of logic app standard that you can provision so one caveat here this is for logic app standard there's also a consumption model which is more of a you know multi-tenant system for logic app standard you're kind of getting your own dedicated compute and your own app service plan so however long it would take to scale up a traditional app service plan is how long it would take you to scale up your logic app um yes but you can definitely scale up and down according to your needs okay cool well thank you everyone i think seranya had to drop off because um oh wait hold on we lost uh where is he there he is there we lost rodrigo but now he's back so all right well wow what a great show we went way over an hour but uh hey that's what happens when you're releasing lots of stuff right so uh all good stuff and thank you everyone for joining us this week and thank you everyone uh at home for joining us uh we hope you enjoyed the show uh next week i've got uh jeremy lichtness on uh jeremy runs uh all the entity framework stuff over in the dotnet team and he's gonna talk about all the cool new stuff for uh ef6 that's coming out for cosmos db so uh that should be fun join us we'll hear about all the new stuff coming out for uh for entity framework uh on cosmos and uh until then thank you everyone theo justine tim thomas deborah rodrigo and saranya hopefully back back asleep so i feel bad middle of the night uh where she's at so okay well thank you everyone see you all again thank you thanks all right thank you thank you [Music] [Music] you

Channel: Azure Cosmos DB

Views: 647

Keywords:

Id: RyTBPvBHHIM

Length: 71min 13sec (4273 seconds)

Published: Fri Nov 05 2021