MongoDB and Redis Caching

About this course

good morning from Redmond today we’re at the MVA you’ve got documents mongodb jump start with me today is Stephen Edouard and I’m Remy and today what we’re going to do is we’re going to

cover Mongo DB from beginning to roughly the end but before we get to that let’s sort of set the stage a bit now Mongo DB falls as part of this no sequel ecosystem now before we even dive into

what is no sequel what were some of the problems that developers are experiencing that sort of led to these solutions coming up sure so when no sequel came about the whole

movement I like 2008-2009 the biggest issue it was two big issues one was scalability so sequel databases just didn’t really scale to millions and millions of entities and then we also

had the problem with flexibility so single databases will do things like force you to have a certain structure and say that a year later your business or application logic requires a

different data structure or data organization doesn’t really make it as easy to change it’s not very flexible so those are two biggest issues Romney that we were facing with no sequel or with

sequel databases and that’s why no sequel kind of came about so startups in Denali for example they they might not know or new companies might not know what all of the data they’re going to

store for a specific entity some type of data model so they need it to be very flexible in the way that they would start this stuff and sequel wasn’t quite well some of the tools for sequel

weren’t quite the best to handle that and oh yeah totally is that what that’s that’s like one of the biggest things right so right startups you have you know the biggest thing about service is

that they start their business they have no like the definition of startup if you really don’t have a certainty of where you’re going to be or what you’ll be doing it maybe even three months from

the moment that they start and to say that you need to create a data structure which accurately describes your problem scenario that you’re trying to solve before you even gotten to mature stage

in your business is not really possible so that’s why I actually startups you’ll see a lot of startups actually adopt these no sequel databases because it gives them the flexibility in the

future to change those things alright well that was Steven my name is Remy I’m a Technical Evangelist based out of Montreal so that’s on the East Coast and what I like to focus on in my work is

the web html5 JavaScript node ie11 and Azure and really what I enjoy the most doing about my job is helping startups and developers in Montreal build really awesome technologies I’m super active on

Twitter if you want to follow me that’s my handle right there and I blog fairly frequently on Canadian devs and Remi SOCOM I’m here with Stephan Edouard and Stephan is a former software

test engineer hi but I’ll let you say a few words about yourself sure so my name is Steven I’m a soft I was a software development engineer and test on the.net runtime so worked on a couple of cool

projects if you heard a project and like the new native compliation change plus a couple of modern versions of.net and now Samos start developer evangelist down in Silicon Valley so I work with startups

to enable them to use our technologies partner with us with maybe different customers that we have that where we can you know align our interests and focuses and I focus on Azure with open source

technologies in particular startups love open source technologies it helps out with you know helps in cost but not in cost but as well as being able to contribute back to the source and

obviously you could the site how’s my blog and my Twitter handle so if you’re interested in any of the other things I like to hack on or create I like to make a lot of cool stuff feel free to hit

that website up and I have a lot of cool cool things you could take a look at awesome so today the course topics and they’re sort of structured into six topics the first module this one we’re

going to introduce what no sequel document oriented databases are all about and how they are different in relation to things like popular data sources module two we’re going to work

on getting started with MongoDB specifically and we’re going to look at the queries that we’ve got we’re going to continue working with some of the advanced

queries in module 3 and then in module 4 we’re going to work and figure out how to actually connect to MongoDB from two very popular programming languages C sharp and nodejs

so if you’re familiar with C sharp or familiar with JavaScript then stay tuned at least for until module form will show you how to connect to MongoDB using those languages module five is extremely

exciting to be honest because we’re going to be doing some fairly cool advanced data processing with Mongo we’re going to explore how to use MapReduce and how to use data

aggregation actually get some incredible insight from big data that we might have finally module six we’re going to show you how to run MongoDB on a cloud Ubuntu virtual machine we’re going to host that

up on Asscher so if you’re interested in deploying MongoDB at the end of this module and you’ve been following through the whole day well we’ll got you set up we’ll show you how to get it up right

