Caching for Performance with Amazon ElastiCache and Amazon DocumentDB - AWS Online Tech Talks

Key Takeaways

hi everyone thank you for joining us today to discuss caching for performance with amazon elastic cache and amazon documentdb my name is cody allen and i'm a documentdb specialist solution architect with aws and joining me today is zach gardner a senior elastic cash specialist essay zach's going to be walking us through a demo later on in this session but we'll start off talking about what are discussions going to be about today we're going to dive deep into modern applications and databases describing how the development landscape has changed to really focus on choosing the right tool for the right job a theme that's going to come up a lot after that we'll jump into purpose-built databases on aws and then go into the architecture of both amazon elasticache and amazon documentdb this is going to help show how these services were purpose-built for the cloud to overcome challenges of traditional databases i'll discuss considerations for this architecture before giving you an overview of the demonstration we're going to be showing you zach's going to walk us through that demonstration on how you can utilize this architecture in a real world scenario and we'll finish off with a q a session we do have chat moderators that are going to be watching for your questions so please feel free to pop those questions into chat at any time or you can save those questions at the very till the very end and we'll answer them then but let's start off with discussing modern applications and databases today developers are building highly distributed and decoupled applications aws is helping them build these in the cloud by using multiple aws services to handle scale performance and manageability and to understand why developers are decoupling these applications we need to understand how we got here now if we go way back mainframes were the predominant way of building apps the data was on the mainframe and if we needed that data well we just went straight there and this lasted until we got those client server applications and this really changed the way applications were built applications started become more distributed in nature however that underlying data model was predominantly structured and the database was often a monolith then the internet arrived and life was awesome and as a result we started seeing these three-tier application architectures emerging client and application code became even more distributed however that underlying data model was still predominantly structured and that database remained a monolith well what's changed if you fast forward to today the microservice architectures are how applications are built in the cloud and microservices have finally reached the database this is going to allow developers to do what they do best breaking apart those large applications into smaller services and again pick the right tool for the right job developers want to avoid a single overburdened database that has a single storage engine and a single compute engine trying to handle every single access pattern and these expectations have resulted in data management systems with specialized storage and specialized compute layers optimized for their given use case or their workload and this is so a developer never has to trade off the functionality performance or scale on top of this what we've seen over the last few years is that more and more companies are starting to hire this technical talent in-house to take advantage of the cloud there's this huge wave of technological innovation that the cloud is providing and these builders are not building in those monolithic ways of the past but with these microservices where they compose different elements together using that right tool for the right job all of this has led to a highly distributed loosely coupled application architecture that's powering the most demanding workloads in the cloud the expectations for builders as well as the end users of today's applications is really different the way it used to be the latency requirements are much lower and they're expected to be able to handle millions of transactions per second with millions of people using the app at the same time businesses are expanding into new localities to reach new customers and they're capturing more data about their customers to either improve existing products or sell new products and as we have more devices connecting we see more and more connections hitting these applications up to billions of devices connecting to the cloud and because of this businesses can invest millions of dollars in hardware and licenses up front and hope they'll be successful that that model just isn't realistic anymore instead they have to hedge their successes by only paying for what they use without capping how much they can grow all of these dynamics combined have changed the way businesses build applications and these modern applications have wildly different database requirements which are way more advanced in nuances than simply running everything in a relational database we used to throw everything on relational databases it could handle the reporting it can handle the etl we would even throw code at our databases by running functions and stored procedures even creating our own cl clrs common language runtimes and dlls to perform that but we don't do that anymore again it's that right tool for the right job so why are we considering purpose-built databases put simply we need that scale we need that performance and we need that availability it provides great thing here is aws has purpose-built databases to meet these requirements thinking back to the mainframe and monolithic databases the database landscape has changed much like our developers are creating microservices specific for their different flavor or code we're starting to see different flavors of databases no longer is relational the only category and we have to shove the square block into the round hole so to speak now we have key value stores and we have document databases we have in-memory databases time series and ledger databases now aws is going to offer purpose-built database solutions for each of these types so if you're running an on-prem rdbms system well you can run that on aws with rds or even move to a fully managed service like aurora you can take advantage of neptune that makes it easy to build and run apps that work with highly connected data sets but today as you can tell by the title of this session we're going to be focusing on these two amazon document db and amazon elastic cache now amazon documentdb with mongodb compatibility is a fast scalable highly available and fully managed document database service that's going to support your mongodb workloads the key thing here is it was designed from the ground up to give you that performance scalability and availability you need when operating those mission-critical mongodb workloads at scale with documentdb the storage and compute layers are completely decoupled from each other that means that i can scale each of them independently i can also increase read capacity to millions of requests per second by adding up to 15 low latency read replicas within minutes regardless of the size of my data we're implementing the apache 2.0 open source apis by emulating responses that a mongodb client expects from a mongodb server well what does that mean that means that you can use your existing mongodb drivers and tools with documentdb and by using the same tools and drivers that mongodb provides documentdb makes migration seamless with zero to minimal code changes and near zero downtime we also have features like global clusters that allows you to build globally distributed applications that are resilient to regional failures and as a managed service we're removing all that undifferentiated heavy lifting that means that you can focus on what matters for your business and this is going to promote your innovation that's required to stay relevant today documentdb is secure it complies with various iso and pci dss standards and we have a global presence across 16 aws regions and we're continually adding more by listening to our customers and building what they want documentdb is designed for four nines of availability we're replicating six copies of your data across three aws availability zones and since it's all running on aws we get native integration with other aws services like cloudwatch and cloudtrail secrets manager and many more we'll we'll dive a little bit deeper into that here in just one second now amazon alaska cache that's going to offer us fully managed redis and memcached that means that you can seamlessly deploy run and scale these popular open source compatible in-memory data stores amazon alaska cache for redis which is what we're going to be focusing on today is a blazing fast in-memory data store that's going to give you that sub millisecond latency to power those internet scale real-time applications it's all built on open source reddit and it's compatible with redis apis well again what does that mean just like documentdb can use those existing mongodb tools and drivers elastic cache for redis is going to work with your redis clients and uses the open redis data platform to store your data that means that your self-managed redis applications can work seamlessly with elastic cache without any code changes now you can build those data intensive apps and improve the performance of your existing apps by retrieving data from high throughput and low latency in memory data stores stated simply amazon alaska cache is going to play a very unique role in our purpose-built data strategy and that it's about working side by side with document db it's really straightforward you add a cache for that dramatic performance enhancement think of elastic cache as the first responder for those application data feeds taking a lot of pressure off documentdb while turbocharging its performance now we do need to point out that the architecture that we're going to show you today is a very specifically designed solution before implementing elasticache in front of your documentdb clusters it's very important that you understand your workloads while having a side cache can improve your query response time your workload and your query patterns is ultimately going to help you decide if this is the right architecture for you because it's not going to be the right architecture in every situation for example if your workload includes the ability to do uh a lot of ad-hoc queries across multiple key value pairs so think of a customer portal where your customer can search by one or many of the key values stored within a documentdb document utilizing documentdb's buffer cache via direct connection from the application would be a well architected solution and additionally you can continue to use documentdb to handle your aggregations via its rich set of supported apis and operators although alaska cache is going to send any cache miss queries to the target database having your application connect directly to document2db to retrieve the requested data can avoid unnecessary steps and we'll we'll talk about the different caching techniques in a second that will help illustrate that point and since you're utilizing the buffer cache to hold your working set within documentdb you still get very fast query response your application so ultimately you need to decide if this is going to work for you uh you need to determine is your workload read heavy or right heavy today's demo is going to illustrate a workload that's read heavy where users are performing the same query multiple times if your workload is also incorporating heavy write traffic adding an extra layer via last cache may decrease performance by adding additional steps ultimately slowing down that customer experience but again the point here is know your workload know where this is going to improve your situation or maybe it's not quite the right architecture and of course if you have any questions about that or need help you can reach out to your aws count team let's jump into the service architecture of amazon document db to understand what's doing behind the scenes now since your applications can leverage the same mongodb drivers you currently use that also means you take advantage of connection parameters like read preference in this first example we're going to see what it looks like when your application uses a read preference of primary for those read after write strong consistency results now our best practice when using documentdb is to use a secondary preferred read preference and that's so that your primary can focus on doing all the rights while those replicas can do the heavy lifting of reads but you are able to connect however your application needs by specifying that read preference so here we can see our applications doing a simple find operator against our collection to find this one document well when the documents that your application needs are located within the working set in the buffer cache they're going to be served from memory documentdb is going to return those documents immediately from the compute layer and it never has to reach into that distributed storage volume well now let's talk about our preferred method of using secondary preferred for that read preference again this is going to send all those reads to the read instances and only send reads to the primary if all the other replicas are unavailable this is going to really open up that primary to just handle those rights and be extremely performant we have the same situation here the documents are in the working set of that replica so there's no reaching into that distributed storage volume it's returned immediately to that application layer but what happens when our find filter changes and now we need a document that isn't in memory well the compute instance now has to reach back to that disk and retrieve the requested document this is also what happens when you perform a collection scan against documentdb due to a missing or inefficient index if it cannot find the answer if it cannot find that document in memory it's going to have to reach back into that storage layer now documentdb is using a read quorum of three on that storage volume and this is part of our high availability default architecture that gives you those six copies of your data across three availability zones so even if an entire availability zone was lost on the storage layer you'd still have enough copies of your data to continue reading while that a-z is recovered in the background so here the storage instance or the storage layer is returning those docs back to the compute instance the important thing to point out here is that one of the dimensions for pricing with documentdb is i o operations so every time that your compute layer has to reach into storage there's going to be a charge associated to that an i o read operation is eight kilobytes and an i o write operation is four kilobytes so again if we don't fit the documents that we need within our replica within the working set there's going to be a cost to that both with performance because reading from disk is slower than reading from memory and through a billing mechanism for those i o operations finally our compute instance has that data and it can return that document back to the client now let's switch gears and talk about the service architecture for amazon elasticash now when you're building a distributed application we want to achieve that low latency and scalability we've already seen how documentdb solves these requirements by utilizing instance memory that buffer cache for your working set and adding up to 15 replicas to help scale reads elasticash is going to take that concept further by giving you that blazing fast in-memory data store with that sub-millisecond latency we'll walk through specifics on how to implement this architecture here in a second but from a high level your applications are going to leverage less cash to access the data in a particular structure or view to simplify that data retrieval and increase application performance now depending on your workload this can also help with cost as we can scale elastic cache to handle those extremely high repetitive reads instead of scaling out documentdb with more replicas we'll double click on that here in just one second and you're also going to get that optimized key value index lookups based on that in memory microsecond latency now the first casting method that we'll look through with the last cache is right through caching here data inserts or updates are written to both the cache and the database the advantage here is that because the data in the cache is updated every time it's written to the database the data in the cache is always current there will be a penalty though a right penalty versus a read penalty because every write involves two trips we have to write that data to the cache and we also have to write to the database and that's going to add some latency to the process but end users are generally more tolerant of latency when updating data than when reading or retrieving data there's this inherent sense that an update is more work and it's going to take longer because of that now the disadvantage here is if you spin up a new node whether it's due to a node failure or you're scaling out there's going to be missing data and that data is going to continue to be missing until it's added or updated on the database now you can minimize this by implementing architectures that put lazy loading with right through and we'll talk about lazy loading here in just one second but just understand that you will have to redesign your architecture based on those requirements now there's also cash churn and what i mean by that is most data is never read which could be a waste of resources since you're always writing it no matter what it's not guaranteed that it's always going to be read now in today's demo we'll focus on lazy loading or read through caching and in this process we're doing three different things the first thing is the application's going to check the cache for results and if it has a cache hit then elastic cache is going to return that result back however if there's a cache miss and the last cache does not have that information the application is going to go to the source to get it and then ultimately update elastic cache with that new data now the advantage here is because most of the data is never requested lazy loading can avoid that situation we just talked about where we're filling up the cache with data that isn't needed and if a node fails and is replaced by a new empty node your application is going to continue to function although there will be some increased latency there because as requests are made to the new node each cache miss results in a query of the database and at the same time the data copy is added to the cache so that those subsequent requests are retrieved from the cash now the disadvantage here is if there is a cash miss penalty each cash miss results in three trips we have to do an initial request for the data from the cash then we have to request the data from the database because it's not in the cache and then we have to update the cache for those new results and these misses can cause a notable delay in data getting back to the application additionally the data is only written to the cache when there is a cache miss that means the data in the cache can become stale and we'll talk about techniques to deal with that here in just one second and this is occurring because there's no updates to the cache when data is changed inserted or updated like we we talked about with the right through caching so just a brief comparison of the two strategies lazy loading is going to be that read through where right through is going to be on inserts and updates there are cash miss penalties on lazy loading because we have to do those three trips if it's not there whereas the right latency is always putting those new inserts and updates into cash and because of that the data is never still with right through whereas data can get scale still with that lazy loading let's talk about considerations why would i do this where does this make sense and what kind of workloads and architectures will i do this for well from a compute layer we can leverage elastic cache to reduce the number of connections to documentdb now documentdb has limits and quotas around the number of cursors and connections can handle on the instance level for example at the time of this recording uh our r524 xl instances can handle up to 30 000 connections per instance it's a lot right but if you think about an event where you a situation where you have an auto scaling event you're probably adding more ec2 instances you're adding more containers you're you're adding more resources to eks and ecs more more more containers to handle more customer connections that are reaching back to your documentdb cluster now there are going to be some situations where you might be using a driver that's not using connection pooling efficiently it's not using existing connections it's opening up new ones or you haven't connect you haven't capped the number of connections a connection pool can made can make on that container and in those kind of situations especially during a huge auto scaling event you can run out of connections very very quickly but with alaska cache in front you can offload those queries covered in the cache to the caching layer without ever connecting to documentdb so that means based on your workloads because you have fewer connections and queries hitting your compute layer there might be an opportunity to resize your instances to a smaller instance type and i'll double click on that here in just one second when we talk about network we focus on the time it takes to get our application the document it needs to fulfill the query by leveraging elastic cache in front of documentdb you get that sub millisecond latency and you also can leverage those redis clusters with replication to distribute the workload you're also going to get cash control with less cash you only cash the subset of data that you need so instead of cashing the entire document elastic cash gives you the ability to fine-tune the data that's being returned so if you have a subset of hot data such as content that's suddenly really popular you can improve your customer experience by only returning that smaller subset of data quicker than you would return a larger data set the name redis actually means remote dictionary server and a dictionary is a general purpose data structure for storing a group of objects as you can see redis supports a full range of data structures at the very bottom here we have bitmaps and bit fields and for today's demo at the very top we're going to be focusing on strings but this again focuses on the need to understand your data characteristics and what's important to return to your customers redis is going to help with those known repetitive query patterns for desired key value pairs it's up to you to define upfront what the important or hotkeys are in your document db collections so that elastic cache can return those the other added benefit though is that you can control what can should be returned and even what can be removed from cash so although you need to be sure and define upfront what keys are important to return you also have the granularity to control what's in the cache and what can be removed finally from a cost perspective you could potentially decrease your i o operations in documentdb by serving these repetitive and similar queries from the caching layer i'll give you an example let's say that you have profiler enabled on your document db cluster and profiler is going to store any long-running queries into cloudwatch so you can review those you can see what the query was and what the execution plan and where was doing an index scan versus versus a collection scan and let's say that you've identified a slow running query that's doing a collection scan now remember when we were talking about the architecture of document to be earlier a collection scan is going to hit disk it is not going to be served by the compute layer it has to reach into disk which means i o operations well elastic cache can help in this situation by serving the results of that collection scan query up front while you focus on creating your index on documentdb avoiding repetitive collection scans so instead of all these applications hitting hundreds thousands of times even all doing this repetitive collection scan using ios elastic cache can offload that and serve it through the cache and like i mentioned earlier less connections and less resource consumption on your documentdb cluster can change your architecture size requirements you could potentially scale down your instances from maybe an r54 xl to an r5 to excel and you might even be able to scale down the number of instances that your document db cluster is using additionally both document db and elastic cache allow you to go global now with documentdb you can leverage the recently released global clusters to help with disaster recovery and even data locality since the data is replicated in near real time global clusters allow you to be up and running in a new region in less than a minute if a regional outage occurs and since that replication is offloaded to the storage layer there's going to be little to no impact to your application performance since the applications connecting to the compute layer up front so that means that you can leverage those low replica lags of less than one second to even utilize those secondary clusters to perform local reads letting you build that globally distributed application similarly with global datastore from elasticache you can create cross-region read replica clusters that give you the low latency reads and disaster recovery across aws regions when you create a global data store in elasticache it's going to automatically replicate your data from the primary cluster to the secondary cluster the last cache then sets up and manages that automatic asynchronous replication of the data between the two of them a global data store can help increase the responsiveness of your application by serving those low latency geo local reads across aws regions and by pairing these two services together we can further improve that customer experience by globally reducing latency to access data additionally if you needed to expand to a new region where maybe doc documentdb wasn't yet available you could leverage global data stores from elasticash to serve up hot data in a region where your customers are and that it is available now both elastic cache and documentdb give you integration with other managed aws services that can help you achieve those security compliance or administration needs cloudwatch is going to give you the ability to see what's going on in your clusters things like cpu usage freeable memory network allocation specific to elastic cache you have a simplified way of seeing cache hits and cache misses and with documentdb you can see things like your read iops and right iops in both cases you get to monitor replication lag in your cluster and total number of connections i already mentioned with documentdb the ability to enable profiler to view those slow running queries but you can also enable auditing which lets you see those ddl events and from there you can create your own metrics to watch and learn on for example if you want to see when you have a high number of failed logins or anytime somebody's created a database you have the ability to do that through cloudwatch and all aws services utilize cloudtrail this is something you can't disable so any api calls made to these services whether by sdk cli or console those are going to be tracked here additionally both elastic cache and documentdb can leverage secrets manager to safely store database credentials instead of embedding those into the application either through an environment variable or through a local config file previously if you were going to rotate your credentials you had to invest time and update each one of your applications with those new credentials after you did that you would go distribute your updated application and if you had multiple applications that were sharing those credentials and you missed updating one of them the application failed and you had to start over again and because of that risk many customers choose not to regularly rotate those credentials which is effectively substituting one risk for another you don't want to do that but with secrets manager you utilize im policies that control access to document db and elastic cache and allows your applications to connect lambda is going to allow us to run that serverless code and it plays a lot of parts in integrating these databases with other services so for example lambda can run as an action to a cloudwatch alert such as adding another documentdb instance to our cluster when we see active connection spike or we know that we could use another replica lambda can go do that for us or lambda can even scale out our redis cluster to add more shards it can take care of these expansion jobs that we need lambda is also going to be utilized by secrets manager to do those credential auto rotations we talked about either on a preset schedule or on demand and finally the the most obvious one you know lambda can run our application code for us without the need for instances at all using those im roles and policies we can give our lambda code the limited access it needs to reach to elast cache and those documentdb clusters let's shift over and talk about today's arc uh architecture what zach's going to be showing us now in today's demo we're going to be looking at an application that allows users to search a movie database for different key value pairs zach's going to show how a user could search for a movie by its creation year for example through a rest api client to the application engine that application engine is going to process that api request and retrieve the json document that holds the movie date details from the last cache layer if there's been a prior request for that movie well that's going to be served by elasticache if not the application engine is going to query documentdb and return that requested document back to the application again as a json document then the application will cache a copy in the last cache to speed up the response time of any subsequent request for the same movie the demo will be using that caching technique we talked about earlier lazy loading or read through caching it's going to illustrate how last cache and documentdb perform together for different query complexities we'll start off looking at a relatively simple query this query is actually doing an index scan on documentdb because it's covered by the index it fits in a working set it can be served out of the buffer cache but what we're doing here is giving you an example of how elastic cache can help if there's a huge burst of clients all requesting similar data returned by this very simple query next we'll increase the complexity we'll query on multiple fields one that's indexed and one that's not again these can be handled by documentdb but alaska cache is helping some of the more intensive execution plans remember that elastic cache is not actually performing the logic that documentdb cluster is instead it's matching on the similar queries to return the results that means that even with elastic cache in front of documentdb you can still reach back to documentdb and do those ad hoc queries that you need finally we'll increase the complexity by performing a regex lookup against an index field documentdb just like before is going to utilize an index for this search because we're passing along that hint operator in each of these scenarios we'll be able to see where we have cache hits that'll ask cash's handling and cache misses that go directly to documentdb and what's really cool about this the thing that gets me most excited about it is zach's gonna show us what that customer experience is like we get to see the response time for both those cache hits and misses to truly understand and appreciate that sub millisecond latency i will hand it over to zach now to start walking us through our demo thank you so much cody and thank you all for joining us during this webinar as mentioned my name is zach i work with the amazon alaska specialist team here at aws and i'm excited to present a demonstration which speaks to the value of introducing caching specifically on amazon alaska for redis into your architecture so we'll look at a few examples thank you cody for looking through some of the queries that we're going to model as part of our interactions between amazon documentdb and amazon elastic cache and i've built a small test harness which is responsible for making a series of calls to the two databases data stores in order to support that caching use case so let's transition over there here we can see just a brief demo application as i mentioned that is built in order to proxy calls between documentdb and amazon alaska cash and when setting up a caching strategy it's important to understand what are the dimensions of your data in order to benefit from having calls to a cash right there might be situations where the data changes so frequently that the overhead of introducing a cache isn't worthwhile but there are definitely other situations where you're repeatedly reading a series of information that can drastically be improved in terms of latency as well as to offload resources and calls to your primary data store so in our example we have amazon elastic ash as that in memory low latency layer in front of amazon document db while allowing documentdb to focus on the value-added work such as processing the queries and retrieving data in a variety of forms and fashions so as we look at some of the dimensions to consider in our caching strategy the first is a cash ttl so we talked about cash churn for instance and how if i write something to the cash there's a good chance that i'm going to want to retrieve it in order to gain some of those performance benefits now when i'm speaking with customers and they say well the ttl of the data is only one second or two seconds meaning once i retrieve it from the datastore documentdb in this case i only want it to live there for one or two seconds and the likelihood that i'm going to call that information is relatively low now of course understanding the dynamics and characteristics of your data it will start to inform which data access patterns repeatedly serve relatively static information and would benefit from that caching layer so for our use case here we'll set a cache ttl meaning time to live for about 30 seconds the next dimension is how much data do i really want to store in my cache at any given time and on amazon elasticash for redis we can support upwards of over 300 terabytes of data of in-memory storage in your cache if need be but here it's helping us maintain a ratio between the number of different queries we want to call and the total number of calls so think of this as a ratio in terms of how variable are the different queries that are being called if i need to store a thousand different queries at a time i need to store 5000 different queries at a time that will impact the amount of in-memory storage i need on amazon elasticash so as mentioned we can scale to reach extremely high volumes of data but for our use case here today will settle on maybe 400 different queries and finally as you look at the request rate so as i put items in my cache let's say we want to keep them there for 30 seconds or definitely longer we've seen that how frequently am i actually calling for that information as to achieve some of the benefits of cash modeled by this metric here cash hit ratio meaning how often did i find an item in the cache already and returned that back with that micro second latency and avoided the call to document db so here we have 5 000 total calls which will be considered as part of our caching strategy and next as cody alluded to there's different complexity as it relates to what actually gets executed on the source system in our case document db as mentioned we had a low query complexity which was running a simple lookup against an index we will have a medium complexity query which will actually look at an index field but then perform further validation or further filtering and finally we have a high complexity query which would perform a bit more loose loosely structured analysis such as through a regex so we can run different queries against the system of record and understand what the impact would be so run my first use case here and we see the cash is kind of warming up right and we have a cash hit ratio against relatively low complexity queries uh putting us around 90 cash hit ratio meaning this was the time we looked for an item in the cache if it wasn't there we wrote it to the cache and then on repeat request we actually were able to serve it in the cache because it wasn't evicted right so we chose to store the item for 30 seconds now we look at some of the performance benefits attained now keep in mind this is not a performance benchmark of elastic hash this is not a performance benchmark of document tb merely just a point of reference of how a single application can sequentially call these resources in order to benefit from you know the the two different calls out to the last cache in documentdb so just by a cursory understanding of how to make those calls we can see around 3000 commands per second or request per second going to elasticash and around 451 requests being served from the from documentdb and and now we'll run it again but this time we'll run a bit more complex of a query so we'll run a high complexity query meaning the database has to perform more work which means that the ratio between the commands per second and the database queries per second will definitely change so we start it up again and we see that elasticash is serving the data with that consistent throughput because the data is already pre-calculated it is ready to be served up from the cache and documentdb has to perform of course a little bit more work to process that more complex query so in this case it's running a regex operation so here we see about 77 database queries per second compared to about 2300 on amazon elastic now i wanted to just transition over into redis so that we can see an example of how this might look from a data perspective so i'll run my console so i don't let the data expire on me and i'll transition to my command line so here i have redis and just log into my host and i want the redis cli and that is running on amazon elasticash which is behind this environment variable my flask redis host so we can see that i'm connected to elasticash the next thing i can do is run the keys command and here you can see some final keys which have not yet been evicted but i'll run my console quickly here again so we can see what happens in the cache so we run that and i'll run my keys command just for the everyone at home don't run this in production it's a blocking command for the server but we see examples of keys now in my database if i run db size we can see there are about 406 keys in the application in redis so we'll just run this one more time this time with some low complexity queries and we'll actually look at some of the keys so you can see i've modeled my data using the complexity as part of the key prefix and this is generally a best practice to understand what type of information is in the cache before you have to access a key so i run one example i see a movie returned i run another example i get a different movie returned and these are hopefully showing you exactly how data can be modeled at least in a primitive sense using the string data type within redis there are a variety of other data structures which can be used to model different axis patterns especially if you need to maintain a sorted order of key value pairs in memory there's a sorted set data structure there are sets and lists to be able to represent different result set objects in a more native way on redis for this example we just looked at a simple key value pair modeled based off of as you can see here the concatenated version of the type of query i've run but at the end of the day it really just depends on your data access patterns and whether or not you could even further specialize by taking advantage of some of the reddest data structures available perp is built for a variety of different internet enabled use cases so with that i'll transition back from the demo and certainly want to thank you all for being a part of this presentation it was really great getting a chance to do a webinar alongside cody and the documentdb team as mentioned if you have any questions about documentdb or amazon elasticash we'll be happy to stand by and answer them after this session and thank you again for attending and we'll speak soon thanks