WELCOME TO THE SESSION. IT'S VERY 
EXCITING TO SEE ALL OF YOU AT THE 
MICROSOFT IGNITE EVENT. BEFORE WE 
GET INTO THE CONTENT, A QUICK QUESTION. 
HOW MANY OF YOU ARE NEW TO AZURE 
COSMOS DB? HOW MANY OF YOU DEPLOYED 
STUFF ON AZURE COSMOS DB IN PRODUCTION? 
A FEW. GREAT. IT'S EXCITING. THE 
CONTENT HERE TODAY COVERS BOTH. 
IF YOU HAVE GONE ALL THE WAY FROM 
A POC TO PRODUCTION, I'LL SHARE 
SOME BEST PRACTICES THAT CAN PROBABLY 
HELP YOU A LITTLE BIT MORE. AND 
FOR THOSE OF YOU WHO ARE NEW IN 
THE AUDIENCE TO COSMOS DB, THE SESSION 
WILL COVER BEST PRACTICES THAT CAN 
GET YOU AHEAD IN YOUR IMPLEMENTATIONS. 
OKAY? JUST A QUICK INTRO ABOUT MYSELF. 
I'M SURYA NANDURI. I'M AN ENGINEERING 
MANAGER AT MICROSOFT. AT CORE SERVICES 
ENGINEERING AND OPERATIONS TEAM, 
WE BUILD, DEPLOY, AND MANAGE APPLICATIONS 
THAT RUN THE BUSINESS OF MICROSOFT. 
AND THESE APPLICATIONS ARE USED 
INTERNALLY BY THE EMPLOYEES AND 
ALSO BY OUR CUSTOMERS AND PARTNERS 
TO DO BUSINESS WITH MICROSOFT. WITH 
THAT, LET ME GET INTO THE CONTENT. 
TODAY, THE SESSION OBJECTIVES ARE 
THE THREE THINGS I WANT YOU GUYS 
TO TAKE AWAY. NUMBER ONE, HOW DO 
YOU MODEL YOUR COSMOS DB COLLECTIONS? 
AND SECOND, HOW DO YOU DO HORIZONTAL 
PARTITIONING TO SCALE OUT? THIRD, 
HOW DO YOU MAKE THE RIGHT TRADEOFF 
BETWEEN CONSISTENCY AND PERFORMANCE 
FOR YOUR AZURE COSMOS DB IMPLEMENTATION? 
WE'LL APPLY THESE CONCEPTS TO A 
REAL-WORLD EXAMPLE FROM OUR OWN 
LEARNINGS FROM THE PROJECT WE HAVE 
DONE, WHICH IS ENTERPRISE TIME TRACKING. 
SO, FOR THOSE OF YOU WHO ARE NEW 
TO AZURE COSMOS DB, A QUICK INTRO. 
A FEW THINGS THAT AZURE COSMOS DB 
PROVIDES IS, NUMBER ONE, TURNKEY 
GLOBAL DISTRIBUTION. SECOND, IT 
CAN HORIZONTALLY SCALE OUT, WHICH 
MEANS YOU CAN MOVE FROM SMALL AMOUNTS 
OF DATA TO LARGE REQUESTS AND FROM 
LARGE AMOUNTS OF DATA TO HIGH VOLUMES 
OF REQUEST. NUMBER THREE, IT'S A 
MULTIMODAL DATABASE, WHICH MEANS 
WE SUPPORT KEY VALUE, COLUMN FAMILY, 
DOCUMENT, AND GRAPH. ON TOP OF THIS, 
WE HAVE DIFFERENT APIS TO ACCESS 
THE DATA. AND TODAY, ALL THE BEST 
PRACTICES THAT WE SHARE IS GOING 
TO BE ON THE CORE SQL API THAT COSMOS 
DB PROVIDES. AND THE MAJORITY OF 
THE IMPLEMENTATIONS THAT WE RUN 
INTO WITH OUR CUSTOMERS ARE IMPLEMENTATIONS 
ON CORE SQL API. A LITTLE BIT OF 
BACKGROUND ON THE USE CASE THAT 
I'LL BE REFERRING TO IN TODAY'S 
PRESENTATION IS ABOUT TIME TRACKING. 
AND WE ROLLED OUT THIS APPLICATION 
TO THE ENTERPRISE SERVICES USERS 
OF MICROSOFT BASICALLY SERVICE EMPLOYEES 
THAT WORK ON CUSTOMER SITES, ON 
CUSTOMER PROJECTS. THEY LOG TIME, 
AND THIS TIME THEY LOG IS USED FOR 
BILLING. IF IT GOES DOWN, THE PROBLEM 
IS WE'LL NOT BE ABLE TO INVOICE 
OUR CUSTOMERS AND WE'LL BE NONCOMPLIANT. 
IT'S A MISSION CRITICAL SERVICE 
THAT WAY. WHY IS THIS A GOOD USE 
CASE FOR AZURE COSMOS DB IMPLEMENTATION? 
BECAUSE THE USER BASE IS GLOBALLY 
DISTRIBUTED. MICROSOFT IS A HUGE 
COMPANY THAT IS ACROSS THE WORLD. 
AND THERE ARE MANY DIFFERENT QUERY 
TYPES THAT THE APPLICATION HAS TO 
SERVE UP, SO IT'S A REALLY GOOD 
USE CASE. WITH THAT, LET'S DIG INTO 
THE DESIGN OF WHAT WE HAVE DONE. 
IT IS THE COST OF DOING AN OPERATION 
IN SIMPLE TERMS. HOW DO YOU DETERMINE 
THE TROOPER THAT YOU NEED FROM AZURE 
COSMOS DB? SIMPLE STEPS. NUMBER 
ONE, LET'S DEFINE IT AND I'LL WALK 
YOU THROUGH THE STEPS. IT IS MEASURED 
IN REQUEST UNITS. BASICALLY, IF 
YOU ARE SCALING UP IN A RELATIONAL 
DB SORT OF SCENARIO, YOU'RE EITHER 
BUMPING UP THE MEMORY OR THE CPU. 
WHAT COSMOS DB DOES IS IT ABSTRACTIONS 
ALL THOSE THREE AND GIVES YOU THIS 
LOGICAL WAY OF DEFINING OUR USE. 
THAT'S HOW YOU MEASURE THE THROUGHPUT. 
YOU CAN MEASURE IT AT TWO LEVELS. 
ONE IS AT DATABASE LEVEL AND THE 
OTHER IS THE PROVISIONAL LEVEL. 
IF YOU PROVISION AT THE CONTAINER 
LEVEL, THEN YOU HAVE MORE CONTROL 
OVER THE THROUGHPUT THAT YOU WANT 
THAT CONTAINER TO HAVE. OKAY? IT'S 
A DESIGN CHOICE THAT YOU CAN MAKE 
BASED ON WHAT YOU DO IN YOUR APPLICATION. 
SECOND IS IDENTIFY ACCESS PATTERNS. 
AZURE APPLICATION READ HEAVY, WRITE 
HEAVY. WHAT'S IT LIKE? IT'S VERY 
IMPORTANT TO KNOW THAT BECAUSE A 
LOT OF DESIGN DECISIONS ARE BASED 
OUT OF WHAT SORT OF PATTERNS ARE 
DATING AN APPLICATION. NUMBER THREE, 
IF IT IS A READ-HEAVY APPLICATION, 
MAKE SURE YOU UNDERSTAND THE QUERY 
PATTERNS. I WILL COVER PARTITION 
IN THE NEXT SECTION. YOU WANT TO 
KNOW WHAT ARE THE QUERIES YOU'RE 
RUNNING. WHAT ARE THE CROSS QUERIES 
YOU'RE RUNNING. WE'LL COVER THAT 
IN DETAIL IN THIS SECTION NEXT. 
LAST L LAST, UNLESS YOU RUN A POC, 
YOU WOULDN'T BE ABLE TO DETERMINE 
WHAT SORT OF THROUGHPUT YOU NEED. 
I HIGHLY ENCOURAGE YOU TO RUN A 
POC. ONE THING TO AVOID IS DON'T 
DO ANALYSIS PARALYSIS OF THAT DATA 
BECAUSE IN AZURE COSMOS DB YOU CAN 
ALWAYS COURSE CORRECT WITHOUT ANY 
DOWNTIME. CALCULATING THROUGHPUT. 
WITHOUT A POC, WITH A LOW TEST OF 
20, 000 USERS AND THEN 5, 000 APPROVERS 
WORLDWIDE, THE WORKLOAD IS, AS YOU 
CAN SEE, READ HEAVY. WHEN WE RAN 
THIS TOC, THIS IS WHAT WE GOT FROM 
COSMOS DB METRICS. BASICALLY, IF 
I EXPLAIN THIS OUT, THE Y-AXIS IS 
THE THROUGHPUT, AND THE X-AXIS IS 
THE DATE. MUCH OF THE THROUGHPUT 
IS AROUND THE 500 TO 1500 USE RANGE. 
THEN YOU SEE SPIKES WHICH GO UP 
TO 7500 RUS. WHAT DO YOU MAKE OUT 
OF IT? WHAT SHOULD BE THE THROUGHPUT 
IN RUS FOR PARTITION? ANY GUESSES? 
ANY OTHER GUESSES IN THE AUDIENCE? 
IT DEPENDS. OKAY. LET'S FIGURE OUT 
WHAT THE ANSWER IS. ALL ANSWERS 
ARE VALID, BUT WHAT IS THE MOST 
OPTIMAL ANSWER? LET'S FIGURE IT 
OUT. LET'S MAKE SOME DESIGN DECISIONS 
ON THE FLY, AND I'LL REVEAL THE 
ANSWER AT THE END OF THE NEXT SESSION. 
YOU SAW SOME TOWERS UPDATE IN THE 
GRAPH. LET'S ANALYZE WHY THOSE TOWERS 
ARE THERE AND WHY THOSE QUERIES 
ARE TAKING A LOT OF THROUGHPUT. 
YOU CAN ANALYZE TWO THINGS. ONE 
IS AZURE DIAGNOSTICS, WHICH IS BASICALLY 
OUT-OF-THE-BOX AZURE PROVIDED. IT 
HELPS YOU FIND OUT WHAT ARE THE 
QUERIES AND HOW MUCH R USE QUERY 
IS TAKING UP. DUE TO PII, YOU DON'T 
GET A MATCHED QUERY. APP INSIGHTS 
CAN GIVE YOU THAT BECAUSE THIS IS 
AT THE APPLICATION LEVEL. YOU CAN 
LOG WHAT SORT OF QUERY YOU'RE RUNNING 
AND THEN COUPLE THAT WITH AZURE 
DIAGNOSTICS TO SEE HOW MANY SO WITH 
THAT, LET'S ANALYZE THIS QUERY. 
SO THE QUERY THAT'S CONSUMING THE 
HIGH NUMBER OF AUDIOS IS ALL ENTRIES 
TO BE APPROVED. AS I SAID IN MY 
USE CASE, THERE IS SUBMIT TIME, 
APPROVALS FOR APPROVE TIME. SO IN 
THIS CASE, WHEN THE APPROVAL IS 
ASKING FOR ALL THE TIME ENTRIES 
THAT THAT PERSON NEEDS APPROVED, 
THAT'S TAKING A LOT OF AUDIOS. SO 
LET'S SEE HOW MANY AUDIOS THIS IS 
TAKING. SO IT'S TAKING ABOUT 959 
AUDIOS AT PEAK. AND ON AN AVERAGE, 
IT'S TAKING 50 AUDIOS, WHICH IS 
PRETTY HIGH. AND NUMBER OF REQUESTS 
EXCEEDING CAPACITY, AS I SAID THE 
CAPACITY AT 500 AUDIOS FOR THE POC. 
SO IT'S 180 QUERIES ARE EXCEEDING 
THE CAPACITY. AND IT EXCEEDS WHAT 
AGILE COSMOS DB DOES IS GOES NINE 
TIMES TO GIVE YOU THE RESULT BEFORE 
IT SAYS I CAN DO IT. AND THE QUOTE 
YOU GET IS HTTP 4429 WHEN IT EXCEEDS 
THE LIMIT. WE SEE A COUPLE ISSUES 
HERE. ONE IS BECAUSE IT'S TAKING 
A LOT OF RETRIES, IT'S POOR PERFORMANCE 
OF THE QUERY AND HIGH COST BECAUSE 
OF HIGH AUDIO CONSUMPTION. THAT'S 
WHY YOU SEE THE TOWERS UP THERE. 
HOW DO WE OPTIMIZE THIS? LET'S LOOK 
AT IT. AND THAT GETS INTO THE NEXT 
SECTION CALLED PARTITIONING. AND 
THIS WILL HELP US NOT ONLY SCALE 
OUT BUT ALSO REDUCE THE NUMBER OF 
AUDIOS SOME OF THOSE 
QUERIES ARE 
TAKING. SO LET'S LOOK AT THE DOCUMENT 
FOR THE USE YESTERDAY, WHICH IS 
A LABEL DOCUMENT, AND IT HAS CERTAIN 
ATTRIBUTES IN IT. I USE THE EMBEDDED 
MODEL HERE. THERE ARE TWO MODELS, 
EMBEDDED AND REFERENCING. YOU USE 
EMBEDDED WHEN IT'S A ONE-TO-ONE 
BETWEEN THE MAIN OBJECT AND THE 
EMBEDDED OBJECTS CALLED ASSIGNMENT 
DETAILS AND APPROVAL DETAILS. IF 
YOU HAVE ONE TOO MANY OR MANY TOO 
MANY, YOU USE REFERENCING. SO LET'S 
LOOK AT THE BEST PRACTICES FOR SELECTING 
A PARTITION KEY. HOW DO YOU DO IT 
FOR SCALING? NUMBER ONE, IT HAS 
TO BE UNIFORM, THE STORAGE. SO BASICALLY 
IF IT'S LIKE THIS FRONT ROW SEATS, 
RIGHT? IF IT'S UNIFORM, THEN IT'S 
BETTER FOR PERFORMANCE AND THINGS 
LIKE THAT. AND MAKE SURE THERE'S 
UNIQUENESS OF VALUE WHEN YOU'RE 
SELECTING A PARTITION KEY SO YOU 
GET THE MOST THROUGHPUT. THIRD, 
GOOD DISTINCTIVENESS AT ANY GIVEN 
TIME. SO THESE ARE THE THREE FACTORS 
WHICH YOU CAN USE TO SELECT YOUR 
PARTITION KEY. LET'S LOOK AT SOME 
OF THE CANDIDATES IN THAT LIST ELIGIBLE 
FOR PARTITION KEY. WE LOOK ADD SUBMITTED 
BY, SUBMITTED DATE AND ASSIGNED 
APPROVAL AS THE THREE PARTITION 
KEY CANDIDATES, AND WE RAN IT THROUGH 
THESE THREE DIFFERENT BEST PRACTICES 
THAT I JUST MENTIONED. SO IF YOU 
LOOK AT SUBMITTED BY, STORAGE DISTRIBUTION 
UNIFORMITY IS VERY HIGH. OKAY? BECAUSE 
IF YOU ARE PARTITIONING BY USERNAME, 
ALL THE DATA THAT THAT USER ENTERS 
IS IN THAT PARTITION, AND LIKEWISE 
FOR OTHER USERS ALSO. CARDINALITY 
IS VERY HIGH. IT'S UNIQUE. THAT 
DOES NOT CHANGE. NUMBER THREE, DISTINCTIVENESS 
AT ANY GIVEN POINT OF TIME IS HIGH. 
LET'S LOOK AT ANOTHER EXAMPLE. SUBMITTED 
DATE, STORAGE DISTRIBUTION IS NOT 
VERY UNIFORM. WHY? BECAUSE TODAY 
IT COULD BE A HIGH-TRAFFIC DAY. 
TOMORROW IN THE U. S. IT'S A WORKING 
DAY. IN INDIA, IT'S A HOLIDAY. SO 
IN THAT PARTICULAR PARTITION, YOU 
WOULD NOT HAVE DATA AND IT'S NOT 
UNIFORM ACROSS DIFFERENT DATES, 
RIGHT? SO IT'S LOW. SO GIVEN THAT 
AREA, WHAT WE SELECTED IS SUBMITTED 
BY BECOMES A BEST PARTITION KEY 
BASED ON THE BEST PRACTICES FOR 
SELECTING THE PARTITION KEY. LET'S 
SEE HOW COSMOS HAS THE DATAB BASED 
ON THIS PARTITION KEY. THAT'S HOW 
COSMOS DB DOES IT BASED ON THE USERNAME. 
BECAUSE I HAVE 27, 000 USERS, IT 
DIVIDES THE LOGICAL PARTITIONS INTO 
27, 000 PARTITIONS. COSMOS DB GAVE 
ME TEN PHYSICAL PARTITIONS. WHEN 
YOU RUN THAT QUERY, SELECT START 
FROM COLLECTION SUBMITTED. IT DIRECTLY 
RUNS ON THE SURIA COLLECTION AND 
THE RESPONSE TIME IS INSTANTANEOUS 
BECAUSE IT'S A DIRECT READ ON ONE 
LOGICAL PARTITION, OKAY? IT'S CALLED 
THE POINT QUERY. AND THE AUDIOS 
TAKEN FOR READ ARE ONE AUDIO FOR 
ONE KILOBYTE OF DATA. THIS IS THE 
FASTEST COSMOS DB CAN GET. SO LET'S 
SEE A SECOND EXAMPLE OF A CROSS-PARTITION 
QUERY. SO HERE A PROVER IS TRYING 
TO APPROVE ALL THE LABELS SUBMITTED 
WHERE HE'S THE APPROVAL. SO SELECT 
START FROM C WHERE ASSIGNED APPROVAL 
EQUALS SANDEEP. SO WHAT IS COSMOS 
DOING IN THIS CASE? IT RUNS THAT 
QUERY ON EVERY LOGICAL PARTITION 
TO FIND OUT WHAT ARE THE LABEL ENTRIES, 
THOSE ENTERED BY THOSE USERS WHERE 
THE ASSIGNED APPROVER IS SANDEEP. 
THE QUERY IS RUN ON 27, 000 LOGICAL 
PARTITIONS. THAT'S WHY YOU SEE AN 
AVERAGE AUDIOS OF 50 AUDIOS AND 
PEAK USAGE OF 959 AUDIOS BECAUSE 
IT'S RUNNING ACROSS 27, 000 LOGICAL 
PARTITIONS. SO WHAT DO YOU DO? SO 
LET'S SEE WHAT THE TOTAL AUDIOS 
CONSUMED IN THIS CASE IS BEFORE 
WE FIGURE OUT WHAT DO WE DO ABOUT 
THAT USE CASE. DOCUMENT RIGHT TAKES 
FIVE AUDIOS BECAUSE COSMOS DB REPLICATES 
ALL THE RIGHTS. AND TEN RIGHTS PER 
SECOND. SO TOTAL IS 50 AUDIOS. FOR 
ASSIGNED APPROVAL QUERY THAT WE 
JUST SAW, IT CONSUMES ON AN AVERAGE 
50 AUDIOS, AND IT'S 100 QUERIES 
PER SECOND. TOTAL IS 5, 000 AUDIOS 
THERE. AND THEN FOR THE POINT QUERY, 
IT'S ONE AUDIO FOR 500 QUERIES PER 
SECOND. SO 500 AUDIOS. IT IF YOU 
TOTAL IS UP, IT'S 5, 550 APPROXIMATELY 
AUDIOS. LET'S SEE HOW WE CAN OPTIMIZE 
THIS. SO I'LL INTRODUCE A CONCEPT 
CALLED CHANGE FEED. SO WE LOOK AT 
THE TOP QUERY, LOOK AT THIS. NOW, 
CROSS PARTITION QUERIES ARE OKAY 
IF THEY'RE SPACED OUT. IF THEY'RE 
TOO FREQUENT, IT WILL CAUSE HIGH 
NUMBER OF TOWERS LIKE YOU SAW. WHAT 
DO YOU DO? CHANGE FEED IS THE ANSWER 
FOR THAT. SO BASICALLY WHAT CHANGE 
FEED DOES IS -- SO THIS IS MY FIRST 
COLLECTION, WHICH IS THE LABEL COLLECTION, 
WHERE IT'S DIVIDED INTO 27, 000 
LOGICAL PARTITIONS. I DO A CHANGE 
FEED ON THIS. SO BASICALLY I READ 
THE EVENTS. I WRITE AN AGILE FUNCTION, 
AND FROM THOSE DOCUMENTS INTO ANOTHER 
COLLECTION CALLED APPROVAL COLLECTION, 
OKAY? AND THEN THE PARTITION KEY 
THERE IS ASSIGNED APPROVER. IN THE 
APPROVER COLLECTION, BECAUSE THERE 
ARE 500 APPROVERS, AZURE COSMOS 
DB, IT'S TOTALLY OKAY TO HAVE MORE 
PARTITION KEYS. THAT MAKES YOUR 
APPLICATION MORE SCALABLE. WE TALK 
ABOUT STORAGE BECAUSE WE'RE DUPLICATING 
DATA. DO NOT WORRY ABOUT STORAGE 
BECAUSE COST IN AZURE COSMOS DB 
IS VERY LESS COMPARED TO THE COMPUTE 
COST. YOU CAN USE THIS FEATURE CALLED 
TTL, TIME TO LIVE FOR DOCUMENT. 
THE DOCUMENT GETS DELETED AFTER 
ONE MONTH SO YOU CAN CLEAN UP THE 
STORAGE. SO IN THIS APPROVAL COLLECTION, 
THE PARTITION KEY IS ASSIGNED APPROVER. 
AND HERE, BECAUSE ASSIGNED APPROVER 
IS IN THE CLASS, IT DIRECTLY RUNS 
ON THE KEY AND BECOMES A POINT QUERY. 
SO YOU JUST CHANGED FROM A CROSS 
PARTITION QUERY TO A POINT QUERY. 
LET'S SEE WHAT THE COST ESTIMATE 
OF THIS IS. SO THE DOCUMENT RIGHT, 
WHICH DID NOT CHANGE FROM EARLIER, 
50 AUDIOS. NOW WHEN YOU'RE READING 
THE DOCUMENT FROM LABEL COLLECTION 
AND PUTTING IT INTO APPROVAL COLLECTION, 
THE READ IS ONE AUDIO AND THE RIGHT 
IS FIVE AUDIOS. THE READ IS ONE. 
WRITE INTO IS FIVE AUDIOS. A POINT 
QUERY FROM A CROSS PARTITION QUERY. 
ONLY ONE AUDIO CONSUMPTION. 100 
AUDIOS IS THE TOTAL. SUBMITTED BY 
QUERY REMAINS AS IT IS 500 AUDIOS. 
THE TOTAL YOU GET IS 710. SO YOU 
SAVED 8 TIMES THE NUMBER OF AUDIOS 
THAN WHAT YOUR DESIGN WAS PREVIOUSLY. 
5, 550, ALL THE WAY. YOU PAY FOR 
EACH AUDIO, AND YOU JUST SAVED A 
LOT OF MONEY. SO REMEMBER THE POP 
QUIZ? HOW MANY OF YOU GUYS HAD A 
AS THE ANSWER? OKAY. [LAUGHTER] 
SO THE CORRECT ANSWER IS SOMEWHERE 
AROUND A. ALL ANSWERS ARE CORRECT, 
BUT YOU NEED TO FIND THE RIGHT OPTIMIZED 
AUDIOS SO THAT YOU PAY LESS FOR 
BETTER PERFORMANCE. OKAY? SO LET'S 
LOOK AT ANOTHER CONCEPT CALLED CONSISTENCY 
LEVEL. AS I SAID, COSMOS DB PROVIDES 
GLOBAL DISTRIBUTION. HOW DO WE HAVE 
DATA AND MAKE SURE WE GET HIGH AVAILABILITY 
AND HIGH PERFORMANCE FOR OUR APPLICATION, 
RIGHT? MAKE IT BETWEEN CONSISTENCE 
AND PERFORMANCE. READ REGION IS 
SEVERAL. HERE'S THE PARTITION KEY 
SUBMITTED BY. IT'S VERY IMPORTANT 
TO UNDERSTAND WHAT YOUR REQUIREMENTS 
ARE TO DETERMINE THE RIGHT CONSISTENCY 
LEVEL. SO THE REQUIREMENTS FOR OUR 
APPLICATION ARE USER ALWAYS GETS 
THE LATEST WHEN YOU'RE SUBMITTING 
AND MAKING EDITS ON YOUR LABEL, 
YOU WANT TO MAKE SURE YOU'RE EDITING 
THE LATEST COPY AND NOT AN INCONSISTENT 
COPY. WHEN YOU'RE APPROVING, YOU 
ALWAYS APPROVE THE LATEST EDITED 
LABEL RATHER THAN APPROVING AN OLD 
COPY. SO THOSE ARE A COUPLE OF REQUIREMENTS. 
AND THIRD IS BECAUSE WE ARE IN AN 
ENTERPRISE SORT OF A SITUATION, 
WE HAVE DIFFERENT THINGS ON OTHER 
ENTERPRISE SYSTEMS. SO LET'S LOOK 
AT OUR POC RESULTS. COSMOS DB OFFERS 
CONSISTENCY LEVELS FROM STRONG ALL 
THE WAY. AND IN BETWEEN IT OFFERS 
THREE EXTRA CONSISTENCY LEVELS. 
LET'S GO WITH STRONG. WHEN WE PUT 
STRONG, HERE THE AVAILABILITY IS 
LOW BECAUSE EACH TIME YOU WRITE, 
IT HAS TO GO REPLICATE INTO ALL 
REGIONS AND AFTER ALL THE REPLICATION 
IS DONE, THAT'S WHEN IT SAYS IT'S 
DONE AND HERE'S THE NEW COPY OF 
THE DATA. SO THAT'S NOT VERY HIGHLY 
AVAILABLE. AND SECOND IS PERFORMANCE-WISE, 
IT'S SLOW. SO SLOW RESPONSE TIMES. 
WE'RE NOT TALKING ABOUT A HUGE NUMBER 
OF SECONDS AND MINUTES HERE, COMPARED 
TO THE OTHER CONSISTENCY LEVELS. 
IT'S A LITTLE MORE SLOWER. AND THE 
OTHER THING IS IT'S TWICE AS EXPENSIVE 
THAN CONSISTENCY. IT'S A COST FACTOR. 
SO LET'S LOOK AT READING K VERSIONS 
OF DATA WHICH IS LATE OR -- SO BASICALLY, 
AGAIN, WE LOOKED AT THIS OPTION. 
BUT THE CON HERE IS STILL AVAILABILITY 
IS LOW. PERFORMANCE IS LOW. AND 
THE COST IS ALSO VERY HIGH. HERE, 
WHEN YOU'RE DOING A WRITE, AZURE 
COSMOS DB GIVES YOU A SESSION TOKEN. 
IF YOU'RE READING WITH THE SAME 
SESSION TOKEN, THEN YOU'LL GET THE 
LATEST WRITTEN COPY. SO WITH THAT, 
WHAT WE COULD DO IS THE SYSTEM GUARANTEES 
THE LATEST LABEL RECORD. THAT'S 
WHAT THE APPROVER WANTS TO APPROVE. 
SO THIS WORKS VERY WELL FOR US. 
FROM A COST PERSPECTIVE, THIS IS 
TWO TIMES LESS CHEAPER THAN -- LESS 
EXPENSIVE THAN THE STRONG CONSISTENCY 
LEVELS. FOURTH, CONSISTENT PREFIX. 
BASICALLY COSMOS DB GUARANTEES THE 
ORDER IN WHICH THE VERSIONS ARE GIVEN TO THE READ. 
BUT IT DOES NOT REALLY WORK FOR 
US BECAUSE APPROVER HAS TO ALWAYS 
APPROVE THE LATEST COPY OF THE DATA. 
SO IT DOESN'T REALLY WORK FOR US. 
EVENTUAL, COSMOS DB DOES NOT GUARANTEE 
THE ORDER. AGAIN, THIS DOES NOT 
WORK FOR US. YOU HAVE TO HAVE THE 
LATEST COPY OF THE LABEL RECORD. 
SO WITH THAT, WHAT WE SELECTED WAS 
SESSION CONSISTENCY. AGAIN, FROM 
AN AVAILABILITY POINT OF VIEW, WE 
GOT HIGH AVAILABILITY. FROM A COST 
POINT OF VIEW, IT'S BETTER. AND 
THIRD FROM A PERFORMANCE POINT OF 
VIEW, IT'S FASTER. SO THAT'S HOW 
YOU SELECT BASED ON YOUR DATA LOAD, 
YOUR PATTERNS, YOUR REQUIREMENTS. 
YOU CAN SELECT WHICH ONE WORKS FOR 
YOU. 80 OF OUR CUSTOMERS AND USERS 
USE SESSION. BUT DATA SITUATIONS 
WHERE YOU WANT TO USE OTHER CONSISTENCY 
LEVELS. AND HERE THE METRICS AND 
SLAS FOR OUR APPLICATION. 27, 000 
USERS ON IT. AZURE COSMOS DB 99TH 
PERCENTILE, WHICH IS SUPER AWESOME. 
5/9 AVAILABLE, WHICH IS THE BEST 
OF ANY SERVICE ON AZURE, SO IT'S 
AWESOME. AND FOR OUR APPLICATION, 
THE RESPONSE TIME IS LESS THAN 2 
SECONDS BECAUSE WE ARE RUNNING ON 
THIS WORLD-CLASS AZURE COSMOS DB 
INFRASTRUCTURE. AND THE COST SAVINGS 
ARE 50 COMPARED TO OTHER IMPLEMENTATION. 
SO WITH THAT, YOU GUYS WANT TO SEE 
A LITTLE DEMO OF AN APPLICATION? 
AND THE COOL THING IS WE'RE LAUNCHING 
THIS AT THE IGNITE FOR ALL OUR USERS. 
ANY VOLUNTEER ON THE AUDIENCE ON 
WHO CAN HELP ME LAUNCH IT? THERE'S 
A GOODIE. COME OVER. ALL RIGHT. 
WHAT'S YOUR NAME, SIR? ASPEN. FANTASTIC. 
IT'S A MOBILE APP, SO LET ME OPEN 
THAT UP FOR YOU. GREAT. SO THIS 
IS THE HOME SCREEN THAT USERS GET. 
BASICALLY IT'S SAYING, HEY, MY NAME 
IS , RECOMMENDED LABEL ENTRIES FOR 
YOU BASED ON HISTORICAL LABEL ENTRIES 
I'VE MADE. HERE'S THE MEETINGS AND 
EVENTS. BASICALLY YOU CAN ENTER 
TIME AGAINST THE PROJECTS, WHICH 
IS THE MCS TAG HERE. AND NONPROJECTS 
LIKE HERE. WE JUST ENTERED A 20-MINUTE 
SESSION. SO LET'S ENTER 20 MINUTES. 
LET'S CLICK THIS HERE. DO THE HONORS 
OF DOING AGREE AND SUBMIT. AND THERE 
YOU GO. AND GOT THE SAME WI-FI CONNECTION 
AS ALL OF YOU HAD. THE LABEL IS 
SUBMITTED SUCCESSFULLY. THIS MORNING 
I ATTENDED SATYA'S KEYNOTE. OOPS. 
OH, MAN. THAT WAS A BUMMER. WE'LL 
DO IT AGAIN, ASPEN, OKAY? SO HERE'S 
THE MOBILE APP. IT BASICALLY SAYS 
THE MASS NAME IN THE APPLICATION. 
HERE ARE THE RECOMMENDED LABEL ENTRIES 
FOR YOU. SO IF YOU'RE ATTENDING 
A MEETING EVENT HERE, WE'LL CLICK 
THIS. IT'S A 20-MINUTE SESSION. 
SAY YES. AND THEN DO THE HONORS 
AGAIN. THANK YOU, ASPEN. AND BOOM. 
LABEL GETS SUBMITTED. SO THAT'S 
WHAT OUR SERVICES USERS ARE MOBILE. 
SO IT'S A VERY HANDY APPLICATION 
THAN THEM. IT'S A DAILY ACTIVATE 
THEY NEED TO DO. THANK YOU FOR HELPING 
ME LAUNCH. HERE'S A SMALL GOODIE 
FOR YOU. THANKS, ASPEN. APPRECIATE 
IT. [APPLAUSE] SO WITH THAT, HERE 
ARE A FEW RESOURCES ON AZURE COSMOS 
DB THAT YOU CAN LOOK UP. IT HAS 
PRACTICAL EXERCISES, LABS, A LOT 
OF DOCUMENTATION AND SOME CASE HISTORIES 
THAT YOU CAN GO THROUGH TO LEARN 
MORE ABOUT AZURE COSMOS DB. AND 
STOP BY OUR BOOTH . WE ARE THE ENGINEERING 
TEAM. AND GO TO IT SHOWCASE. THERE 
IS A WHITE PAPER WRITTEN ON HOW 
WE'RE DIGITALLY TRANSFORMING IT 
IN MICROSOFT. IT'S A VERY GOOD READ. 
I ENCOURAGE ALL OF YOU TO GO THROUGH 
IT. THANK YOU FOR ATTENDING THE 
SESSION. PLEASE EVALUATE THE SESSION. 
YOU SHOULD GET A NOTIFICATION ON 
YOUR MOBILE APP. YOUR FEEDBACK IS 
VERY IMPORTANT TO MAKE SURE WE CONTINUOUSLY 
IMPROVE. THANK YOU, AND I'LL BE 
ON THE SIDE STAGE HERE IF YOU HAVE 
ANY QUESTIONS ON AZURE COSMOS DB 
THAT I CAN HELP ANSWER. THANK YOU 
FOR BEING A WONDERFUL AUDIENCE. 