away and you’ll be able to connect from different web apps to that same document storage the thing is bun 2 or Ubuntu I I mean I say Ubuntu III I don’t know exactly what it is probably Aakash

depending on yeah it’s at least the way I say it is something I guess that’s how I heard people on the East Coast days ok I’d be very different from some folks elsewhere and it could be that I’m from

Montreal so we tend to read words differently because we’ve got a little bit of that French background so it’s a little bit different could be a little bit yeah a little bit of that so just to

set some expectations hopefully you will fall into one of these categories we’re trying to target the content in this MVA to start up developers open source developers and enterprise developers who

are interested in things that aren’t just sequel server so basically if you’re a startup and you’ve been working and trying to figure out ok well how do I store my data in a way that’s flexible

and if I need to pivot in the future well then with MongoDB we’ll show you how that’s done if you’re an open source developer you’re basically building your entire stack on your building a lab

staff for example you might want to use Mongo as your data store as well now if you’re haven’t if you haven’t at least had some experience with JavaScript it’s really recommended that you take a few

moments to just take a look at some of the differences between JavaScript and the languages that you do know because working with MongoDB actually has us using javascript in the command line

tool so it’s a little bit interesting in that they took a really really popular language that is mostly predominantly on the web but it’s now in your database it seems like JavaScript it’s just

everywhere it’s taking over I I really think it is it’s awesome though so we’ll see it we’ll definitely see in module 2 where essentially just straight up in the command line we’re just

straight JavaScript just to manage database administration things like that that you would expect to not use JavaScript for we’re using it for database management alright so if you

haven’t joined the envier community mva stands for Microsoft Virtual Academy the site that you’re on right now and essentially it’s a free online learning tool tailored for IT professionals and

developers there’s over a million people registered on the MBA so you’re definitely in a large community working all learning together and you can definitely ask each other questions we

have a chatroom that’s going on for this MVA today so if you have any questions please feel free to post them in the chat room and we’ll address them live on camera right here we won’t even wait til

it’s over we’ll answer your questions right now now the other thing that you got to keep in mind is that MBA you can get points for different stuff and you can redeem these points for other things

so if you’re interested in getting 60 MVA points for listening live it’s quite easy how you how you get those points you got to visit AKMs slash MVA – voucher it’s on the slide if you can see

it right now and you basically enter this code MongoDB now you got to do this as soon as possible because this code actually expires on this date in 2015 the 20th of January 2015 so without

further ado I think it’s time to actually get into the me of this module let’s talk about no sequel documents now I this module is sort of structured in in two sort of

parts a discussion of what tabular data scissors are things that you might be familiar with if you’ve ever used sequel in any of those other databases and how that’s different with to document

oriented data stores so it’s all me Steven what are popular data sources I got so type of data sources are and we can call them column orientated tabular ilex column tabular but really it’s any

data store where you organize your data into a table and it could be a sequel database but like we mentioned earlier it could also be a node sequel database so in the case of sequel databases

tabular data stores have things called foreign keys where entity and a row so roads or an entity would point to another entity on another table so essentially your data for a thing or a

related set of things is spread across multiple tables and so that’s what we call tabular where the organization is for that that data is actually spread between multiple tables you have no

sequel table stores to which don’t really do that meaning that either there’s no strict enforcement between a foreign key meaning we’ll talk about that a second Romney but a foreign key

between one entity pointing to another that entity could not exist or something and that would be okay whereas a lot of sequel databases that’s not okay and it will actually throw an arrow if you try

to do that so if you have a tabular database of some kind and you’ve got all of these columns now typically from my understanding you can’t change these columns as frequently as you’d like you

can’t completely scrap the data split things up it’s a little harder when you’re in a sequel type data store yeah so definitely in the sequel type datastore that becomes a little

difficult will say that you have a column which has a foreign key if you drop it you know that that that might break the relationship or if you have a foreign key that points to a

another row on another table if you try to delete that row you might get an error there now if non with no sequel data stores that are tabular column oriented it’s

