 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVersity. We would like to thank you for joining this DataVersity webinar moving from relational model, excuse me, data modeling and relational to NoSQL. Sponsored today by CouchBase. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them via the Q&A section in the bottom middle hand, excuse me, in the bottom middle of your screen for that feature. And if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DataVersity. And if you'd like to chat with us or with each other, we certainly encourage you to do so to access the Q&A or the chat panel so you can find those icons in the bottom middle of your screen. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session and any additional information requested throughout the webinar. Now, let me introduce to you our speaker for today, Matthew Groves. Matthew is a guy who loves to code. It doesn't matter if it's C-Sharp, JQuery or PHP, he'll submit pull requests for anything. He has been coding professionally ever since he wrote a quick basic point of sale app for his parents' piece of shop back in the 90s. And he currently works as a developer advocate for CAHPS base. And with that, I would give the floor to Matthew to get to today's webinar started and the first webinar of 2022 for DataVersity. Hello and welcome. Thank you very much and happy New Year's to everybody. I'm going to go ahead and try to share my screen here. And we'll get started. So welcome everyone. We're going to talk about some data modeling and specifically making the move from relational to no SQL. And we'll talk about making that move into the cloud mainly as well. But everything talking here can apply to the cloud or on-premises if you're still doing that. We'll talk about CAHPS base a little bit today. CAHPS base server, it's a modern distributed no SQL database that fuses the strengths of relational with JSON flexibility and scale. Now, databases to me are like languages. It's good to know more than one of them. Fortunately, couch base is multi-lingual. It's a multi-model no SQL database that supports, as you can see here, documents. So your standard JSON data, a key value. So that includes JSON but also any other type of data you want to store. Full text search for obviously searching through words but also searching by geography. Analytics. So doing HTAP or HOPE, everyone referred to it type of queries. Mobile, referred to here as edge database. So that's offline capable synchronizing data to mobile devices and to the edge. And as we're going to see today, we're going to focus on relational style data modeling. And that falls under the document database purview here. Because I think couch base is very uniquely suited for handling the same style of data. And as we're going to see with the newer versions of couch base, the same type of use cases. So if that in mind, let's talk about the goal, your goals. So we want to identify if what I'm going to cover today is going to be useful to you. So I've been a use case that can benefit from moving couch base, for instance, a user profile session store catalog or any kind of content management. Customer 360 mobile as I just mentioned, and even things like large scale finance and fintech use cases can really benefit from a modern database. And so your goal then might be to get some or all of your data from a legacy database onto a modern database, maybe a portion of your data you just maybe want to slice a microservice for instance, to run on a modern database, or it may be a brand new service or maybe the whole thing. So if you want to be able to switch your application or or switch a part of your application or building a whole new application. Those are all going to apply here. And we want to also talk about optimizing your data model so we're not just moving from relational to couch base and leaving the data as is. There are some things we can do to change the data model, and or change the way we access that data to meet performance you know if we're not making any progress we're not receiving any benefits then what is the point of just switching from one database to another. So we're going to look at some ways to optimize that as well as well as some things that you you get just by switching to couch base in the first place. So we've got three steps want to cover today. So we're going to look at how to map data from relational into couch base, which thanks to some of the newer couch base features is relatively straightforward we'll see how that works. We're going to look at how to shift your application code over and I think again couch base is uniquely suited to this and no no database is a plug and play switch alright but lots of things that couch base. So the capabilities of couch base has that makes this much easier to do than others, and we look at optimizing so what are some things we can do once we're in couch base to improve performance to make a data access more efficient and so on. So we'll look at that today we're just going to scratch the surface a lot today so if you have questions I'd be glad to answer those just throw them into the q amp a tab there and we'll get to those later. Answer as many as I can, and if I can't answer them completely I'll try to point you to some resources. So let's look at mapping from relational. And so you might say why now why we're looking at mapping from relational to couch base right now. And I think one of the big parts of that is couch base seven, which is also featured in our new database as a surface covering code couch base Capella which I'm going to show today. And this makes it easier than ever to bring your relational data into a modern database or even to a fully managed database of the service or debas couch base has a has concepts called scopes and collections now, which provide organizational building blocks that these are akin to schemas and tables in the relational world. They're not exactly the same but it's a very similar concept that we can match to a couch base is distributed so as the transactions are relatively new features well means you can fall back to relational style modeling where you have data in several pieces, when you need to do that. And then nickel, which is also known as sequel plus plus this is couch bases query language it's been around a long time, but it continues to mature with couch base, including things like user defined functions and begin commit rollback for applications, but everything is there in sequel select insert update delete merge common table expressions joins aggregations those are all there have been battle tested for a while in couch base. So, you might just be asking the question now if you're not familiar with couch base is it is it just a relational database now. Have we just reinvented that and I would say that couch base has is becoming is attempting to become a fusion of the best of both worlds so we can do relational style things now in couch base yeah I mentioned acid and joins things like that. But the core focus of couch base remains these things here on the screen. Right we want to be distributed to provide high availability and scalability. It's flexible so we're still storing data as Jason and memory first so there's still a built in cash in couch base. Manage cash is part of couch base to provide fast performance. So those things are still part of couch base. With that in mind. We're going to create a translation dictionary a sequel to couch base dictionary that helps you to map the concepts from something you're familiar with legacy relational to a modern database couch bases listed here. So I'm not going to go through all of these and detail here but if we look at a legacy database it's runs on a server right when a modern database is going to run on a clustering a collection of servers that are networked together. So roughly the same from an organizational or developer point of view, but by switching to a cluster, we add scalability so we can keep adding additional machines to that cluster additional servers to the cluster to gain scalability and high availability if a server in the cluster goes down the server or the cluster can stay online at the database level. A server can have multiple databases and a cluster can have multiple buckets, but at the bucket level, we can say, we can define replication, we can say how much we want to replicate the data in this bucket. You know the more replication, the better of course but just straight off to that, and then caching as well so we can define at the bucket level how much RAM we want to give to the managed cash. A schema is very much like a scope and couch base. You know what you mean you come from a relational background, you may not have seen schema use too much. You might just be used to seeing dbo for instance in the sequel world and in couch base there's also a underscore default same kind of thing, but schemas and scopes can be used to manage microservices or multi tendency, for instance, a table and a collection is probably where one of the biggest differences come into play there, roughly the same level of organization, but with a collection and couch base we can define a schema upfront we don't have to say well, it has to follow these specific columns and these specific data types. So we gain flexibility there. And that's because inside of a collection there are one or more documents, and those documents are JSON data, they're not coupled to each other. So there's no tight coupling between the pieces of data in the collection and that helps with the distribution as well. And in the sequel world I mentioned this already but SQL plus plus the couch base is akin to say transact SQL and SQL server. And it's a full implementation, as I mentioned, so it's not just a sequel like language it's a full SQL implementation. The tables and leg and relational have a primary key and every document in or every sorry every row as a primary key value and then every document in couch base has a document key value. And then of course indexes are there to help with performance on the sequel queries. All right and I'm working personally on this project called SQL server to couch base this is a dotnet library that helps developers move from SQL server to couch base now even if you don't use dotnet or SQL server. And the same principles still apply to any any relational database and I'm actually trying to work on getting this to support other relational databases like Oracle my SQL for instance in the future, but for right now SQL server. And so I'll be going over some of those principles in that project. If you're interested in learning more about this project I'll give you a link towards the end of GitHub where you can check it out make suggestions try it out submit issues, that sort of thing. And some other tools that are very similar to take similar approaches. These range anywhere from a fully full commercially supported tool like glue sync. That actually allows real time synchronization between couch base and SQL server and Oracle, for instance, which is very cool you don't have to get rid of SQL server at least not right away. You can start synchronizing data between them, which allows you to dip into those modern capabilities without getting rid of your legacy database at least not right away. My project is most similar to something called couch grass, which is an open source community project as well. And it's just migrating from postgres to couch base same approach. The last approach then is kind of the more bare bones do it yourself DIY script based approach where you can export data into CSV files and then import CSV into couch base via UI or command line something like that. So there's a whole range of options here that will fit your budget or your requirements and everything in between. So a quick demo here of some mapping. I'm not going to go through the whole process because it does take a little bit of time for this kind of thing to run and we don't have a kind of time and it's kind of boring to sit and watch so just want to show you a quick example of what's going on here so let's start with a SQL server database I have running here locally this is an older version of SQL server but you know based on my experience this is probably a version that many of you're still using in fact but this is a sample database called Adventure Works you're probably familiar with that and it contains many tables schemas and lots of data so you can see just some of the schemas here are human resources person production and so on. And then within those schemas their tables so the person schema has address address type business entity and so on. So I can query the data with SQL, as you can see right here I'm querying the address table, and we'll get results here from the address table so just a bunch of addresses that correspond to. I assume to a person or entity of some kind. Alright, so we've got all these tables here all these scopes and schemas and I can map these to all those couch based concepts, as I mentioned earlier with the with that dictionary. So this is the utility that I've written. This is a configuration for it. And I'm just going to connect to SQL server, which is running locally. I'm connecting to a couch based Capella, which is running out in the cloud but of course you could also connect it to a local couch base or on premises couch base or whatever. And then you give it a bucket name, and there's a bunch of other information here I'm not going to go over but what this will do is it will go into this couch based server, and it will create a scope for every schema it finds and SQL server, it will create a collection for every table it finds and SQL server, and then it will start moving data over it will turn rows into JSON documents. Now I've actually done this ahead of time. I'll just refresh here to make sure I'm still logged in and to couch base Capella. And this is the online database as a service version of couch base, called Capella but of course we also have couch based server that you can run locally if you want to. But couch base Capella has a nice free trial going on right now so I'll give you more details on that towards the end. This is the bucket I've created called adventure works just one bucket here for now. Let's go into the scopes. You can see I've already my utility in fact has already created all these different scopes here like a person and purchasing human resources so that correspond to those schemas. And if I go into one of these scopes you can see that there are collections that correspond to the tables and SQL server so the person collection password email address and so on. Let's go ahead and go into that address one we were looking at. So look at the documents here. And so this is these are the actual documents in that collection. See ID one here you can see that we've got this address with ID one that is 1970 Napa court and that's ID one that's all in JSON data format there. So look back over here you can see we've got address ID one is 1970 Napa court and it's got spatial location, which gets translated to JSON and so on there. So we've roughly just kind of lifted and shifted the data from our relational database into couch base we haven't done anything to change the modeling, we've just moved the data over completely. We've done JSON format with a document ID instead of a primary key but the same data is there and ready to be used in our modern couch base database. And I can also if I wanted to run some queries on this, and I don't know if this is going to. I'm not going to necessarily run this because I haven't. I didn't prepare this as I query but if we go person dot address. And let's just say limit 10 let's see what happens here. Okay, so probably because it needs to be the venture works 16 something like that. I know no index yeah so I need to aware on there so probably where. See a dot address ID is not missing. And let's see if that runs. There we go so I can just run a sequel query and return instead of tables and rows I can get JSON data, I can put it in table format if I want to. It's a little more interesting, sometimes to see it in this view, we've got kind of an embedded object here in spatial location but you can see it's roughly the same type of query language and I'll show more examples of this later. In fact coming up next about how couch base makes this easier to transition. Okay, so we've got our data moved over from SQL server into couch base. And so that's a relatively straightforward easy step that may take some time depending on how much data you have. But the next thing is we want to, we want to move the, the application code over that the code that actually connects reads and writes from the database and again this goes back to your goals are you creating a brand new service, or are you changing anyone or changing part of existing service. So if so, you're going to need to make changes to the parts of that service or that code that use the relational database. And so the things you need to shift the tools you need to make that shift over is as follows is an SDK. First and foremost and this is whatever language or software is written with uses an SDK connect to a database now couch base has officially supported SDKs for 10 languages and then some beta and community support for other languages. But most of the popular ones you'd expect to hear Java node Ruby dot net see a PHP and so on are all listed there. So you can use those to connect to couch base. The other thing is SQL, if you're refactoring an existing application. Much of it that interacts with the database is probably going to consist of SQL queries that your team has written over the years. And so the question might be do we have to rewrite all of that. I think the answer from many of couch bases competitors is yes, you basically have to rewrite in a new query language and start over from scratch. And so couch basis answer is, you can use and maybe reuse existing SQL I'll show you an example of what I mean here and next couple slides. And the last thing is acid transactions now for a long time this has been an Achilles heel of distributed databases but there's been no acid transaction support, but couch base now has acid transaction support so if you want to keep your data in databases like relational style data, you can still have acid transaction support to make sure that data is updated reliably and consistent. Let me give you an example of SQL and what kind of reuse you can you can expect. And couch basis for its equal for many, many years so if you're already using SQL, this isn't going to change very much and that's going to make the transition smoother I think. So many databases claim a SQL like language but couch basis language SQL plus plus or nickel is on a whole other level. So for instance, this is a query from official Microsoft documentation about T SQL, which is a SQL server implementation of SQL. And this query returns all employees from Adventure works and the cities that they live in. And this is I think a non trivial example of SQL at least that'll fit on the slide. There are multiple joins happening here. There is a sub query. There is ordering going on. There are multiple tables involved there's multiple schemas involved. There's string functions so we've got the trims up there and there's concatenation we've got putting a space in between the first name and last name. Now I went ahead and converted this query over to couch base couch basis SQL plus plus or or nickel language. It turns the same same exact results now in JSON format instead of a result set, but there's a slight difference in syntax and I'm going to give you a second to put your guests into the chat box there of what that difference is. If you can actually spot that difference. If you blinked you might have missed it. Now I do want to make the point that this isn't always going to be this easy right it's not going to be always a matter of just copying and pasting a query and it'll work. However, you do get a pretty good head start towards modernization and you're using a language that most developers in your organization already know SQL, you know, probably one of the top three, certainly languages in the world, period, and certainly the most popular language for dealing with data, and it looks like some of you in the chat have gotten it correctly. So instead of using the plus symbol for concatenation, which is what SQL server uses SQL plus plus uses double pipes for concatenation which I think is what oracle uses as well or my SQL uses for concatenation. So, you know, SQL T SQL sometimes has some different syntax. Right so another example for instance, I'm a SQL server developer from way back so I used to have to use the top keyword now select top 100. When I first discovered my SQL and oracle it was there was a limit. You could use the limit keyword for paging which I found to be much much better. And actually that's what couch base uses is the limit and offset sort of thing. Someone saying that plus is not anti standard. That's correct. You know, most relational databases claim to be anti standard but there's usually some minor at least minor variations and additional keywords that are that are non standard so that's that's pretty much par for the course amongst SQL implementations. The next thing I want to look at is acid transactions so here is an example of a SQL server. The next example is a transaction being run from C sharp. Now if you're not familiar with net C sharp SQL server is totally fine. It's not important for our purposes today, but there's basically three parts of this code that are key for a asset transaction and one is to actually create and start a transaction so that's what we're seeing here this is using a tool called entity framework. And then you perform some set of data operations, you know, usually at least two could be more. And at the end of that you save those changes and then you commit the transaction assuming everything goes well. You say all right, I'm all I'm all done now make sure all these operations completes. And if something goes wrong in the middle they don't all are if they're not all able to be completed and there's a rollback that can happen. In this case it's happening during a exception but it can happen any of the time as well, you know, based on some custom logic is totally fine. So those are the three main parts of an asset transaction begin commit and or rollback. Let's look over at the C sharp example using couch based server. And again I've left out some of the data manipulation pieces here so it fits on the slide but there's basically the same three parts and one of them here is creating this transaction object now. There's some different settings to think about because we're talking about this is distributed database instead of a single server, but there are sensible defaults here. And there's a commit now in this case. The API here is inside of a lambda. So the commit can be implicit, but you can also make it explicit if you want to say context dot commit. And the same thing for rollback. It's also implicit if there's an exception, then a rollback automatically happens but you can also say context rollback if you want to. There's the same three parts there. So it's the developers don't need to create your own transaction framework or you don't have to work around those asset limitations with the modern database anymore. So what does this all mean, it means it's not going to be an overnight process to modernize it's not just a drop in replacement for a relational database. But with couch base it's going to be weeks or a few months instead of years and years with other database options. So I want to take a look at some of the code here, beyond the slide. More complete example just to show you this in action. And I've got here in this, the same GitHub repository, which I'll give you a link to at the end. So I've got a web API project for SQL server and I've got one for couch base and so here is an end point I want to look at here. It's called a get person by ID. Now I'm using entity framework but I wanted to show the actual raw SQL because ultimately, if even if using link behind the scenes is still generating SQL. So I wanted to show this in action here. This is a way to select a person, a given a person ID gets passed into this query, and that returns a single result as a person class or an object of type person. All right, for go over and look at the couch base version of that is a few other things here again because we're distributed and I can probably refactor this to slim it down but the main thing I want to focus on here is this SQL query. It's pretty much the same thing some slight syntax differences right it's a dollar sign here. And this query options for passing the person ID of the other query options, but it's the same sort of approach, selecting from SQL and returning a object of type person. And let's look at a more complex example using acid so I've got this back in SQL server code here. I've got this update person endpoint here, and it has an API called person update API and see if we can go to that real quick. Yep, so this API is very simple, it allows you to update a person's name first name last name and an email address of that person. Now, in our SQL server remember that person's name and a person's email address are in two different tables. So if we want to update both those at the same time, we have to do that inside of NASA transaction. So we've got this begin transaction here. We're going to find the person, we're going to find the email, and we're going to make changes to that person make changes to the email, save those changes, commit the transaction, something goes wrong, you can roll back the transaction. Again, I just do it in case of an exception, but you can be more explicit if you want to. Let's look at the couch base example here I've got a similar endpoint called update person. And there's the same object here person update API so it's the same exact API. And again we've just moved the data as it is in the couch base so we still have the person data in one document and the email address data in another document. And because it's two different documents we need to update them within a transaction. So creating a transaction object, starting a transaction lambda here. We're going to get that person out and make changes to the person, get the email out make changes to the email, and replace those pieces of data, and return okay. Notice there is not a explicit context that commit in here but I certainly could do that. I wanted to. And there's not a explicit rollback. Just because I'm only doing a rollback in case of an exception being thrown so that's just implicitly happening there. But certainly if you need to have more complex logic you can put those within ifs and elses and shifts and what or selects and whatnot. So there we go. So we've got very much similar approaches in the modern database and the relational database but we've gained a lot just from switching to that modern database in terms of building caching and json flexibility and so on. So all we've done at this point is, you know it's a lot of work to switch our application over but we have switched our data over and switch application over. The next thing we think about is optimization, because there are some things that a modern database can do that your relational legacy database really can't. So one of the things we need to think about, and this is kind of the main thing when it comes to data modeling in the json database or a modern database is when to consolidate. You know relational style data is spread out right we mentioned the person and the email addresses are in separate tables, since separate pieces. So in order to get that together we have to join those pieces of data those tables, and to update them we have to use asset transactions if we want to update them both at the same time. So those things introduce overhead, and especially in a distributed database that's overhead has to be, you know, it requires more overhead because I have more servers in the mix and the two piece of data could be on two different machines for all we know. So what we can do in a json data model is we can actually choose to denormalize data when it makes sense to. Now, my point of view on this is basically denormalize until it stops making sense to normalize and that that requires a human thought so this can't be completely automated but once you make a decision about when it makes sense to denormalize data, then we can actually automate the actual mechanics of doing that so let me show you an example here. So when I copy some data directly from relational to couch base it stays in this relational style format person is a single document represented by Jason object there. And person can have multiple email addresses, each email address is its own document as well so these are two documents here if the person has more email addresses there would be, you know, two email address documents or three or four, whatever. Now I don't have to keep it this way. In fact, keeping this way can be performance detriment as I mentioned, because I have to use join when I want to select a person and their email address, and I may have to use an asset transaction when I update both of these at the same time. Now, you can keep it like this couch base does support those things acid and joins, but you may want to consolidate to meet those performance goals and maybe just to simplify. So my utility, once you made the determination that yeah I want to combine email address in the person I think that makes sense. Then you can just specify which tables are combined and the end results going to look like this. So now there's a single consolidated person documents, you no longer have to use a join, because the data is already right there inside the person. You don't need to have to use asset to make a change right because it's just one document. So, just updating one piece of data in couch base is always going to be acid compliant. And you don't have to use a nickel even to get this data. If we know the key at a time we know 123, we can just get that with a key value operation, which is something that you can't do in relational world. If we make this change or application has millions of users and let's say they're often updating their profile not just email address they have other preferences. They want to update their purchase history, all kinds of things that a profile would want to keep track of. And for talking millions of users, we have just eliminated millions of joins millions of acid transactions, lots and lots of overhead and improve performance with one simple data model refactor. So I mentioned this in last slide but with relational databases SQL is the only way to interact with data. So I have to write a SQL query to return data no matter no matter what it is. All right, so an example here is, if I want person whose ID is 123. I have to say select, you know, star, probably shouldn't use star but select star from person where person ID equals 123 and that's the only way I can get that data out. And you can do the same thing in couch base you can write the same exact query in couch base to get that person by their ID. But couch base is multi model, as I mentioned earlier on, it can function as a key value database. And so that 123 is the key. So we can look up that data by just writing this piece of code here we can say get by ID 123. And that's always going to be the fastest way to retrieve a single piece of data. We don't have to go through a query engine or query parser, any indexing, it can just go right to looking up that data by its key. And it's going to in couch base is going to go to the cash first to get that data the managed cash. So if that data is in the cash already and you can you have control over whether you know how much memory you want to give the couch base. So we're going to pull it right from memory which is super fast. So we're going from potentially microseconds or, you know, heaven forbid seconds down to a sub millisecond or sub millisecond but millisecond operation to get that piece of data. And if we've already merged or consolidated our email address and phone number and so on, then we have gone from a lot of extra overhead and work to a very quick key value lookup operation. We can reduce latency. We can reduce pressure on the query service so we can't always we can't always eliminate every query, but certainly we can reduce pressure on the query service to leave it to do the work for where we do need the query service. This is a C sharp example on the right but again, similar APIs are available for all of the couch base support SDK so Java node PHP Python, so on they're all there. So let's want to restate you can keep the version on the left if you want, but the version on the right is going to be better performance, almost all the time. So, quick example of this and again, my utility has already done this. Actually, one of the configuration settings here is I can say alright I want to consolidate many to one mapping from the email address table to the person table and the foreign key is business entity ID. So I've given it this configuration, and it can do the rest, it can go ahead and, and match up each row of that email address data and embed it into its person it's parent object sometimes this is called the aggregate root. If you're familiar with the domain driven design type of modeling. And we're going to combine those pieces of data together. Now I've already done this ahead of time. So we're here, and not there. We'll go to say collections, and we'll go to person collection, and the person, sorry person scope, and the person collection. And here's all the data that's in there, at least five rows of it anyway, and zoom into this document here so this is person with ID one. And the lines, let's say two through 14 come from that person table, and then 15 through 25 that comes from the phone number table, and then 26 through 34 come from the email addresses table. But notice that person's phone is an array of JSON so we could have more than one phone number there, email address also an array we have more than one email address. There are some data in here that I would call vestigial. So for instance the online 17 and 28. They still got the foreign keys in there just because I've copied it as is into there but those can be removed, because it's no longer a foreign key it's now domestic data so we can just remove that from there if you know you're running a cleanup process for instance we could do that. But there you go so that's how we can consolidate data. So I just want to just remind you is that this is optional you don't have to do this with all of your data in in couch base you can keep the data separately. Absolutely. A question just came in using your example when is the overhead for say 20 email addresses I need to update just one. It's a very good question I don't get into it usually in this presentation. So one thing that couch base offers is what's called a sub documents API. So, in your case if we have 20 email addresses in there, which would be pretty crazy for one person have 20 email addresses but I guess not impossible. We only want to update one of them with the sub document API, we can identify just a portion of the documents, we can say okay I just want to update this email address here. And that means it's not going to pull this entire document across the wire, just for you to make one little change to this field, for instance, and then it's not going to send the whole thing back across the wire it's just going to be the minimum part that you need to update it. And you may pull the entire email addresses array or just one item from the array. Either way, you're going to work with just a minimum amount of data that you need and so that I will absolutely reduce your overhead to just a minimum you need to update one part of the document. So we're going to update like, I don't know, let's say Ken needs to change his last name for instance, we could, we don't have to pull the whole document over just to update last name we could pull just this one part. See what it is, and we could update just this one part. So that's absolutely possible to do with couch base some other databases also have this but couch base calls it sub document API it might be called other things in other databases. That's what you want to look for. If you're trying to look into that that does have an effect on data modeling absolutely because now it makes it a little easier for you to decide well should I embed all the things even if it makes the document really big. It's okay because I can update the parts as I need to without having to transfer the whole document across the wire for time. Really good question. Okay. All right, so let's go back over to slides here we're going to just kind of wrap up here. Got some next steps for you if you want to if this is intrigued you and you want to check it out yourself. One thing I'd start with is the couch base playground go to couch base dot live. And these are ready to run examples right there in your browser no download required. You can create an account if you don't want to start running those examples. There is something you can sign up for a 30 minute session if you want to play with the same database for 30 minutes. You can, again, you don't have to leave your browser you can do it right there, totally free. So there's examples in all those languages I mentioned so Java.net PHP C++ go etc. They're all there. Ultimately you can connect that playground to your Capella trial so the next step is if you want to try couch base Capella as a free 30 day trial going on right now let's go to cloud.com slash sign up completely self service tutorial has some sample data that comes with and you can also import data from CSV adjacent if you want to. You can connect it to your playground and start coding that way so again you don't have to leave your browser if you don't want to, but you can connect it as I've done here to, you know, a coat some code running on your local machine and interact with couch base Capella that way. And after you're done with that trial if you want to keep going with couch base there are some pay as you go models is different developer options there and production options there starter kits and so on so that's what you can do to check it out so start with couch base dot live and once you're ready to play with it some more to do maybe a proof of concept or something, you can go to cloud.couchbase.com and keep going there. If you're interested in that library that I'm working on I would love to hear any your feedback I love to hear criticisms truly. If you want to go there and just open an issue some of the best work I've done has has sprouted from someone entering an issue and saying hey what about this can I do this or hey why doesn't it do this or it should do this. I welcome that kind of stuff. So go to github.com slash M groves SQL server to couch base. That's what it's called right now it may change his name if I start adding other databases, but please go there and check it out I love to hear your feedback. So I have time for questions now thank you very much everybody and again happy new year everyone thanks for joining us today. Happy to answer any questions we've got. Thank you so much for kicking off the day diversity webinar new year was such a great webinar just to answer the most commonly asked questions just reminder I will get a follow up email to everybody by end of day Monday with links to the slides and links to the recording of the webinar. There was an email or a question that came in early here. Can you add remove nodes for a cluster on the fly. Can I scale up and down on demand. Can you add or remove nodes on the fly based on demand so I guess there's two answers here so if you want to automate that I'm not sure if that's automatable yet with Capella, but certainly you can add nodes to on the fly. But if you go in there and you can either add them via the web UI, I think you may be able to maybe arrest API you can use do that as well. And certainly, if you want if you want to explore couch based on Kubernetes, there is something called a couch based autonomous operator that allows you to do that automatically. So you can scale up and down based on certain, you know, performance measures or quotas things like that in your Kubernetes cluster. And that of course you you would have a lot more control and a lot more responsibility, but you can certainly do that and then run that any Kubernetes provider AKS or EKS or GKE or whatever. Love it. So how can catch base help streamline mobile application development in comparison to other cloud data store platforms. Okay, so with couch based Capella. So, first of all, let me start and say couch base does couch bases mobile offering consists of couch base light, which is a database that can run on devices so mobile devices and then some embedded devices as well. And then a sync gateway is the tool that you can use to have those databases synchronize data with your couch based server, whatever that's running running on premises or running in the cloud or what what have you. As of right now I don't believe a sync gateway can run in couch base Capella just yet that is something coming in the future. I would say, you know, how can help streamline mobile application development. That's a very broad question. I think one of the things that couch base provides that's relatively unique couch based mobile is offline first capability. So you read and write to a database running on the device, no matter if you have internet connection or not. And so once you have, you know, if you're if you're walking around for instance and say a large parking lots or you're out in the field delivering packages, you may not always have connection. But if you have a couch base right couch based light running locally on your device you can still do reads and writes and it will synchronize later once you're getting into an area where you have connectivity again. Awesome. What level of locking this came in earlier. Sorry say that again. It says simply what level of locking, what level of locking. Correct. Oh, we're talking acid transactions, or well, not so much acid transactions I guess. Locking is part of acid transactions but couch base offers locking API's up to offers both optimistic and pessimistic locking. I don't want to get into too much detail there because it's a lot of fun stuff that I'll go on about for hours but certainly both types of locking are supported in couch base and that is part of the asset transaction API but it's behind the scenes. Don't you have to delete the entire document and rewrite it if you're only updating one field. No, I think I cover that someone mentioned in the chat. Certainly not you can update. You know just a subset what's called a sub document API of the document so if you have large documents that's a very helpful thing to reduce the amount of waste and overhead and updating, let's say just a Boolean flag for instance. And what is the performance compared to relational. Yeah, so that that's a tough question to answer across the board, because it always depends on use case and how much data you have. I will say that one thing that sets apart couch base in terms of performance is the built in caching layer. So, lots of times you'll see large scale relational deployments that really wouldn't function very well unless they were integrated with some caching components with couch base that's built right in. So, as I mentioned that the key value lookup is always going to use that cash, which means we're talking microseconds for those operations. Now when it comes to queries, you know, it's it's hard to say without looking at the queries like I've seen some really gnarly queries out there and those can be bad in relational and the couch base world. So, having good indexing is very important couch base has a index advisor to help you to suggest indexes that would make your queries faster. And there's other options as well so couch base has a full tech search engine built in sometimes using that is the faster way to go. The analytics engine for really complex ad hoc queries that's the better way to go for those so there's a lot of options for couch base in terms of data access and just speaking about performance in general is kind of hard to do without without more detail. I love it. So, and if you have questions for Matthew feel free to submit them in the Q&A portion it helps me to find them a little bit easier than the chat but let me just going through the chat here a little bit Matthew. Any major attention points when transitioning as you explained. Any major what points. Any major attention points when transitioning as you explained attention. Okay. You know, I think, going from relational to modern database. There's a lot of benefits to it. If, if you have a database that is very heavily stored procedure or trigger uses a lot of triggers that's going to make it more challenging couch base does have some functionality that can replace those, at least, at least a large part of it. So, with couch base eventing and udfs and things like that but you know it's, it's still going to be very difficult to do that kind of transition. If you're very trigger and sprock dependent. So that I said that we've made your attention point for me, I'd be, I'd be, I'd be concerned about that. If you're looking to get into the transition, just make sure you have a good strategy for that before you go in. There are multiple databases per cluster and this cluster equals SQL server and SQL server. Right, that's correct. So, when we say databases, my translation there was buckets. So a couch base cluster can have multiple buckets so back over here. You see I just have the one, but certainly I can add more buckets to this I want to put a diversity bucket for instance, I can go ahead and do that right here. I'm going to go through the faults and there we go now I have two buckets they're in the same cluster though. So this is kind of equivalent to a database or catalog in the relational world. Perfect, and is it possible to document the expected format metadata of the collections documents. The expected format that's a very interesting way put it expected format. So there is something in couch base called infer, there is an infer function and what this does is it will take a sample of the day that you have. It will give you a, a schema that's been inferred from looking at that data so if you have a lot of person documents and they all have first name and last name. It's going to consider that to be, you know, generally the expected format I guess would be first name and last name right, but it's not going to enforce that. And that's kind of one of the key differences here is that you gain flexibility at the cost of enforcing you know those rigid constraints that you have in the relational world. So those lines, we do value the next question is talks about constraints specifically we value the relational databases for their constraints on triggers views etc how does catch base handle that. Right, I already mentioned the triggers could be could be an issue. As far as views go that, you know, that there's a lot of it depends on in the views world. There are some things we can do in cash base to help with that. As far as constraints though foreign keys and unique keys. I showed you the way that I would embed data that would help with that so it's no longer foreign data it's now domestic so there's less of a need for foreign keys there. Not always right but it reduces the need. And so a lot of that, a lot of that functionality kind of gets has to get picked up by the application that consumes it right so if you want to enforce something unique. Again, there are some potentially some workarounds with eventing or with the actual constructing a document key which is an enforced uniquely enforced uniqueness in the document key. But yeah there's a lots of it depends there. So, you know, something that again kind of the earlier question something to watch for is, you know, if a unique constraint is something you rely on completely for the database to provide. You know that's likely causing other problems in your application stack but it's something that definitely has to be handled by the application and that's that's true of almost any any modern no SQL database. I love it well that's all the questions we have right now I'll give everyone a little moment here just to enter anything else is reminder. I will send a follow up email by end of day Monday with links to the slides and the recording so anybody who missed part of the webinar can certainly catch up. Anything else Matthew you would like to add. Really terrific questions everybody thank you for all your discussion and questions I really appreciate it. Thank you for coming. Thank you so much again for kicking off the new year with us and couch based for helping sponsor yet another webinar just love it. And again, thanks all of our attendees as Matthew said for being so engaged in everything we do. And hope you all have a great day. Happy New Year.