 I'm really excited to get to present here to you, all of you from around the world and across the globe. This is a really fun chance for us to dig into databases. Here's the part where I tell you, I am definitely going to post the slides on my site tonight. You're going to go check on my site tonight tomorrow, next week, next month. In about three months, you're going to get tired of pushing refresh and you'll email me and I'll promptly reply in six months and say, I'm definitely going to post them on my site tonight. And I'll never post them at all. I've ran into this scenario enough that I take the complete opposite approach. My slides are on my website right now. You can go to robrich.org and you can see these slides on my site right now. Let's go to robrich.org and click on presentations right here at the top and here's databases in the microservices world. You can get to the slides that we're about to look at right now. While you're here on my site, click on about me and you'll get to this page and this is some of the things that I've done. I'm a Microsoft MVP. I'm a friend of Redgate. I'm an evangelist for MemSQL. AZ GiveCamp is wonderful. AZ GiveCamp brings volunteer developers together with charities who otherwise couldn't afford software services. We start building software for them Friday after work. Sunday afternoon, we deliver that completed software back to the charities. Sleep is optional caffeine provided. If you're in Phoenix, come join us for the next AZ GiveCamp or if you'd like a GiveCamp in your area, reach out to me on Twitter or by email and let's get philanthropy installed in your area too. Some of the other things I've done, SQL search control basics, mine is chapter eight. That was a lot of fun to write. I worked on Gulp in version two and version three as a core contributor and one of the things that is particularly cool is .NET ROCKS. I replied to a .NET ROCKS podcast episode. They read my comment on the air and they sent me a mug. So there's my claim to fame is I have a coveted .NET ROCKS mug. So let's dig into databases in the microservices world. Talk about this guy. Application architecture. Let's start here because this is kind of fun as we look at the mechanism of microservices. When we look at microservices, we can kind of think of it in this way. We started with spaghetti. We moved to lasagna, end-tier architecture. And ultimately we ended up with ravioli microservices. I really enjoy this analogy and here's the as you grab the slides from robrich.org you can click through on this purple link to get to the article that describes this spaghetti and lasagna and ravioli mechanism. It's a really, really cool analogy. Looking at it differently, we used to have monoliths here on the left. And in that monolith, we had all of the pieces of our application. In this case, we've separated it into an end-tier application. But ultimately it's all deployed in one piece. And we deployed it in one piece because deployment was hard. We'd get on a conference call at, I don't know, through in the morning on Friday night and we'd keep deploying until Sunday afternoon when we got it right. And it was hard. It was really hard. Because it was hard, we didn't do it very often. Well, fast-forward to today and now we have containers that makes deployment really easy. It's cake to spin up a new system to get content forwarded from the Internet. Deployment is no longer hard. Because deployment is no longer hard, we can architect differently. We can architect as microservices here on the right. And so these microservices, each one is responsible for a very small piece of the application's functionality that makes the code a lot simpler. It makes the program really elegant and it makes it replaceable. If we have a change in business logic or in business need, we can swap out a microservice with a different microservice that accomplishes the task better. Or add new microservices to accomplish new tasks. And each of these microservices then can scale independently. So we don't need to have one big box or many big boxes to accomplish our website. We can have lots of little pieces horizontally scaled to accomplish the needs of our content. Now here in this, we have a user interface and the user interface will probably hit a load balancer that will then proxy off to each of the microservices or we may have microservices running on subdomains. But then the microservices as they need to reach out for data, they will reach out to other microservices to get the content from that microservices data. So as we look at microservices, they do one job. They're easy to deploy now with containers and they can scale independently of other content. If we need to scale up the shopping cart, we don't also need to scale up the login system and the monthly reporting system. They're easy to replace. And in particular, one of the tenants of microservices is that each microservice could own its own data. Now the beauty of having the microservice own its own data is that if that data needs to evolve, if that microservice needs to get replaced or adjusted, then there's no concept of, well, who owns this piece of data and can I change it and do I need to get all of the approval processes? That microservice owns that data and as the microservice evolves, the data can evolve too. Well, we set out to build microservices and we want them to own their own data but usually we fall back into a pattern like this where we have one monolithic database. That database that we used last year or 10 years ago or a generation ago and we have our microservices but they all talk to the same database. Bummer. Well, why do we do this? Well, well, there's a lot of reasons, but provisioning the database is still hard. There's a lot of content in there and when we lose a database, then that's traumatic to the organization. We've just lost data. We've lost customer records. If we lose a web server, yeah, we can prop up a web server. The website may be down for a little bit. Said another way, what will make the news is losing the database. It won't make the news when you lose a web server. So databases are hard. Ultimately, the DBA's job is to make that database secure and accessible. And so ultimately, the DBA is likely going to say no when we say, hey, can I have another one? Yeah. DBA's job is to enforce safety within a data structure. So it kind of makes sense. I'd hope that we could get a DBA to focus less on guarding and more on facilitating in a safe way. But that's another conversation. So ultimately, the DBA is pushing back. He doesn't want too many little databases because did we remember to secure it? Are they all backed up? It's really easy when we have lots of little databases to forget that basic database hygiene. I guess we didn't back up that database and completely lost all of our customer data. That's not something that we want to hear. So to avoid that, we don't create these little databases. We have one monolithic database. So now what do we do about it? Well, if we must use a monolithic database, we can treat it like lots of little databases with bounded contexts. And a bounded context is a methodology within an application to be able to carve out that portion of the database that is necessary for this particular task of work. When we think about a bounded context, we could look at a shopping cart. Well, a shopping cart needs access to the product catalog. The shopping cart experience probably owns the product catalog portion of the database. All of the product descriptions and all of the pictures, but they don't need to own the customer record. They don't need to own HR data. They only need to own the product catalog and the shopping cart, the orders produced. By comparison, the fulfillment system doesn't need to worry about what is the product description and the pictures at all. The fulfillment system's goal is to ensure that the content is delivered, ensure that it's shipped. So they own things like the shipping address and the order status, updating the order status to mark that it is shipped. They may own some billing details. Was it billed or perhaps that's a separate system, the billing system that owns credit card information and an order's payment status. A bounded context allows us to carve up our monolithic database into lots of little pieces. And now we can treat those little pieces as if they were, let's claim the term, micro databases. Now in time, hopefully we can get to the concept of micro databases, lots of little databases where each, hopefully we can get to micro databases where each microservice owns its own database. But in the shortest term, a bounded context is a great way to go. How do we get then to micro databases? Well, here's that micro database mechanism where each microservice owns its own data. Now we still have those two concerns about who owns the backup and who owns the authentication story. So to get to micro databases, we need to do interesting things like a mechanism to enroll a database in an authentication and backup strategy. We need that automation. When we have that automation, we can move to micro databases. We can get to that point where we have lots of little databases that accomplish lots of tasks. A micro database, it's owned by one microservice and other microservices that need to get data in this database will call that microservice to get or change data within this database. So how do we do joins in a micro database? Well, this database may publish events to a service bus. Now a service bus is really interesting. A service bus like Kafka or a similar type of thing is a mechanism for communicating between disconnected systems. The beauty of a service bus is that the publishers can publish content into that service bus and they don't need to get that data consumed right away. Simultaneously, a consumer can grab data out of that database whenever they're ready and might even be able to back up and reread some of the data out of that service bus. So if we have a service bus between our microservices, then those things that need to can publish events into the service bus and those things that need other data can subscribe to the event in the service bus. We call this event sourcing where we'll publish events into an event store and then we'll consume those from another store. So how do we do joins? Well, we listen to the events published by that other microservice and we keep track of the content that we care about. At that point, when we're ready to join, we own all of the data that we need to join on. So here's another good example. So who owns the customer record? Well, if we're in micro databases where each event where each microservice owns its own data, well, do all of them own the customer record or do we go back to a monolithic database where the customer record is one big piece? So for example, should the shopping cart own the customer record? They're responsible for creating an order based on a customer. They'll likely verify the shipping address or should billing own it they're the ones that need to own the credit card information or should human resources? Human resources has lots of well, secret data about the user and it needs to be kept within HR's boundaries or should sales own it? They're probably the first person that saw the customer but in sales, there's very different validation requirements. For example, a lead or a prospect, they may only have a name and a phone number. They may not have a company address but for order entry, we need to have a full shipping address. We probably need a phone number. So if sales is responsible for the customer record, do we enforce sales to enter in all of the data before we begin? Well, now they're starting to use, I don't know, notepad or Excel to keep track of their leads and duplicate databases is always fun. So who owns the customer record? Well, we probably want to create a new microservice that is the customer record and that customer record would only be the primary key and the account number, maybe the company name but after that, all of the rest of this data is specific to each microservice that needs it. So the shopping cart can call into the customer microservice and say, hey, I've got this customer ID, is this a valid customer ID or I've got this account number, is this a real account number? The billing can go ask the customer microservice, hey, I've got this credit card detail, is this customer still active? Can I still create this purchase for them? Human Resources has all of their data within their Human Resources microservice but the customer ID is still in the customer microservice. Because we have this mechanism where each microservice owns its own data, then each one can define what customer means to them. To the customer microservice, a customer is merely an auto-incrementing primary key and an account number. Everything else is stored somewhere else. Sales has their microservice that has a foreign key off to this customer microservice and they have all of the lead and prospect information. Shopping cart has all of their shopping information, all of the order history and billing has all the credit card details. We've created a schema where we have microservices that have maybe overlapping-bounded contexts but each of them still owns their own data with no overlap into any other data. Using event sourcing, we can get different data to different microservices or if the billing service does need to call out to the customer microservice, then that's totally fine. So micro databases, we've reached it. We've gotten to the point where each microservice owns its own data. We have enough automation to be able to enroll these databases in authentication and backup strategies as soon as they're created. So we know we still have that data safety but we also have a user experience, an architected system that will scale horizontally rather than needing to scale vertically with very large database servers. We've gotten to, let's coin the term again, micro databases. This is really cool. Microservices require micro databases. If we have the automation to get there, then it can be really, really cool. Well, the other thing that's really interesting here now is when we have micro databases, each database doesn't need to be the same kind of database anymore. That's pretty cool. So some microservices may be able to store data in a form that is better suited to that database. So let's take a look at that. I love this quote. They don't all have to be the same database vendor or the same database type said by me. Right now. Okay. So because they all don't all have to be the same type, let's look at some of the database types that we now are able to choose from. Well, relational, a SQL database, a document database or a no SQL database, a graph database, key value, time series, search, object or blob store, file store, column store. And let me introduce you to new SQL databases as well. So first up, with each of these, we'll look at the characteristics, the pros and cons, best use cases for this particular database type, and some example databases that will get you to Google search terms. I'm definitely not pitching a particular database in this section, but when we look at examples, that will help you to be able to Google it. Okay. First up, relational databases. What I love about relational databases is it's a great default. It's a really easy mechanism to understand. In a relational database, we have rows and columns. You can think of this like an Excel spreadsheet. With a spreadsheet, we have rows and columns. One of the big defining characteristics then of this is that each column has exactly the same kind of data in it. I'll have a state column in that column. I'll list each state or province. I'll have a phone number column, and I expect that to only have phone numbers. I'll have a created date column, and I'll expect all of the values in that column to be dates. One of the things that makes it a relational database is the SQL engine. And this SQL engine uses English-ish like queries, and so we can kind of get those SQL queries. This SQL engine has been tuned for generations to be really compatible and really efficient. So as we look at relational databases, we know that they're going to be pretty fast and pretty easy to use because they have this consistent SQL experience. One of the things that's particularly cool about relational databases is ACID compliance. Let's take a look at ACID compliance. Atomic, consistent, isolated, and durable. Now I love this talk here where they talk about all of the particulars about ACID compliance, and I'd invite you as you grab the slides from roberts.org to click through this link and read this article. ACID compliance suggests that all of the data either succeeds or fails together. We're not going to get part of the update through and part of it not. We're not going to lose some of the data. All of it either gets through or all of it doesn't. By comparison, we have eventual consistency. In eventual consistency, we'll push it out and in time it will get to be okay. But if we save and then quickly read, we may get the old data. An example of an eventually consistent system is ordering something at Starbucks. You go to Starbucks, you place your order, they hand you a ticket of a tag or they ask for your name. Once they finish preparing the thing, they'll come back and they'll give you your order. A similar thing is like a bank statement. If I go to my bank right now, I may or may not have the charge that I just made at Starbucks. But at the end of the month, I'll have all of the details of my statement there. Is eventual consistency sufficient or do I need asset compliance? That's definitely a question for your organization and probably for your microservice. Does this microservice need eventual consistency or asset compliance? So here's those details of a SQL database, rows and columns, one big server, tables of consistent rows and columns, asset compliance and SQL queries. One big server. So typically because database engines were built before multi-threaded CPUs were a thing, most SQL database engines scale vertically. I can't really put two machines together and tell them you're one database. That's kind of a bummer because to scale up, I just have to keep buying bigger and bigger boxes. Eventually, I may get to the point where I run out of box or I run out of money to buy that box. Relational database is usually being one big server. That could be a pretty big bottleneck. So next up, oh, so here's relational databases. Their strengths are in a strong schema. I can do table joins. I have that very fast optimized engine. I have that compatible familiar syntax. On the downside, I must scale up that one big box and ultimately, I probably will normalize my data to third normal form to be able to reduce redundancy in my data and ultimately to reduce database storage. To that end, I may choose to use an ORM to be able to get at this data easier, an object relational mapper that does that heavy lifting of turning my objects and my application into rows and columns in my database and back. It'll take my code-based queries and turn them into SQL queries and return those results. So we've got relational databases. Ultimately, the best use case for relational database is probably a good default choice. If you're in a monolithic database scenario, your database is probably a relational database. Here's some examples of relational databases that'll get you past that Google search. Next up, let's look at no SQL databases or document databases. I'm going to call them document databases because pretty much anything that isn't a relational database is technically a no SQL database because it's not using that relational SQL. But in particular, when we say no SQL, probably what we mean is a document database. Now, the beauty of a document database is that I can take this JSON blob and I can stick it in my database as one piece of data. Instead of tables, we'll probably talk about collections and we probably mean the same thing. The interesting thing about these JSON documents though is that they don't all have to be the same. Each document can include or exclude any fields that they need to and I can nest content within this record. They're ultimately optimized for reads and so I may choose a schema that is, well, a little bit redundant to ensure that I can read really quickly. A great example might be a news site where I need to read everything about that news article in one shot. So I'll put the author name, I'll put the author's details, I'll put the title and body content and I may put the first two comments in this single document. So that I read by ID, I get back that entire document and I render that page in one go. Now, most document databases are distributed across many machines. That means I can use commodity hardware there and so I don't need to scale up to one big object or one big machine. That is wonderful. But because of that, they'll set aside asset compliance for eventual consistency. Is it committed when I only write it to one machine or is it committed when I've distributed that to all of the machines? Do I need to wait for quorum across all of the cluster to be able to decide that that data is committed? Different NoSQL databases here will make different choices there, but ultimately that's kind of the major difference here. SQL databases are one big box and NoSQL databases are JSON documents on many boxes. So when I'm looking at a document database, it is distributed. I have no schema, which means that I don't need to care for it. I don't need to migrate it. On the downside, I have no schema, which means my application probably needs to enforce different things. Like my database probably does have a schema in the mind of the architect who built it, but now I'm just not telling the database about it. So now I have to do things like, well, what if I read data that doesn't exist? What if I'm trying to do a where query, a filter on a field that doesn't exist? So no schema can kind of be a two-edged sword there. Ultimately, because I'm outside of SQL, we may kind of try to layer a SQL-like language on top of a document database, but I'm outside SQL. I don't have that really, really fast tuned engine. So we end up with SDKs for each language, and that SDK may have JSON-like query syntax, but it's not SQL. Or maybe it is SQL, but now how do I talk about nested things? That can get a little bit weird in document database. One of the big downsides to document databases is each collection is its own island. There isn't really a concept of joins in a document database. Now maybe that's okay, but the way we avoid joins is we denormalize our data. We have duplicate copies. That does make writes more expensive because I need to update all of the copies. But again, in document databases, we're optimizing for reads. So here's some examples of document databases. Document databases might be a great use case for a product catalog or a news site, a CMS, something where I need to get the entirety of the thing really quickly. And the fact that I'm storing it in a little bit of a weird scenario or I don't have ACID compliance straight away is okay. So next up, let's look at graph databases. Graph databases are really cool in that they focus not only on the things, but on the relationship between the things. Here's an example of query into a graph database that focuses on the relations between people and the company they work for. Now I can do things like friends and friends of friends that really easily in graph databases and not only that relationship, but I can hang data off that relationship as well. Relationships then are directional, which is pretty cool. So graph database, how is that different from a SQL table with two foreign keys? Well, yeah, I could kind of start to fake a graph database with SQL, but it's that query syntax that makes it really elegant. The concept of being able to join across those relationships in a really elegant way. And so to that end, graph databases are really tuned for those relationships. So on the upside, it's really fast to be able to query into those relationships to keep track of those relationships. On the downside, it's made that choice at the expense of other things. Now it may do those other things okay, but its focus is on the relationship. So if you need asset compliance or you need really tight SQL or you need joins, then a graph database may not be able to perform as well as SQL database in that context. So a graph database, here's some examples. Graph databases are great for social networks because social networks really focus on those relationships. Messaging apps where I need to keep track of all the messages between people. Maybe a recommendation engine might work for a graph database because it's keeping track of relationships between products. Next up, key value databases. Now a key value database is really cool in that given a key, go read a blob of data. Often the data is JSON or a big text blob, although ultimately what's interesting about key value databases is the value is anything. We could think of this as a SQL table with a primary key and a binary blob value, those two columns. So whatever I choose to write in that binary blob is kind of irrelevant to the key value database. I just write it based on that key and when I want it back I go ask for that key and get that value back. This is really great for those key value type of experiences, those by ID type of experiences. These can be great for caching servers if we need it. I can store different data in each of the values because to the database it's just a binary blob. On the downside, I can't really query for anything but ID. If I need to do a where clause on content within the value, for the most part I have to read all the keys, deserialize that data in whatever way I make sense for what data I wrote there, and then look at that data and see if it matches. Not really an efficient way really an efficient mechanism. If we need that kind of query into the related data we probably want to lean on a different type of database. But for those paces where I really need to search by ID and I need to match on that ID really quickly and just get that data straight back out key value database can be perfect. So key value databases here's some examples of some key value databases. They're best used for caching, for configuration, user session data. Anything that is that big binary blob of stuff that I just need to access based on a key. Next up, time series databases. Isn't it cool that we have these micro databases so that we can explore all of the different types? Here in a time series database we're looking at different portions of time. We'll create time windows, time buckets. Now what's interesting if I think of an Excel spreadsheet I assume that there's only one piece of data in each cell in that spreadsheet. Well in a time series database I can create a window that is a week or a month or a day or an hour. And in that cell I have all of the data that matches. What's then cool is I can query into that window to get interesting things like min and max and average and count and that can be some really cool analytics to be able to create those windows, understand the quantity of content within those windows and to start to search for trends within those time windows. Time series databases are great when I have very time specific data. Perhaps I have sensor data coming from a mobile network or another type of time series data where I have lots of events that need to jump into my data store. It's not great when I have more generic data because well since we've set aside that SQL engine it's really tuned for this time series thing not for all the other things. Here's some examples of time series databases and it's really great for that IoT monitoring or real-time events. I might choose to grab real-time events for mobile devices or sensors maybe stock trades or click streams. Those are great for time series databases when I need to know did that event happen within that time window what was the min and max or the quantity of events within that time window when I need to handle that data in bulk in that way time series can be great. A text search database we can think of this like Google or an Elk stack. A text search databases focus is on finding matches within a document. Given a text document we'll go pre-catalog all of the pieces we'll identify all of the words we'll be able to then reach into this with an inverted index to be able to identify matches within that document. I'll type a query it will go find a match and it will show me which documents or where in that document is the match for my query term. Now in time we may pair this with a natural language processing engine so that I can ask it questions more so than just search for terms and that's a really good line extension for this. The text search database itself isn't that natural language processing engine but pairing those two is a really elegant solution. Text search databases are great when I'm trying to do that find the documents that contain this thing or find the spots within this document that need this thing. It's not great for joining on things it's not great for relationships between things because it's really focused on that finding the content within the document. One of the things that's a major barrier here is stop words. In English the words a and and on you know those words that don't really have meaning on their own so I may choose to eliminate all of these stop words from my index so that my index is significantly smaller. Now this is very language and culture specific so if I have an English set of stop words and I'm storing data in other languages then those stop words don't really make sense or maybe a word in English is a stop word but not in another language. A great example is I may choose to not index a because you know a by itself has no meaning but what about when I talk about the street avenue a? Well now the a is really important did I create a stop word that was a that just completely dropped it and now all that I've indexed in the street name is avenue. Did I shorten avenue to av and add that as a stop word because you know av usually doesn't have anything at that point this record has well nothing to match on stop words are really fragile within a text search database. The text search databases are great when I need to go find the content within a document. Here's some examples of them. It's great for matching documents or matching content within a document. One thing that's interesting about Splunk is that Splunk will actually put in the schema later so I can just quickly ingest all the data and then I can analyze it later and put in a schema so that I can start to wear on different columns or content. Next up an object store or a blob store or we could think of this as you know a file system. I'm not going to say file system because you know that has a very specific connotation. S3 isn't a file system or is it? The key is a path into that document and the value is well whatever I choose to put there it's really great to think of it as a file system. You know at that point I may not have folders per se but I do have documents and I may choose to create a naming convention that nests them in these simulated folders. That's pretty cool. These object blob stores are great for very large things for videos for file backups system backups. They're not great for when I need to query inside those big things. If I want to do a where on an object store I basically need to open up each document deserialize it in whatever way makes sense for that and then search that document using a different mechanism. So maybe I open up each backup and now I need to unzip it into place and then or maybe I open up each media file and I go looking for images within each frame or now you can see that where's an object stores are pretty fragile. So object stores are great when we need to store big things. We probably don't want to put a database backup or a video file in a cell in a relational table. Suddenly our database is you know two or three five times the size but we do want to upload this to maybe our NFS file share or to another blob store where we can keep that object as an object just as a binary blob in a lot cheaper mechanism for storage. Here's some examples of object stores. Next up column stores. Now column stores are really innovative adaptation to SQL databases where instead of storing the data in rows the door this data is stored in columns. So in a traditional system here on the left I would have all my rows and each row would have the entirety of the data associated with that piece of that row. In a column store I'm going to create a different type of index. I'm going to create all of that data in columns. Now using an example of you know countries in the world or maybe states within the country there's very few and so I can get a really good compression on this. If I'm looking for all of the states within the country there's you know maybe a dozen or a few dozen and I can make a couple of entries in this thing and it becomes a really well compressed index. Now that's really cool for doing analytics because I can reach into that column store and I can pull out the values that I need. I can quickly get to that section and grab all of those values. Column stores are great for faster seeks and for bulk reads. By comparison row stores are usually better if I'm doing transactional data where I need to do lots of random reads and writes because lots of random reads and writes aren't really the job of column stores. Here's some examples of some column stores. Ultimately column stores are great for analytics. If I need to do analytics on data bulk reading and bulk analysis column store can be a really good way to store that data efficiently and query it quickly. So next up let's talk about new SQL databases. A new SQL database is a new type of database that focuses not just on SQL and ACID compliance and all of those pieces but also adds with it distributed. One of the big barriers of SQL databases was they were architected when one machine, one thread was the name of the game. So with a new SQL database we may choose to in this case we're looking at a mem SQL architecture. We have a few aggregator nodes. We'll submit our queries to one of these aggregator nodes and it will go reach into leaf nodes to get the data out of the partitions. So the data is partitioned into lots of different commodity hardware and so now to add more capacity to our database we just add more leaf nodes and more aggregator nodes. At that point now we can get much more performance from a larger database without having to buy yet another big box. We can think of this as SQL with an SLA. Whatever you have the spinning wheel where you're waiting for that query to respond a new SQL database is probably the right choice. New SQL databases they are much cheaper to scale. On the downside because my data is stored in partitions to do something like a join may require data moving across the network. Now normally all of these nodes are going to be close to each other so that that network latency isn't a major bottleneck but that's one thing to think of when we're looking at a new SQL database. So new SQL databases here's some examples. New SQL databases are great when I've outgrown my SQL database when I just can't buy a bigger box or when I need to store more data or when I get that spinning wheel of doom where my queries are just taking too long I can get to that spot where I can partition my data across databases partition my data across nodes and be able to get at that content in a very multi-threaded mechanism. So one of the things that's particularly cool then is a lot of databases are looking less towards being a specific type and more towards being a hybrid database. I'm primarily this database but I'm also going to do that as well. So for example a SQL database that adds JSON types or a time series window or adding time series window functions to a relational database or adding a two column relational table to create a key value store within a relational database. We can see how we can take a regular database and kind of make it work in other environments with just a few tweaks. A JSON data type in the database is a great example here because I can create what is effectively a no SQL database embedded in a column of a SQL database. Now I still get joins across all of my relations but I may still have interesting query syntax into that JSON block. I can treat it not just like a big string in a column but like JSON data that can be really really cool. So as we look at this as you're grabbing your camera to take a screenshot of the picks this is a great one to grab. Here's a review of all of the different types of databases that we talked about today. One line two line description of that database and when you would want to choose that database as the database for this microservice. Now keep in mind because we're using microservices I can choose lots of different databases to accomplish the task provided that I enroll each database in that mechanism for getting the authentication and the backup in place and at that point then my microservice owns that data. Relational data, document data, graph data, key value data, time series data, text search data we can find the correct data store that matches these. So here's our architectures. We looked at that monolithic database underneath our microservices and if we must go there a bounded context is a really elegant way to solve this. Create a bounded context that outlines that portion of the data that responds to that is that this microservice owns and that bounded context can keep track of that portion of the database. As we get to that level of automation each microservice can own its own data store and we can get to that spot here on the right where maybe they're different databases in the same database server or maybe they're completely different database servers to keep those data sources very isolated. We coined the term micro databases here to outline that database that is owned by a particular microservice. When we get to that level of automation then it's really easy to upgrade that database where we don't have to go check with all of the other people that might be reading and writing to this because we know that this microservice is the only one tagged with this data. Micro databases we looked at each of these types of databases and the beauty here is that we don't need to choose only one. We can choose the one that best serves the task. Another magic question well how do we choose? Here's the other slide as you grab your camera grab this slide too or head out to robrich.org and grab these slides there and you can get this content straight away. Here's my recommendations and also recommendations as advised by Gartner. Ideally you would use a database as a service. Now a database as a service is great because they'll keep track of all of the backup and restore pieces all of the user authentication pieces, all of the uptime pieces. Never get woken up again if your database goes offline. You've outsourced that to your database as a service provider. Use automation if you're using more than one database server because that automation can ensure that you have consistent backups consistent restores consistent user authentication rolling secrets whatever you need that automation can provide that. By default choose a SQL database. SQL databases have that asset compliance. They're compatible. You can get a really good generic and general mechanism built into a SQL database. And then once you've got that solved for the other microservices where different data is best served by a different data store then grab a different data store that exactly matches those needs. Now you may choose a different database type based on the needs of that data and ensure that it's a really good fit because you are by choosing that different data store sacrificing more generic things. Now you've specifically chosen that because you've specifically carved out that portion of the data that's needed for this microservice or perhaps a microservice needs more than one type of data store to be able to store different types of data. This is a lot of fun to review all of the different types of data stores and in particular to review mechanisms of getting from microservice from monolithic databases to micro databases. What are your questions? Well, first of all, thank you for that because that was really awesome to get that overview and to lead up into the MemSQL story and the new SQL databases. I think that was a really nice thing. But we've got one question coming in from the YouTube feed and you may have already covered it but just to repeat, what are the downsides to using new SQL over SQL? The overhead network latency and performance? Yeah, definitely great question. When we looked at new SQL, a new SQL is that SQL engine but not constrained to one box. And so we get a whole lot of benefits of a cheaper way to deploy. We can just add more commodity hardware to get more capacity to our database. On the downside that one concern there is potentially network latency. We do need to coordinate between multiple boxes to do this. Now, arguably in our SQL databases, we're kind of doing similar things as we're trying to negotiate between threads or between simultaneous queries. So in a new SQL database, we'll likely get better performance in spite of that potential network coordination efforts. And so I think you did a good job answering the question earlier. So if you go back to your recommendation slide just for a second, if you could just pass back here. One of the things that is interesting to me is this new database as a service. And as an old school person, I should date myself with being a DBA for SQL service, SQL database back in the dark ages. So I think the emergence of database as a service and how it simplifies things for developers. So being able to attach to the service and let the service provider manage and the distribution of the service and the security and all that. Can you talk a little bit more about how that has changed things? Yeah, definitely. When we look at databases as a service, that's like one of the big things is, well, knowing that the data is my critical piece, I really don't want to let go of that. I really want to own that ownership of my data. And I put it in a cloud and feel okay. Well, when we look at just comparing, I don't know, our office building versus a co-location facility, as we move to a co-location facility, we've chosen to outsource providing electricity and building security under the premise that that co-location facility is better at that. As we move then from a co-location facility to a cloud, our clouds, our public clouds are going to be much better at physical barrier security. They're going to be great at that. We've also chosen then to also outsource backup and restore. That's one of the things that usually bites us is, well, was last week's last night's backup okay? Most cloud database vendors will allow us to continuously back up. So, you know, there isn't a big burden of time where we need to stop all the things and back up. And also, it's point in time restore, maybe point in time restore to a parallel spot where we can now diff the data that we had together with the data that we used to have and find any abnormalities. Those are great capacities with a cloud database. Additionally, most of them offer, you know, lots of nines uptime at which point restore based on hardware failure is no longer a thing. I worked for a company where their server room was in the same room as the water main and the air conditioner. And everything else that wasn't people. And there was one interesting morning where they learned that the air conditioning vent had nicely leaked into the top of the server rack. Oops, that doesn't happen in a cloud database vendors mechanism because they're keeping track of all of those pieces in really elegant ways. Now, it does mean you need to let go, but I would argue as you think through those types of things, the things that you've chosen to outsource, you can now focus on solving the business needs that you have, not on solving for little things that you don't care about. Definitely. I've been in those server rooms and seen that that scenario play out badly as well. So there's another question coming in for regular applications that are ported into cloud environments. Which database would you recommend? He's currently running Oracle aiming for Postgres for licensing reasons mostly, but is there anything you would personally recommend? This is one of the touchy ones. As an advocate for MemSQL, I need to show you how easy it is to get started with MemSQL on Red Hat. If I go to the Red Hat marketplace, I can just type in MemSQL, and here's that MemSQL database. From here, I just click Go and provision that database into place, and it'll keep track of MemSQL, that new SQL database across all of the pieces so that all of the pods in my Kubernetes cluster, in my OpenShift cluster are accounted for. And that's really cool. It's really, really easy to get started there. Ultimately, which would I choose? I would argue, what is the perfect size coffee mug? There you go. I think the other thing is it's matching it to your use case as well. I think that really makes a thing. There's no generic answer for this. I definitely will have you back, and we can talk about some of the MemSQL use cases for ML and AI and all kinds of other things that I've seen you guys doing work on. But it really depends on what you're putting in that coffee mug. And which side the handle's on, or how many or no handle, what it is. I mean, it's really about the use case. And so there's not really a good one-off answer. But I do think easily to be deployed, easy to maintain scales well. Those kinds of considerations are part of the first order of things that I look for. And definitely, we'll have you back to do a deep dive on MemSQL sometime soon. And I really appreciate you taking the time today to answer these questions and to give us this tour de force on databases today. That's definitely. This has been a lot of fun. I definitely learned a lot. I think one of the things for me is there are so many choices, and there are so many different use cases that it's really nice to see them all laid out this way. And so thank you very much. This is a wonderful briefing, and I can't wait to have you back again. So thanks, Ron. My users have other questions that we didn't answer here. Reach out to me on Twitter at Rob underscore rich. Grab these slides right now at robrich.org. And let's continue this conversation because this was a lot of fun sharing this knowledge with you. I'd love to continue learning with you too. All right. We're going to definitely get you back on. This was very, very useful. So thanks a lot. I'm so glad. Take care, everybody, and we'll talk to you all soon, probably tomorrow. So all good. Thank you, everyone.