actually a little bit more flexible because you can drop some columns and it could be okay I know for example Asher tables I’m not too sure about Amazon’s venmo tables but if you drop a column

it’s fine you just lose the data if you want to add another column that’s fine you just don’t have any data for the new for the existing rows with that with that added new columns that kind of

makes sense so you still get a little bit of flexibility there but sequels generally doesn’t give you that flexibility and I understand it a lot of folks are building apps that might have

binary type data let’s say pictures if you’re building a photo sharing app let’s say you’re building a music sharing app let’s say you’re building a clone of some of the popular music

streaming sites out there and you want to store this data in your database and it’s something that’s scalable it there’s no sequel let you do stuff like that well I mean I think in my opinion I

don’t think you should put binary data like that into a database because that database is really for structured data or data that you can go through and query against you can’t query against a

song exactly right so when you’re talking about binary files like that regardless of the data store you’re using you probably want to put that into something like Azure blob storage or

maybe Amazon s3 storage and just keep it in there and just store the pointer to that data so that you don’t actually blow up your database size because I don’t think people understand that

there’s actually overhead when you add stuff to your database there’s some overhead to that data that the database causes so you’re actually just kind of heard yourself more and there’s better

networks like content distributed networks that actually take care of that for you and it’s a lot better more efficient gets to the content to users Wolk wicker so although no sequel and

big data tend to be lumped into the same conversation fundamentally they’re not exactly the same right absolutely not yeah it’s the big data you’re talking about getting insights on large amounts

of data and large data we’re talking like maybe terabytes I’m just you know grossly large now no sequel is just a flexibility it can be scalable and generally no sequel databases do some

trade-offs to get that scalability but no sequel is really talking more about data things that we can query against things that we can get that we can do with databases and things like Hadoop

where you can do huge MapReduce tasks those are a little different now we will talk about today using MapReduce on MongoDB actually offers it out of the box which is pretty neat but it’s let’s

we really should have muddled with two because we’ll be here all day right so the ecosystem is fairly it’s fairly big now you’ve got different types of no sequel databases and the one that we’re

going to talk about today is actually MongoDB so what is MongoDB so MongoDB is the no sequel database it’s a tabular it’s no tabular data so it’s all document orientated so people you know I

think the first time I looked at MongoDB I was like wow what what is this it’s um it was quite different than what you’re used to and when you come from type of data sources I remember in college all

we learned was sequel and even after sequel I’ve learned like ah sure tables and you know was still used to tabular data and this kind of MongoDB kind of came around and kind of blew my mind a

little bit as far as how you can organize your data and so really what it does it organizes everything to collections documents but no tables so a collection is just a collection of these

things called documents in a document is really just a organization of just include self enclosing organization of things that all related to each other because of this the way it’s structured

there aren’t any joints you don’t need to join things between these entities because ideally all that data should just be in one and that’s kind of the philosophy that MongoDB follows and it’s

not good for everything but it’s definitely good for a lot of things so if I had let’s say a document describing some bank data that would include all the

accounts that I have all of my profile information in the same document yes so all that data would actually just be self-enclosed into one document and that document you might ask what does that

look like it actually looks a lot like JSON that’s the most popular way or format of using it it doesn’t have to be but that’s the most popular way so and a scenario like a bank you would have that

user and all their accounts kind of sum this self enclosing thing rather than having this data spread out between two I believe we’re going to go to example that kind of you know really hits on

this a little bit more so if you have all these collections and then you don’t need to do joins to just get data from different parts of the database and when you have this one document that contains

everything what does that do for scalability does it improve things does it make it faster can you scale horizontally a lot more yeah so I mean if you think about it right so say that

you have a couple tables and you might have it charted that data charted between a lot of different servers when you do things in MongoDB you’re doing it on a per document basis so if you’re

looking if you’re trying to a join which you know doesn’t exist in MongoDB on a sequel table it could be quite large depending on what you’re joining on large I mean expensive whereas in as in

