 Okay. My name is Jim Mulholland. I'm with a small company in Texas called Squeegee. And this presentation is going to be about MongoDB, which is a document-based storage system. So, again, this is about MongoDB. MongoDB is a document-based storage system from a company called Tengen, based out of New York. They actually just released the 1.0 version yesterday or Thursday. Thursday they released version 1.0, so it's a production-ready system. And I'll give you more details as this presentation goes along, obviously. So, let's get to it. So, first, Mongo. This is from the MongoDB website, MongoDB.org, if you want to look at the website. Mongo from Umongus is a high-performance, open-source, schema-free, document-oriented database. So, that's the way they say it on the website, and a little bit as an aside. They probably had to use the word Umongus in there because it's been a little bit of a controversy in using the word Mongo, and a lot of people haven't been happy about that word because it's derogatory, apparently, in a lot of languages, including English. I didn't realize this, but you can go to urbandictionary.com and look it up and you can see some interesting definitions. So, it was for Umongus. Obviously, it was nothing they didn't mean to hurt people. Actually, I've seen tweets saying people won't use it because of the name, which is a little ridiculous. So, I just wanted to mention that. So, I don't know if any of you guys have seen the Mel Brooks film, Blazing Saddles. There is a character on there called Mongo, which doesn't really help to cause a whole lot. That's him. A little more volume so you can hear what's going on. You get the basic gist. That's Mongo from Blazing Saddles. And here's just one more little Mongo clip that I thought was pretty funny, unless you're a horse lover, I guess. So, that's Mongo. But, he does have a good side because it's the guy that played Mongo, Eric Carroll. So, it's actually the dad on the show Webster. So, that was something I learned in doing research for this show, which I never would have known otherwise. I thought that was pretty cool. But, there's a good Mongo. So, trying to get the nice good image of Mongo because I got the Urban Dictionary image in my head. It has to be a good Mongo. In my search, I did find a good Mongo. Check this out. The big gingerbread man. The whole, I need a hero. So, that's Mongo. What I especially like is that basically Mongo DB, now I can have a theme song. I need a hero. I need a cool database. So, awesome. So, I went through the lyrics and it's kind of fitting. Bonnie Ray, not Bonnie Ray. Bonnie Tyler, thank you. Maybe she was thinking about databases. Check this out. Is there a white knight upon a fiery steed? Late at night, I toss and turn and dream about what I need? Who doesn't do that about a database? Steepen to sit around that night in the bed? Man, I need a better database. He's got to be strong. He's got to be fast. Database. He's got to be sure. He's got to be soon. He has to be large in life. Obviously, could be database. So, to pay homage to Mongo, the Mongo gingerbread man, in this presentation, to map it all together, using this tool, if you guys are questioning what I'm using, it's a tool called presiprezei.com. It's a different way of doing presentations. Instead of doing slides, it's on the canvas. Anyway, so, I decided to do the whole thing in the image of a gingerbread man. So, basically what I'll be doing is zooming in the different sections of the gingerbread man and just to remind us that Mongo's a good guy. Good, happy, positive feelings. So, why MongoDB? This is from the website also. It's a perfect blend of RDBMS and document storage systems. So, overview. Mongo is schema-less. So, like I said, it's document-based. There's no schema. You don't have columns in a table. It's all documents. However, even though it's schema-less, you can still have dynamic queries, which is huge. Before we discovered Mongo, we tried Calix, which is all static views. And to do those static views, you have to map reduce, and it gets a little cumbersome and complicated. You have to know a lot of JavaScript to figure that out. So, dynamic queries is nice. You can have multiple indexes on a single document, or what they consider tables, which is cool. It has replication to fail over. They keep saying auto-sharding is coming. It's in alpha right now, and it's extremely fast. So, there's been tons of tests and stuff done on it. They've had to couch and Tokyo cabinet and MySQL and stuff, and Mongo usually is right up there. Very close to Tokyo, if not faster, which is cool. Great for websites, which is what we're using it for. Caching, logging. A lot of talks about using it as a logger. It's scalable, and it can store large objects in a tool called Grid at Fast, which comes with Mongo. It's an easy way to store big images, videos, all kinds of stuff that you usually store in the file system. You can now store in Mongo, which is nice. You can access it from multiple servers very easily without worrying about going through the file system. It's not great for. It doesn't have transactions, so if you have a transactional app, this is not the database for you. If you have to do a lot of ad hoc business reporting or complex SQL, may not be the best use case. It does have dynamic queries, but it's not as complete as you would with SQL. SQL's been around for 20 years or plus, and Mongo's been around for basically 18 months. It's still new, which is exciting. They've come a very long way in a very short time. It's really, I think, a game changer in terms of what it could do, what it could be for the community, and not only the Ruby community, but any community, because it's just really cool stuff. If it's not this, something else like it. So, compared to other DBs. All right, big fella, let's crash this pocket. So, I thought that was good, because it's basically, it's a new kid on the block. It's crashing the party. These other day bases are out there. Oh, I had that backwards, that quote. But Mongo comes in a little bit late. I think they just, the public release, the public beta release is January or February. So, we started using it early March. And yeah, it's a long way to go. A lot of improvements to be made. So, there's a chart, scalability and performance versus depth and functionality. Memcache, obviously, is very fast, but you can't do a whole lot with it. It's just a nice, easy way to get data quick. Key value stores, like Tokyo Cabinet, also very fast, not as much functionality. The thing, they are just keys and values, right? Keys and a string of a value. Mongo is a little farther down on the depth of functionality because it's key and binary data. So, it's key in all kinds of type data you can tie to it. So, you can have dates and strings and ints and arrays and hashes. And then RDBMS is a little bit, it's more functionality than all of them, but not quite as performant in terms of querying and inserts and stuff in most cases. So, this is actually from, it comes off, it goes off the screen a little bit, but this is actually from the MongoDB website. It just compares Mongo, Couch and MySQL. Just some basic stuff. I won't go through all of them, but Mongo and Couch are document. MySQL is relational. It's the Object Rose Storage, one large repository in Couch. Mongo splits them up into collections, which is their tables. MySQL has tables. So, interface, CouchDB's REST interface actually makes it really flexible, and there's a lot of things you can do with that, whereas MySQL and Mongo use native drivers, which help with the speed. All right, the basics. So, here's just kind of an overview of what Mongo does, not in relation to Ruby, but what Mongo gives you, a little more details on that. So, go Mongo, go! Here we go, Mongo. So, like I said, this is the way Mongo is spread out. It's database collection documents, whereas RDBMS will be database table rows. Mongo is database collection documents, whereas a database is like, you know, a database. It's a database. Cool thing about Mongo, it creates them on the fly. So, like in Ruby or Rails application, if you define a collection, you don't have to do any kind of a create database or anything like that. You can try to insert a record into a collection on a database, and that database is not there. It'll create the database, create the collection, and insert the row. So, it all happens magically behind the scenes. Very fast, too. So, it's nice. You don't have to worry about any of that stuff. Collection, like I said, is similar to a table. It's same as RDBMS, other than it doesn't have columns, right? It's a collection. It's a way to group similar documents into smaller data sets. So, and that really helps out with the speed. It can be indexed by one more keys, which helps the speed. And there are three ways to relate to other collections. You can have an embedded document, which means that if you have a parent document inside that document, you can have just basically an array of hashes, which is another embedded document. Foreign keys is what we think about in RDBMS. You know, a person has, you know, a child, you know, child table would have a person underscore ID in it. And then a DB reference is just a reference to another table within a parent table. So, there's pros and cons of each of the three ways. That's actually probably one of the most complicated things about going to Mongo or any relational database. So, you have to change it where you're thinking of, you know, how are you going to architect this? You know, the tables are different. There's so many different ways you can relate tables. There's so many different ways you can store data. It's just a different way of thinking. Kind of very similar, actually. I thought about this this morning. Similar to this friggin' presentation I'm using, because it's not slides, right? You've got a big canvas. So, it's just you've got to change your mindset and how you want to relate everything. So, very similar in terms of Mongo or document-based databases. So, a document is the actual data piece. It's the row inside the collection. Each document stores both a key and a value. So, it's just basically you have a hash. So, you have a document is just, it's a single row of an array and a hash. It's basically what it is. And that hash can have, you know, anything in it. So, not going into more detail on that in a bit. So, the storage it uses. It uses something called Bison, is how they pronounce it, which stands for binary JSON. So, binary JSON is the data storage format for documents in Mongo that allows for storage of data types that JSON does not allow, such as date data format and bin data format. But, basically a way for them to store a whole bunch of different types of data. So, out of the box, which is very cool. Quaring. So, this is, Mongo actually comes with a console tool. So, you can actually go straight into the database and actually query it just like you would SQL. It has its own query language. So, these are kind of some of the types of queries you can do. So, here you've got the DB. So, if you got declared database, you know, so DB.connect, so I didn't do all this, but if you had a database name, you connect that database. And collection is actually the collection name. So, this could be like people. So, DB.people.find, and then first name, colon, you know, first name being the column name, or, you know, the entity name, property name, and then what you're looking for. So, in this case, John. So, it also has a very cool feature of regex searches. So, you can search based on a regex. So, this is just an example of that, just using your regex notation of slash slash. But actually, one of our tools is TweetCongress.org is one of the tools we wrote with Mongo. And we just do a Mongo database search. So, if you go to Tweet Congress and do a search, you can do any kind of regex search. And you can search for, like, it's Congress. So, like, one of the searches I'll do is go out and just look for, you know, number values to see, like, dollar amounts Congress is talking about and stuff in Tweet, which is pretty cool. So, you can do that in most other searches. So, that is a nice feature. And here's just fine by ID. Mongo, by default, has an ID field of underscore ID. So, your primary key is going to be called underscore ID. So, this is basically just finding something by underscore ID. So, here's another interesting bit of Mongo, and I'll show you a little bit more of this in a second. Because greater than, less than those kinds of operators are, in this format, dollar sign GT is greater than. So, if you want, in this case, they're trying to find someone that is older than 21. So, instead of age, you know, with a greater than sign or anything like that, it's basically multiple hash notation. So, age colon and then another, you know, brace greater than colon 21. So, different way of thinking about it. But once you, you know, use it a little bit, it makes a little bit of sense. And the cool thing is a lot of the Ruby ORMs, you don't really have to worry about this stuff a whole lot. So, here's just searching for an embedded document. So, in this case, you had a collection of, I don't know what this collection would have been, but person, book. So, this collection is probably book, right? So, you have a book collection or db.books.find. And then you're looking for all books that have an author of first name John. So, in this case, you have an embedded document inside the book collection. So, you have a book with all the book information. Then part of one of those fields in books is author. And then author is first name, last name, et cetera. And here you can just say author of first name John. So, easy way to, you can easily go inside collections and deep dive into them to do queries. So, and then this is something I really don't use a whole lot, but it has a concept of where. So, and this is just an example of how you can use a where clause. So, it's a little, it's JavaScript and some other stuff, honestly. I don't do this ever, but you could. So, yep, yeah. So, that was something I mentioned. So, good point. Thank you. So, yeah, you can do a lot, very flexible. So, I kind of get back to the map-reduced JavaScript stuff. I try to stay away from that. We haven't had to have a big use case for that yet, but it's definitely there if you need it. So, more querying. I mentioned that those notations you can use. These are some of them. You have your in. So, if you wanted to search for something in, you know, just like you would in SQL. And in is not in. Not equal is ne. All is interesting. All is if you wanted to find data where it's in, where in is an or, kind of, all is everything. So, if you pass in all with an array, you can find values that have all of these fields in it. Kind of complicated. I should have had an example of that. And then greater than, greater than or equal to less than. There is also a less than or equal to, which I didn't mention there. Size and where are some of the other ones. Now, the other cool thing. A lot of this, the documentation on MongoDB is actually pretty good. And if it's not documented, the Google group is awesome. And if you have a question about Mongo, you go to the MongoDB Google group. They'll usually respond within them. Literally, if it's more than five minutes, it's amazing. Someone from 10Gen responding to you about whatever your question is. It's been phenomenal. And a lot of times, if there's an issue, they'll have it fixed within a day. So, in a release. And so, that's actually one of the most pleasant pieces about working with this platform, is that the guys supporting it are really responsive and really easy to work with. So, definitely check out the Mongo Google group. So, fields is like select and active record. This is actually really important. Because you're pulling back, when you're doing data, especially when you're pulling back a lot of data. If you have big objects, especially a lot of embedded objects, those objects can be huge. And if you're just looking for, like, a name, it can make the difference between a query coming back in a second versus, you know, a hundredth of a second, a thousandth of a second. If you just, like, name versus, you know, we have, like, Twitter. We have a person that has the person and that person has lots of stats and stuff. They were tying the Twitter type stats or Tweet Congress and some other apps that we have. So, the one piece of data is huge. So, pulling back all that every time is a big deal. But if you do something, you know, like this field and specify what field you want to select, it makes a huge difference. And we've learned that the hard way a few times, learning when pages are taking so long to load and that's why we're just pulling back tons of data. So, something to keep in mind. Limit and offset comes out of the box for pagination. So, really easy to paginate with Mongo. Sort, just like you would with any kind of RDBMS, works on any column. So, and then count and group just out of the box. So, you can just do a person.count and pest in some kind of conditions clause and you'll get the count, the number of items in a deal, a collection. So, other cool stuff. Cap collection. So, this is kind of similar to caching in that it's last you set a collection size that you want a collection to be and once you get to that size, all the old stuff just starts dropping out. So, it's really good for like log, if you want to start storing logs and stuff and all the old stuff you don't care about. So, it'll just, you know, get erased at the end. So, there's a little example on how to create one of those down there. But yeah, it's a nice feature if you just don't need all the most recent data. It's called the older data. Upserts is basically just an easy way to do find or create. So, it has a, basically, if you can call an update and here we have basically, it's a unique field of Joe in this case. It's basically saying, okay, if Joe exists, you know, just update his age to 20. If he doesn't exist, go and create it. So, instead of having to do that in the Ruby layer, our application layer just does for your automatic, magically behind the scenes. GridFS I touched on a second ago, a little while ago. It's a way to store large documents. So, we're using this whole stuff for similar tools and it makes it nice and easy that you don't have to worry about how you can get the file system. Question? Don't think so. Good question. I don't know. What's that? Probably so. Yeah, I mean, we're just, right now we're just storing images, image data. So, it's just, you know, uploading it to the database and just accessing it tied to a model. It's nice and easy that way we don't worry about file system if you have multiple servers and stuff. It's just like you're hitting the database so you can get all kinds of big binary blobs of data. So, it has two collections to store the data. Files stores the, it's basically a collection itself. It has a files document to store the object or collection to store the file metadata, you know, file size, file type, all that kind of stuff. And that has a chunks collection that stores actually stores the binary data. So, and these are all the languages that they support right now. So, C++, Java, Perl, PHP, Ruby, Python, and then SpiderMonkey JavaScript are the drivers that they have out of the box. And they're creating quite a few other drivers or haven't helped create quite a few other drivers. So, it's definitely pretty widespread. It seems like there's quite a good following in the Python community already. A lot of stuff from Python guys, they're getting pretty big. So, Ruby. So, this is how Mongo interfaces with Ruby. It really has nothing to do with Ruby. I just like that last line, more heat less foam. Anyway, so, so, here are the drivers that are currently available for Ruby. You got the Bear to the Bones Mongo Ruby driver, which, you know, if you were going to build your own ORM or something, that's what you do. It's pretty in depth and there's a lot of functionality with it. You can do a lot of things with it. They have an ActiveRecord adapter. I've never actually used it. I'm not sure, you know, what kind of luck you have with it. It's kind of tough to marry the two, but they do have an adapter. So, you're more than welcome to try that. Mongo record is actually what we started using when we first started using Mongo. It's very ActiveRecord-like, but it's its own adapter, so you can use it with, you know, non-rails projects and stuff. We actually submitted some patches of that and created a plug-in on top of that. And then the last one is Mongo Mapper, which John Newmaker created. And a little story behind that, we actually, the whole reason this came about was a chance meeting of Win and I with John at RailsConf in Las Vegas back in May. And, you know, we're big into Mongo then, and literally we're the only person that heard of it at RailsConf as far as I know, RailsConf, because we talked to everybody and anybody that would listen to us about it and no one had a clue what we're talking about. John being one of those guys saying, okay, why do I care about this? And so we got to we went through our whole conference and actually got home and he, like, sent us an email or something saying, this is cool! And, you know, I want to create an ORM for this deal and so I thought he's not, so like, why don't you just extend the ones that have you. Is that excited about it? But, you know, he decided to do his own deal and he did Mongo Mapper and turned out great. So our most recent project that we're using now with Ruby, you're just using Mongo Mapper and it's very it's a very nice ORM. So some of the things that gives you out of the box is type casting, so you can, when you define your keys and I'll go into some more detail, you can say what type, data type you want it to be, and what have you. Which, at first, I thought was silly, but John's point was well, if you're submitting something from a form, like, you know, if you have an age on a form, how would Mongo know that, you know, age should be an int, right? You just store it as a string otherwise. So if you're data typing everything, it's, you know, now you can, it knows that it's an int. So, very good point and it actually worked out really well. Callbacks, aftersave, etc. So those work out of the box. Validations is very cool. Validates presence of, validates numericality of how it works. A little different notation of how it works, and I'll show you that in a second. Per object connection, per object database. So if you have a person object, you can have it connect to a totally different server, if you want it to. You can have it connect to a totally different database. So you just define it in the, in the model. So you can connect wherever you want. So it makes it very flexible. Associations, so has many, belongs to, works. Find all, find first, find last, find. I didn't put in here. But custom finder, like, you know, find by first name works, find by last name works. Custom ID, so the primary key, the underscore ID field. By default, Mongo gives you a big old GUID. So if you have a, you know, if you're doing a show on a Rails page, really person, you know, slash ID is going to be person slash, boom, huge ID. So Mongo Map allows you to do a custom ID, just specify what you want your custom, what your ID field to be, so you could be, you know, first name, dash, last name, or something. So your URL will look pretty. Now Dynamic Founders is there, find by name. And then create keys on the fly is cool. You don't have to declare all your keys in your model. If you want to throw in a key on the fly, you can. This is really nice for interfacing with APIs, like Twitter API, interface with live APIs. Right, yeah, sharding is coming. So that's, let's say it's an alpha now, but yeah, we actually have a use case for now that would be awesome. But they say it's coming and it should be soon to shard it. But yeah, right now, they have nothing out of the box. So like going to shard by city or something like that, right, yeah. So it's supposedly coming before the end of the year. So, which would be very nice. Yeah, be, I think it's different day, different collections. If you have a person you want to shard by city, you know, the usual use case is Craigslist, right? You want to shard by city, so you have a Craigslist and you want to have all the city, city, what would you call Craigslist listings? City listings, I guess, in one place, right? If you had Houston or Austin, that would just be your own collection. So, you know, so everything would be based off the city. So everything that's tied, all the listings would be by city, would be separated by city in that case. So, honestly, I don't know how they're going to implement it, but that's my understanding of it. So, actually, the actual physical storage. It's interesting, the storage is, it starts with a single file. That's one thing I did not mention here, something about the storage. It uses memory, memory map files. So, it makes it really fast. The problem is, it makes it look like your memory is completely 100% used, because it basically looks like it's grabbing on the memory, but in reality it's not, it's just there. I mean, if something else needs memory, you can take it. But a lot of people, they install a manga and they look at their memory and they're like, whoa, I can't use this. You know, it's taking on my memory. But it doesn't actually, you know, impact performance. But the actual files it uses, it uses some crazy deal. The first file is 16 mags, and then the next file, it's, you know, twice the size, and it goes up to like 2 gigs. And then it has, you know, multiple files of 2 gigs. It just creates. And it creates a new one. It uses a ton of memory, hard drive memory, physical memory on the machine, because it always spawns another memory file before it needs it. So you could be one point, you know, use, you know, one in three quarters gigs of memory in this one, for one particular database. And before you needed that second gig, it already creates a second 2 gig file in your machine, so it can also, you know, roll over to use that right away. So there's no impact. So it definitely can use a lot of memory. And we have a tool that we're creating multiple databases for a single application, and, you know, our memory data usage, physical data usage is big, because it, you know, it takes a lot of memory. So both, you know, virtual memory and physical hard drive. So, but the key's on the fly, and I mentioned this a little more in a second, but it's basically if you wanted to, if you wanted to integrate with the APIs, kind of getting on to, you know, you can just suck in the data from a JSON field and just store it in the manga without having to declare in your model. And then you can still be able to use .notation to get to that data after it's stored the first time without doing any kind of declaration or anything like that in your model, which is pretty cool. So, so here's an example. Sorry about the, I was trying to do color syntax highlighting, so I did a screen shot and didn't turn out as well as I was hoping. But, it's somewhat readable. So here's just a multiple model, a class, multiple classes models, whatever you're going to call them, objects. So you have a person, has many addresses, has many posts, and then here's the keys that we were talking about, first name. So, validation, here in this case, first name is required true, that's the validation. So instead of doing, you know, validates presence of, you just do require true. Same thing, last name, age is, you know, this is a validation numericality of, just say numeric true. And then the data typing there also. So, so we have two different types of relationships here. Address is actually a, an embedded document. So it's actually going to be stored with person. So in this case, you have a person, that person will have a document inside that document will be an address field. So it's actually one document. The second one is a post, which is just going to be a foreign key type relationship, and yeah, I think John actually released a new version of MongoMapper yesterday, and since that reverser dropped yesterday, you have to specify the person underscore ID key, before he didn't. But he decided it was too magic. So now you have to do the person ID, so if you have a person has many posts, you have to make sure you specify that key. So, here's kind of some examples of how that works. So it creates and updates. So, so I'm going over the person, let's let you know what the person looks like, the fields. So I do a create, and then just like you would, any kind of just active record, all this is. So first name, last name, age, etc. After the person, so this is basically on an IRB, this is what I put in, and this is the output, this outputs the object. So, and then this is also a very, very active record ish. Person.last gives me the person object that is entered in there, and then person.fadeColors returns the array that I just submitted when I submitted the doc. So, you know, get the array in that case. So here is an example of a favorite animal that wasn't included in person, right? I didn't mention favorite. I didn't know it was going to be a favorite animal, maybe it was just coming from an API or something. So, you know, grabbing the person data from an API, it has favorite animal in there, equals dog. So, you do that, you save it, and then once you went after you went and got the data, the object again, you can do person that favorite animal, and you'd have a dog. So, that any kind of definition defining. Same thing, this is just go one step further saying you can even do that with a hash if you wanted to. So, if you go in and define a hash that wasn't defined at all in your original model, you could do that. So, I just did a family hash of that person, saved it. So here, the class knows it's a hash, in this case an ordered hash. And then, to access the data within that, just person.family and then whatever part of the hash you want to access and it returns that set of data. So, embedded documents I just touched on. So, this is an embedded document, the address. In this case, it just has the address which is basically the street number, city, state, zip. Right? Yeah, kind of a second class citizen. You can't, so some of the drawbacks in embedded documents is you can't do queries on it, right? So, I couldn't go here and now and do, give me all addresses of people in Houston because it's tied to a person. I can find all people that are in Houston. I can't just get all the addresses, right? If you wanted to do a search on, like if you had posts and comments, right? And you wanted to show all the comments in one place. It probably not, doesn't make sense to do that in the embedded document. At first glance, you think, you know, those should be embedded documents. But if you wanted to show just the comments, or be able to search in just the comments, it's not easy to do if it's in embedded documents. It should be its own model. Yes. If you do person.caths or something that wasn't defined, I think it raises an error. I don't know. You know when? I'll have to type it in your head. So, yeah, we'll let you know. So, here's the embedded document. So, to store that embedded document, you create an address.new to get your address doc. And then you just, just like you would in an array, you just set that into person. That's actually bad character return there. A person.save should be on the next line. But that's how you add an address to a person as an embedded document. And then here is, so then you just do person.address.first addresses.first and give you that address. If that person had multiple addresses, you could, you know, obviously get them all there. Person.addresses.last would work too. And then here's a person.findfirst, and here I'm just doing kind of a touchdown what I was doing, the Mongo example. Just doing a deep dive to find the person that lives in a particular city in this case. So, find all people that live in Houston and that we would return, you know, an array of, or in this case one, because it's the first, but if you'd all find a return array of people, all the people that lived in Houston, not the addresses, they would return the people. So, that's a key differentiator there. So, foreign key relationships. So, this is kind of what I just touched on in terms of posts. So, a person who has lots of posts include here would be a Mongo mapper document. I didn't mention but, you know, I think it's there. But yeah, here it's embedded document. That's the only difference with using Mongo mapper in terms of defining as an embedded or not an embedded document. So, here we have a post that's just a document, but it has that person ID. I didn't do a belongs to here. I could have a belongs to person, but person has many posts down there. So, it's just like a cool relationship in that case. So, here you can do a build like you do in Rails or Ruby, person.post.build and that automatically includes the person ID and that's the Mongo ID that gives you by default. So, that's the big good thing it gives you. So, you can do a build, creates the post for you and then you do post.content in this case and this is a post and then save and that saves your post in that way and that person's already tied to that post because you did the build and then this is just how you get it, just like you think you would person that post that first like content and gives you the content of that post. So, validations which I just touched on. So, in this case like I mentioned first name, last name are age, numeric is true. So, if I did person.new in this case I didn't add a last name so I just did first name and my age I did 12 instead of the number 12 I did 12 written out. So, if you try to save that you get, it won't save it will give you your false in terms of the save and it will throw a couple errors. Must be a number, can't be empty just like you would expect with active record. So, I figured that was a good way to end it and that's basically my deal. My name is Jim Mulholland so that's my Twitter and my email so if you guys have any questions let me know. That's it. No questions? Oh, that I don't know. I had not had a need to know that. Right. Yeah, so whatever Ruby goes down to but something I've never had to have that kind of detail. Does this work well with like Amazon S3? Yeah, I don't think it's possible to store it on S3. It's just you store it on a server. So, it has a, you run it as a server on a, you literally do, you download the unzip the tar ball. Right, right. It's kind of a misnomer of document based database because it's still all in memory on your server so it's not really documents at all so I mean it's, you can do types and, you know, store them to wherever you want to store them, zip up a backup and it has all that kind of utility you can use but you can't actually store the physical documents on an Amazon or anything like that. You could have other servers. You can specify, so when you start your server or your, yeah, your Mongo server, you can specify where you want it to store the data and it can be anywhere but I don't think it's going to be S3. I could be wrong. I did, yeah. You could do person not fine by favorite animal and it's more type casting more than anything. It's already there and you have the type casting but yeah, you don't really need it. You don't care about type casting, you don't need it at all. The other thing is if you wanted to do notation of, you know, person so like to do the favorite animal you have to use bracket notation like you would a hash. I couldn't do person.favoriteanimal equals cat because it doesn't know if favorite animal exists yet but the first time you add it you have to do person bracket notation favorite animal equals cat so that's the other difference. Doesn't support transaction at all. They do have two JSON, right? Yeah, so I know they didn't have it at first but yeah, I'm pretty sure I have it now. I don't know about 2XML. Right? Yeah, it's a fast moving deal so it's tons of work being done on here so Oh cool, yeah, definitely. Yeah, no, it's the amount of support it's gotten since the RailsConf like in May. I mean, I've already talked to Rich. I've talked to him Rich Kilmer. So there's lots of people already using it now. It's just one of the first slides. It's the perfect blend of rdbms and database databases very flexible and easy to use and it's kind of natural. You know, the full profiler you can profile queries and all that kind of stuff, you know, the details that you'd expect in database. It shows you where things are fast, where they're not, where indexes should be used and all that kind of stuff. So, oh, I don't know if I've seen any studies on that. I don't know. My guess would probably be Linux because that's used as a Pacto and probably not Windows, but that's just because that's normal. So, yeah. Oh, good point. So one big thing Mongo does not work well because of the memory map files. It does not work well in 32-bit system. It works but you can only have a database size up to 2 gigs because of the way it's memory files. So it really prefers 64-bit operating systems. So it's something to keep in mind that if you want to install, like, so we try to do Tweak Congress or something on a 32-bit EC2 instance and we couldn't because we had too much data in there already. So, something to keep in mind, it prefers 64-bit. Yeah. There you go. Mill of seconds. Okay, cool. Yeah. That's a good question. You know, John? Yeah. So, apparently it's being worked on. Yeah, I don't think it's there yet. So, Prezi, P-R-E-Z-I. So, they actually have a free version. You'd have a little Prezi logo down here. And this is not the way you want to do Prezi, by the way. This is just me being silly. You don't want presentations where you draw things. The cool thing about Prezi is you'd have multiple sections of a presentation and then when you're asking questions, you can easily just, you know, find me to answer stuff on something. It's easy to zoom in. And, you know, if someone wants to know about that, you can zoom in to that section and talk about that. So, it's really, it's just a good way to see an overview of your whole presentation and then easily drill down into different parts of that presentation. So, yeah, this is actually a horrible way of doing it. But, man, I'm just excited to do it. All right. Well, thank you guys. I appreciate it.