like MongoDB because everything’s kind of in a self enclosing document you know MongoDB really optimizes for horizontal scalability now what are we talking

about when we mean horizontal right so horizontal vertical scalability is hey and maybe your programs running quite slow you’re going to get a faster computer and you might get some more

memory to support that program horizontal scalability is instead of getting a faster computer and more memory for that one box you’ll get five more boxes with the same amount of

memory and CPU power and kind of spread that workload across different machines rather than having one machine do more work and so that’s what this concept of

horizontal scalability is and actually works out pretty well because it’s a lot it’s less expensive as well as especially at the cloud you can use some flexibility as far as how many resources

you want to pay for and use depending on the load and the man that you have on your service so I don’t need to get all of these really large size VMs if I want to run

MongoDB across different well if I want to run MongoDB in such a way that it scales to the demand that I have I don’t need to just get this very large VM anymore I can actually get a lot of

small ones yeah MongoDB offers this sharding where we can take different MongoDB instances the same the same database can be spread across these different servers and that

allows for scalability as far as the number of users that you can take number transactions you can do to serve your clients when the clients can be website it could be an app whatever and if one

of these machines went down that I don’t lose that data correct yeah so MongoDB is replication sets right n so if a machine goes down you there’s a there’s a replication set mechanism and Mongo DB

that’s prevent data loss as long as the things were committed to the journal and if this commits a journal then it’s committed to disk and it’s persistent that’s fantastic so it seems it seems it

like it’s extremely flexible very scalable and it lets me change how I store my data on the fly yeah that’s why it’s gotten pretty popular start ups just because of the flexibility here you

know the same reasonable are we talking about why no sequel just gotten popular MongoDB has been one of the more popular ones just because of its ability to scale and its ability to be flexible for

future scenarios and situations so like I mentioned though it’s not particularly it doesn’t fit everything just depending on what your data schema is that you need to support but it is good for for a

lot of things so let’s say that I’m building a new bank I like that example a lot and as a new bank I don’t necessarily have all of this legacy software that I need to

or I’m building everything from scratch now as a bank obviously we’ll have customers and they will have accounts so how do we keep track of persons and accounts okay so well we can first talk

about it in the tabular way that you would normally do it and then we’ll also talk we can talk about it and the way that you would do it in a no document-oriented database like MongoDB

so the first time around so say that you have this Bank and they have a traditional sequel database right so they have persons or holders and they have accounts for those people so say

that we have two people Stephen Edouard myself actually and Sam Wright would I who’s Sam I’d literally invented that name while it sounds pretty cool but it sounds pretty convincing yeah so

and then say that we have accounts and a calendar that you feel it’s like the account type or the balance of the account as well as the currency and the if you notice at the end of the the

counts table there’s a foreign key persons for the holder and that’s a pointer like I mentioned before like sequel top to the to the person that’s in the count holders now in this

scenario say that I want to delete Stephen Edward well there would be a problem because account 0 1 & 2 would still point to nothing would they will point to still Stephen so actually you’d

want to delete account 0 1 & 2 and then delete Stephen so that your database maintains consistency otherwise you’d it would be pointing off to nothing and that’s why sequel kind of gives this non

flexibility here so now if I wanted to so this is how it would be organized in in a sequel database every like type of entity really has its own table which is it’s quite different than what we’ll see

in Mongo so now say that we wanted to be able to get some data about about this table or about the data in this table so I think if we flip so what if we have the account holder with ID 1 what would

be the name for that account holder so it’s pretty simple it’s really straightforward you look up account ID 1 and then attached actually attach that data is Sam

Brightwood first name Sam last name bright with we didn’t really need to touch any other tables we need to touch anything else we had it all in one shot which is pretty inexpensive that works

pretty well unfortunately though this is not this is probably one of the simplest things and it doesn’t really apply to a lot of the different scenarios that we’ll see so if I was building the

website portal for my bank and then was I wanted to log in then I guess having this first table is enough yeah but the minute that I log in and I do want to show the customer his

accounts right yep so if I have to do I would have to do another query with this account holders ID to get his accounts yep right ugly now that’s that’s time to me like it’s two different queries it

could get really expensive if your data base is huge it’s filled with a lot of data I guess in theory so if we had all this stuff in one document it might might be a little bit more performance

and I could change things a little bit differently it would help it would help and we’ll see that in a second so let’s look at C let’s look and see how we would do this with a tabular data

store specifically a sequel data store so well answer the question whose account holder for count III so again I think this is this is a scenario where you just mentioned where say that I have

account holder and I want to know or if they have an account and I want know who the count holder is well so now we have an issue right because that data is not stored on the accounts table it’s not

physically there so because it’s not we have to actually go off and find it in another table so actually one of the things that sequel databases do quite frequently it’s a very common scenario

that you need to join information and joining is literally taking two tables tables and kind of smashing them together into one larger table it really is what you can kind of think of it as

so what we’ll do is we’ll say okay well give me the account ID 3 so we’re the cops 93 and we’ll say okay can we match the ID to the count holders tables ID and we know because the

foreign we’re going to match just one and so we’ll see that you can actually see in the animation here the diagram we join on the account holder ID and then we’ll

see that we have Sam Brightwood attached to the account holder 3 so we know that the answer is that the holder for count 3 is Sam Brightwood because of that join but that didn’t come to get like that

data wasn’t together right yeah so we have to do that on the server and house to bring that data together now the problem is is that we’ll see that in sequel databases as things get bigger

and bigger and bigger more complex yeah they will flex more tables especially if you’re not joining on a key then you know then you start having some issues because it become quite expensive and

those those queries can be quite slow and so that’s that was the issue that we’re seeing with with that type of data and no sequel database is kind of do a trade-off between what the complex

relationships that you can store in sequel for performance and scalability as well as flexibility so that’s what we kind of see this you there so let’s go to one more example that we would see in

a sequel database so say that I want to see which accounts are held by Steven Adler yeah so what if I was CEO are my accounts are so like you mentioned like the first question you asked like well

you know you sign in you have user let’s get their accounts right so we kind of to do something similar except we’ll start and so this time from the counts table we’ll start from the count holders

table so we’ll say okay well I know that I’m looking for Steven Eduard’s so I’ll look for Steve I’ll look for Edward and then say okay well give me all the account holders with the first name last

name Steven born just one we have the ID now and we’ll say okay and now let’s do join between that ID for Steven Edward and the counts table and let’s see where those IDs match and so again this is

another joint on the account holders ID to get that same that the associated accounts for Steven édouard so we’ll see that in this case we have three but you know it could be a wide variety of

however might not match and the Nussle will come back as here as a result for your query but again like it said it’s like is there not the state is not together and it can cause problems as

your as you kind of scale out so you can imagine as a bank you’ve got quite a lot of different data that you have to store things that are regulatory perhaps and things that

are more preferences for the account holder so all that stuff in a sequel database or a tabular database will go in separate tables and if I was just trying to get all that information from

my one big dashboard well then I’d have to do a join with that will impact several different table yep exactly right okay well that’s so and let’s say that some of this information I didn’t

have the foreign key for or the ID key yeah then I would have to also include that in my query as well yep you might have to join on something that wasn’t a key and that would that can be

potentially more expensive than what you would have expected with just the keys all right so document oriented databases do away with these joins these very complicated joins by having all of the

data in sort of one place there’s no tables there’s no rows it’s just collections of documents yep exactly so tell me a little bit more about these document oriented data stores so what

you’ll see is that rather than having this separation of entities across different tables will literally not like it’s kind of like your your data is natively joined and I think that’s

basically the the biggest concept of Mongo is that it’s actually just all that data system natively joined to where joins aren’t necessary to where everything is just one ball of like

information it’s not really separated or anything like that so it becomes quite it becomes quite handy because we can grab one piece of information and it will have automatically have an other

piece we don’t necessarily have to go off and find another query or find another collection or find something else to do an operation again if I just wanted some some of the elements in that

table can I still just get those specific properties or information and/or attributes from that one document or do I have to get the whole thing yeah absolutely so when we talk about queries

expecially more advanced queries that we’ll talk about in modules two and three we’ll talk about how we can do projections against that so we can filter out what we don’t want so you

kind of reduce the chattiness over the line and have not have to get all the data when you actually don’t need everything you only need a subset of what of what that

document have and so it kind of reduces the amount of amount of noise amount of traffic that we have to actually get from the MongoDB connection all right so you mentioned earlier something about

JSON I know it’s like every time I hear something related to JavaScript I’m just always shocked because it’s just everywhere everywhere so you guys are talking about JSON is that how these

document oriented stores mostly show their data yeah so what’s interesting is that and we’ll talk about a couple others lightly but the really popular way is to do it in a JavaScript object

notation JSON format now what’s interesting is that MongoDB isn’t actually storing the data in JSON it’s actually supporting it and something called beef on which is binary serial I

actually forgot what the hook something binary something object was a J’s or some guy yes exactly it is basically the binary version of JSON some guys and why they do this is because it’s a little

more performant but from a visualization standpoint from your from the external user standpoint it’s about the same as JSON so it you know you could just think of it like that and that’s how its kind

of organized so you don’t really have to worry too much about those details but and we’ll talk about and the sec will see like how MongoDB is actually not really storing it as as JSON internally

which kind of helps out with the query performance so but if I wanted to see what it looks like so this is something that’s that’s interesting so I have on the screen an example of what looks like

a collection got two elements right here ID 0 ID 1 and we’ve got an Accounts key that also holds another array that has incited a bunch of other sort of objects and this clearly is something that I

could copy paste into my JavaScript file and it will compile yeah well run it’ll yeah I’ll run you’ll run yeah so compiling wrong develop your own language

my dad compiled eggs I just wanted I really meant to say validate it will be valid yes good so here we’ve got these two documents so if I wanted to store something like this in

a document oriented database this is sort of the native representation that I would use something like this JSON yeah array what about here what’s interesting is that that’s literally what’s how it’s

stored okay so it’s it’s not even of representation that’s how it looks like in the database so what we saw earlier the two tables that we saw accounts in persons hmm this is actually the same

exact data that we saw earlier just in document form now what you notice is that in the collection the root level at the root level is the person yes we’re all starts and that person has

things like account and a first name and a last name every profile setting settings you know joins account so for that exactly well how long how long they’ve

been a customer yet a lot of metadata about what you would think that you would think that person would have and then associated with that is the actual can be embedded documents what we call

so this rabbit hole can keep going and going going where we have documents within documents within documents and we’ll talk about it has in the case that we’ll be talking about it account will

actually just be an embedded collection within the MongoDB document which allows us to avoid having to do these joints because well it’s already embedded in there and so you don’t really have to do

that so a MongoDB will let me query anything that’s in a document including the the accounts that are inside the sort of the the from the hierarchical point of view the account the bigger

account that contains the person’s name and metadata yep I can still query some of the accounts that he might have those for this person yep exactly so literally anything that’s in the document I can

reach it exactly it’s really anything that’s inside there is fair game for a query which makes it really powerful because we don’t really have to look at again we don’t really have to say okay

well I got the account now let me find that account holder or ads account holder and now let me find the accounts for that so if I had the question who is the

account holder for account ID 3 what do I have to do so the account holder for account ID 3 you would look up account ID 3 and you could do that directly in MongoDB and then once you find a cow id3

remember we can query and embed it inside the document yeah so we can go through a whole collection looking inside the documents and say ok well I found the ID account with account ID 3

that gave me a document and will give you a whole document it can give me the whole document or you could choose to just take the specific account that’s in this doc yes I could choose to take the

account as well I could say well I found a matching document and that’s what it is so let’s say I wanted to query for the accounts that you hold that Stephen Edward holes what do I have to do so in

this case we kind of do something similar to what we had before so we’re going to do is we query for the first name Stephen and last name Edward now the cool thing is Romney said you would

think okay well you know your query for first things seeing last image Ward and we expect that there’s one right or we can query by D only query by the account ID we expect that there’s one mm-hmm

you can query the the way that MongoDB works is that there’s a couple of ID attributes we’ll pass that a lot of it’s up to you so we can say that we have the expectation for this table that first

name Steve and last a nerd war first name last name results in a unique document and that’s really just enforced by you doesn’t it have to be that way by so it’s not enforced by MongoDB is of

course by my code yep exact query is this database interesting that inserts documents into the state of it yep exactly so now what we’ll see is that because we query by first thing Steven

lastname édouard we’ll get one document right and then that document literally gives us all accounts that’s attached to it so now we can say instead of hey who is the account holder for account ID or

for Steven Edouard we’ll just say give me Steven Edouard and why I can get everything all the information about this one person and really one shot rather than having to sift through a lot

of different tables and then wait for that query to come back and spend that extra time doing this now I know that there are other document oriented data stores and do they all

sort of function similar to MongoDB or is it different similar so there’s some new laws changes or nuance differences so a couple that could think of off the top of my head are CouchDB and as well

as Microsoft’s own document DB mm-hmm that’s actually in preview that’s the new this new service that’s up on Azure right now right yeah it’s a new service actually so it’s actually preview and oh

yeah but for example office 365 users they I believe a couple other services internally use it but the cool part about it and I think we have a slide to end but we’ll I’ll just chat about now

it has a sequel like as like sequel like data so or sequel like query language will notice that with MongoDB queries we’ll see in the next module that it’s quite different than sequel it’s

actually very different as opposed to doc DB actually has a sequel like interface yeah where there’s query documents yeah with sequel so if you’re familiar with sequel already yeah and

you don’t have to learn how to query this database using their specific method right I you think with my sequel yeah it’s not strict it’s not strictly faecal but sequel like you know take a

liar yeah so you don’t feel a lot more familiar exactly so I would say that’s that’s actually pretty good for someone who’s pretty used to sequel I’m going into no sequel or you know not only

sequel would be would be pretty good now you have CouchDB 2 which has like a native rest interface where we can just interact with interact with the server rather than MongoDB is protocol choice

is a proprietary let’s say proprietary open-source but it’s on the wire it’s all got yeah it’s it or not in your coffee or anything standard it’s actually just MongoDB flash flash it’s

their own protocol so Kara she be has a restful protocol instead yeah luckily so in theory I could query that over the Internet right like if I if I have the endpoint I can just give

it a few do a few rest calls and it would get me some of the day yeah you could just plug it right into your web server and just say so you have a note service

thing just you know Gogh McCall’s to it I believe dat I would be surprised if there wasn’t no any language adapters for even for the rest API because rest api is are kind of annoying anyways if

you just use it directly but that’s just my opinion anyway yeah but it should be fine as far as as far as that works and it’s interesting because they decided to write early Erlang what word yeah it is

that it’s like I’ve never heard of it there’s so many languages out there but it’s um it’s hard to keep up and as an evangelist it’s sort of our job to be aware of everything that’s going on

there yeah I know it’ll be difficult it’s funny because Erlang is actually something we haven’t really heard of too much but it’s actually it’s been around for a while it’s like I believe like it

wasn’t that the language that was used in telecom companies exactly for telephone switches right things like that and I believe it’s because of transactionality or things like that’s

why you know it’s a good language for those things but yes so MongoDB is written in C++ whereas a house use in Erlang so this is some differences in that but I would definitely encourage

looking at all your options before you kind of settle onto one database but I think what you’ll get out of this MBA is that the specific use cases that we would do for a docking orangeade alias

like MongoDB and kind of have an idea of how it might fit your datastore it might not and that’s good to know if it doesn’t and how we can do some really complex queries as well as some cool

data processing so they’ll be pretty neat so before we conclude this module I actually got a few questions from the audience and we shall ask what other data format does MongoDB support apart

from JSON it doesn’t it does it’s only large documents in Java for my walls with it well the question wasn’t too clear as far as um so let’s like when we store maybe binary data yeah JSON so if

you’re talking about like hey I want to store a photo yeah and the JSON document we’re in the MongoDB document which appears with JSON that’s really beefed on just just just FYI

but within there yeah you can totally do like a sequel database so you can take like an encoded binary blob and put it into your database there’s nothing stopping you from doing that anything

can be arrived with a string right and you can interpret as a picture as however you want I don’t recommend that I think we should you should use CD ends and things

like that but if you have to there’s no definitely nothing nothing stopping that but as far as like if you’re talking about like data formats like numbers and strings it’s really what you would

expect in JSON so you have numbers and you have strings and you know that’s really what that’s really what it is I got a good question from TJ isn’t there a way to build an app that

allows two to four people share the shared data between each other like say budget dates information and even maybe have a way for these people to chat with each other through the database so to

store all this stuff together in the database is that is that possible can we have multiple relationships well and that’s the point for that’s the point of having these databases right think about

everything you use every day any type of social platform any type of things like that they hold in a database this is a general database solution where we have different users and they might have

different things and they will talk to each other with by storing data for example my profile information someone else can look at that profile information that’s kind of how it works

now with some time MongoDB you would have your MongoDB server and you might have a couple of websites right or a server which interacts with that database and then you have your

consumers your your end-users your on your website right and have one user that’s looking at my profile information that’s stored in that MongoDB database and have another user that’s that’s

writing or it might might be adding I could be on the other end changing my data now if we’re talking about messaging and things like that I would I think there are other no sequel

databases that do better job handling things that are more like messaging type situations like Redis I heard observe built into it always does the first thing I was thinking of right off the

bock-bock it’s like Redis is actually pretty good for pub/sub we can actually send messages back and forth and there was actually a QuickStart that we have on that so you could check that out as

well but it actually would make that make that pretty easy but as far as like Mongo if you did that the way it would work is really you would put their message in MongoDB and

the use would have to pull it and it wouldn’t be as instantaneous as you want for chat so you could do that there’s also a variety of services that provide a P is for chat services as well

specific to that so I wouldn’t recommend that too much for things that are so pertinent that you kind of want to implement messaging but maybe if you did like non instant messaging like if you

want to just send a message to someone and have it there I would say that’s actually pretty you could reasonably do that with MongoDB another question and I got that I thought was fairly

interesting so in a tabular database if you had these columns and they were of a specific type in our example we had account types like investment checking account and things like that is the

performance in a document oriented DB just as good as in a tabular database when we’re going specifically for things like give me all the accounts of an investment type well yeah so it depends

right so I think you’re talking about maybe a string search versus unlike Mongo versus other databases that’s a really wish you washy question because we’re talking about generally we try a

lot of different databases I would say when you’re talking in general when you’re going over keys it’s fast its linear right when we’re talking about a string comparison across large amount of

collections and I can even do it in our demo we’ll see that it takes a little bit longer than what we would expect for index values like IDs so I wouldn’t say that there’s a huge performance gain in

that regard I think what we’re talking about with the secret sauce here with document databases it’s really the join the joint is where is where we don’t have to we can avoid that which reduces

that time but as far as like call on a column if you have strings you’re searching over it I can’t think of a technical reason why it would be that much faster on so on no sequel databases

in the sequel database alright so thank you so much for tuning in to the first module in conclusion we covered what is a tabular data store and what are joins that they that they use we also talked

about how document oriented databases store data in whole documents and we showed you how you can do types of queries in document oriented databases and the fact that document

arts databases don’t need necessarily joins yeah right so now if you’re very interested in staying on online we’ll be back in ten minutes and our next module is how to actually get started with

MongoDB and do some basic queries cool so thank you so much for being here and please come back we’d love to show you a few more really cool things [Music]