 Hello, I'm Shannon Kemp, and I'm the executive editor for DataVersity. We would like to thank you for joining today's DataVersity webinar, making the case for NoSQL sponsored today by Tengen. Just a couple of points to get us started. Due to a large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A section. Or if you'd like to tweet, we encourage you to share highlights or questions by Twitter using hashtag DataVersity. If you're using the full-screen mode and you want to ask a question, just move your mouse to the top of the screen. You will see a tool to bar drop-down. On the far right is a down arrow that will produce a box to pop up. At the bottom of the box is a Q&A icon for you to click on. As always, we will send a follow-up email within two business days containing links to the slides, the recording of this session, and additional information requested throughout the webinar. Now to introduce our speaker for today, Graham Naray. Graham is a product marketing manager at Tengen, supporting initiatives in product marketing and alliances. Prior to joining Tengen, he was a senior business analyst at CSMG, a boutique management consulting firm specializing in the high-tech and telecom industries. So I'm lucky to have him with us today. And with that, I will give the floor to Graham. Hello and welcome. Thank you for having me today. Let's get started. So we're going to be talking about making the case for NoSQL. And I'd like to start off with a bit of an analogy. So think of relational databases. I think kind of like landline telephones. This is a technology that's been around for several decades. It's reliable. We understand how they work. We know what they're good for. And they're pretty ubiquitous. But when you look at what's happening in terms of development today, the advent of wireless technology and smartphones has shifted what you're developing. So when you look at development, it's happening on mobile applications. It's because the advent of smartphones has opened up a whole new realm of what's possible. This has been said for relational databases and NoSQL databases. Relational databases have been around for several decades. It's a reliable technology. We know how they work and we understand where they're great, what their limitations are. When NoSQL databases came onto the scene just several years ago, they opened up a whole new realm for what's possible in terms of application development. So while today I'll walk you through a number of the components of the context of how we got here and why is NoSQL around and why are organizations using NoSQL today? Really, I think the most important thing, the most salient thing, is really that applications and smartphones relative to landlines has opened up a whole new realm of what's possible in terms of application development and deployment. So building run applications has changed. Things like agile development and the use of cloud computing and all that. We'll talk about that a bit later. So in the 21st century, some leading web pioneers said, hey, we need a new database that can handle these new needs. What they came out with essentially was a new genre of databases that is now termed NoSQL databases. These databases are now available to several organizations that are being sold by companies like ours like TenGen with MongoDB, but there are a whole host of other ones like Cassandra and HBase and CouchBase and Neo4j, lots of other ones. We'll go into a little bit of how these factors have come into play in that sort of the broad scope context. And a database is really only as good as the impact that it has on the person using it. So one of the things that I think are really special about what NoSQL databases can do for your business are in the realm of enabling new applications that are impossible before. Improving customer satisfaction, making it much easier and faster to get products to market, and overall just reducing your cost structure. We'll talk about some stories later on in the presentation about how organizations are using NoSQL databases to achieve these goals. Quick overview of the agenda. We'll talk about what's changed, how did we get to where we are, how does NoSQL address the current state of things and the challenges faced by relational databases. And I'll tell you some stories about some of the cooler things that companies are doing with NoSQL databases today. Well, to start with relational database, for those of you out there who are less technical, just a little brief introduction, relational database is kind of so here we've got a table. It's got some first names, some last names, and a city, and then there's a unique identifier that come all the way on the left, person ID. We want to have a database, and we're going to store a bunch of people. We're going to store the city they live in. We're going to store the car over here. Then we might have another table for cars. So those have their own IDs and their models and their years and all that stuff, but they're linked by this person ID, which you see here in the second table, is that they come all the way on the right. And then they're linking one table to another. This is why we call it a relational database. Some things have changed, and now make it a little bit more challenging to use relational databases in some new contexts. So imagine that all of a sudden you start wanting to add more data, different types of data to your database, and you have way more rows and way more columns, and all of a sudden lots of relationships, lots of rows become more complexity. So what you're seeing here is obviously an exaggerated example of what can happen. But this is sort of a picture to illustrate how those equal databases came in. Really five things have changed, and we'll go into each of these in detail. But to start, there's been an increase in the way in which we ingest the data and the rate at which it changes. That's increased as well. Obviously the volume of data has increased. We go about developing apps has changed, and the way that we go about deploying apps has changed. In fact, these are the key drivers for ways a good fit for applications today, and those equal can help address those challenges. So for data variety, it used to be that relational databases came around that the types of transactions or queries or applications that they would have to support were relatively structured. A retail transaction. We know that it has certain fields. It's got a cost, it's got a date, it's got a location, a person, and a phone number, and a connecting phone number and a set of switches that it goes through. It's all very, very structured. It's not really to capture in a relational database, which is basically, as we discussed, like a spreadsheet. However, today we're storing all new types of data. We're storing just structured data, which would fit very nicely in a table. We're also storing something like a tweet or a like. There's no structure to that or a blog post. We're storing polymorphic data. So lots of different types of data in the same place. We're storing sensor data and clickstream data and click from mobile applications and all kinds of other sources. And just imagine trying to model that. Imagine trying to model everything on Facebook in a relational database. I mean, even if the volume were small, the complexity would be so great that that's just really challenging to do. So that is one of the major challenges posed against relational databases today. The second challenge is data velocity. It used to be that the rate at which we would query a database or add new data to a database was relatively stable and predictable, if nothing else. Even if it were to increase, we kind of knew why it would increase and when it might increase, and it wasn't necessarily that great. Now, data is changing and being ingested just extremely fast. So imagine all of the internal logs clickstreams, sensors, online systems, social media, all kinds of channels, the data is being ingested so fast. That's a challenge for a relational database to handle. We'll talk a little bit more about why that is the case later on. But data velocity, another major challenge. Certainly big servers. So what you're seeing here, actually on the left, is an example of an IBM B from 1980. Was the size of a refrigerator? It weighed 550 pounds and it lost $40,000 back then, which is roughly equivalent to like $110,000 now. That means it stored two and a half gigs of data, or more than two and a half gigs on my thumb drive. So today we're storing gigabytes and terabytes and petabytes and that's because the data is not just coming from a growing number of users, it's coming from a growing number of devices and an increase in engagement. And it's hard to store all that data on one machine. How do we get this data onto multiple machines and still make it work? Folks would use something called the walk-on method. Maybe they'd develop an application over a period of six months, 12 months, 18 months. They'd develop things in sequence. They'd spend a bunch of time up front planning the schema, the design of the database. And I think changes, they would do it every so often, not consistently. And the reason is that if you want to add a column or change a column or pivot a table in some way, that's actually tough. It's not just tough to figure out how that should work, but it's also tough to implement because you need to make that change in a few different places, not just in the database, but also at the application layer and then also in an intermediary layer called the ORM or the Object Relational Mapping. Often times it can actually just take time to execute that change. It needs to populate through the database, which can require a database downtime and all these other complications. Well, today folks are using agile development. They're pushing code every day, every week, every month, every quarter. And they need to be able to make those changes in a way that the database isn't the blocker for them. So it's hard for folks to make those kinds of changes and deal with that kind of agility and frequency using relational databases. It used to be, for relational databases, you've got to store all this on one server. One of the main reasons why is if you remember all those relations, if you've got all those tables and want to serve some kind of query, tell me about Bob's Bentley that's stored in London or whatever you need to pull data from multiple tables. If you didn't have all that data on a single machine, it would just take a really long time to do it. That's a pretty simplistic reason as to why, typically with a relational database, you want to have all your data on one machine. Well, it's hard to take all that work if you want to spread it across multiple machines but today, lots of organizations are exploring how they can leverage cloud and flies infrastructure. In this case, they're not using one single big machine. They're using lots of small, smaller commodity hardware or virtual machines being scouted out. The relational database is lack of compatibility with that type of architecture poses a challenge in terms of how do you reconcile the desire to move towards these new cloud and virtualized infrastructures with making it work with a legacy technology like a relational database? Just to summary, what's changed? We said that there's been a massive increase in the variety of data that we're storing, an increase in the rate at which we ingest that data and the rate at which it changes. Hopefully, the increase in data volume is massive, developing apps in new ways faster and in a more agile fashion than we ever used to before, and we're deploying apps across new architectures. These are the challenges that bring us to the primary difference between the data model. So I said before that a relational database is kind of like a spreadsheet. That's what you have on your left. On the right, we have some different NoSQL database models. Now, there are very different flavors, popular of which is the document-oriented model. In this case, rather than storing data in rows and columns, you store it in a document, not like a document or a PDF or something like that, but a special type of document. In the case of our product MongoDB, it's a JSON document. You can think of a document as being kind of like a row, and each document has these fields, and those fields are kind of like columns. In this case, you might have a document for every person on that table that you have over to your left. So that's one NoSQL database model. There are a few others, key value stores, wide column stores, graph databases. All of them have various places and trade-offs. The most popular of which right now is document models, so we're going to spend some time talking about that. One of the reasons that it's so popular is because of what they've done. They've taken the scalability and the performance of NoSQL. NoSQL tried to address about some of these things, some of those challenges we were talking about before, but they kept the rich functionality of relational databases. So they simply took what's great about NoSQL databases, but they didn't throw the baby out with the bathwater. Those are the reasons why document databases have been so popular. So let's talk about why databases generally can help address some of the challenges that we discussed earlier. For example, some interesting customers of ours, users of MongoDB, are doing with the data. So we said that we're now not just using structured data. We're pulling some kinds of new data. There's a Fortune 100 retailer. I can't disclose the name, but this is a household name that everyone knows. They're doing some really interesting things around retail price optimization. They're not just pulling in their own pricing data. They want to pull in competitive pricing data, but their competitors obviously don't give them the data in some kind of spreadsheet. They have to go crawling for it. So they're from a variety of different sources. Some of it's structured, some of it not. They pull in unstructured data from social media to conduct a sentiment analysis to figure out what products are hot and which products are not. And they're doing all this in real time. MongoDB's document model is flexible and not rigid in the way that a relational database is. And as such, allows them to pull in all these different types of data into one single database. And it's really powerful because they're doing real-time pricing optimization, which is important, really important for the retailers out there that are trying to figure out, hey, how do I compete with M on an eBay and other web companies that have different cost structures than me. This is an example of how a company is using MongoDB to handle the problem of data variety. Data velocity. Data generated data is probably the best example of how data velocity is increasing. And machine-to-machine communication is probably one of the more interesting spaces. So machine-to-machine communication refers to products and services in which you have a machine that captures or generates some sort of signal or piece of information, sends it to some other machine or central system, which then makes some kind of decision based on that data. So for instance, it could be an inventory manager. The machine says, okay, you've run out of inventory, sent something to some central repository, which says, hey, we've run out of inventory, time to re-suck. That would be kind of a simple example. So telephonica is a MongoDB user, and they are using MongoDB to power machine-to-machine platform that's capturing sensor data capable of capturing over 10 billion readings per customer for things like 100 meters and fleet tracking and all kinds of interesting use cases. This is something that previously really may have been possible technologically with a relational database, but actually totally infeasible, even if it would have been actually technologically possible. So really, this is making something possible that wasn't really possible before. And because MongoDB uses a scale-out model, this is what makes this application something feasible. So that MongoDB is addressing the data velocity problem. Correct? It stores billions of posts per day. They use MongoDB, their original deployment. This is the original deployment years ago. It had five billion documents and over 10 billion terabytes growing every single day. With a relational database trying to squeeze all that onto one machine was next to impossible. Trying to manage spreading it out over multiple machines was a total headache and a nightmare. MongoDB, again, with a scale-out model, no SQL databases provided, that's what made this possible for Clis to address its data volume. Organizations are interested in being agile, putting features and new products to market quickly and iteratively. Mailbox is a phenomenal example. Something that may be familiar in Mailbox is an innovative take on a mobile email application. It treats your email as a dynamic to-do list and allows you to do things like snooze emails for later and prioritize them in different ways. Mailbox, which was recently acquired by Dropbox, had an absolutely explosive growth where within the first 10 weeks they scaled over a million users and what they wanted to do was continue to push new versions of the app to keep improving. They run on MongoDB and they actually pushed three separate versions of the app within the first 10 weeks of launching, each of which featured hundreds of bug fixes and new features. This is incredible because it was able to respond to the need of its users very, very quickly. That would have been really challenging with the relational database because of what we discussed before around needing to, how it can be challenging to add columns and migrate data from one schema to another. But with MongoDB, which has a dynamic or a flexible schema, flexible data model, that type of agility was possible. Lots of organizations are working for ways that they can leverage cloud and virtualize infrastructures. We have Tier 1 Investment Bank, which I also can't share, but also a household name that everyone's familiar with. And that is looking to empower everyone in the business units to get apps to market and it's an agile manager. What it's doing to make that possible is it's creating a platform as a service with MongoDB where it's actually going to make MongoDB available as a service to every business unit within the organization so that they can just spin up instances of MongoDB and get going with their development. This is accurate because not only does it align with the way that this organization is looking to do business going forward, is looking to develop and do apps going forward, but it's also great because it has all the other benefits that we've discussed thus far, like it makes your in faster to deploy apps and to develop them as well. That's how NoSQL databases are addressing when we're opposed to relational databases. And now I just want to tell some stuff that I think really paint the picture of what's possible with NoSQL databases and what are the business-level impacts that they can have on your organization. So there are four main areas in which a NoSQL database, particularly MongoDB, can really have on your businesses enabling new types of applications when they weren't possible before improving customer satisfaction, making it easier and faster to bring new products and services to market and reducing your costs. So let's go to the first one. There's a fortune 100 industrial equipment manufacturers that looked at the market and said, you know, this is becoming increasingly commoditized. It's hard for us to stick out. It's hard for us to justify why someone should buy our equipment versus someone else's. So we need to build something that differentiates us. And what it did is it built a real-time analytics product for its customers. That product, what it does is it takes sensor data from the equipment and data back to a central MongoDB repository. And then that data is then presented back to the user with some very interesting visualization and analysis. Things that can help them with resource provisioning and allocation with efficient use of human resources as well. Things that help them save money. Unfortunately, I can't say a ton about the specific use case because it's still pretty confidential. But it's really some powerful stuff. In addition to that, what they're doing is they're using the sensor data that they collect to inform their own internal product development to see what aspects of the products their customers are using and taking advantage of. What aspects of the product are having a tendency to fail and which ones are more resilient? I can't say. It's this equipment manufacturer using MongoDB to deliver a new service that really wouldn't have been possible before because of the volume and the variety of data as well as the speed with which it needs to ingest all that data. That's not only an externally-facing app. It's an internally-facing app as well. Another great example is the city of Chicago, which is something called the Windy City Initiative. What they're doing is they're using a NoSQL database, namely MongoDB, to cut crime. It's actually fighting crime with MongoDB. Here's what it's doing. It's collecting and analyzing a variety of data in real-time from over 30 different departments. Same example, it's going to look at the number of 911 calls and complaints, number of broken streetlights, abandoned buildings, liquor permits, and locations in a given area. It might determine, based on that information, that they're likely to be an increase in crime in that area and can deploy more units, more police officers to that area. Not only are they using MongoDB to cut crime, but it's also using it to improve a number of other municipal services. This is another example of a type of application that wouldn't have been possible before. They're collecting data in so many different forms, including geospatial data to do better for the city. That's a powerful use case that I think applies not only to municipal and other governments, but can really apply to a number of organizations that are looking to aggregate data from a number of disparate sources that have typically been challenging to aggregate and do something meaningful with them in real-time. Today, actually, there's a phenomenal article in GigaOM about how MetLife is using MongoDB. MetLife builds an application called the wall. That application provides basically a 360-degree view of the customer. MetLife, for those of you who know, has over 100 million customers, hundreds of products. It can be very challenging to get a single view of any given customer across all lines of business, and all the times in which that customer has interacted with them. That poses a problem in terms of things like issue resolution and call center productivity, but with this new application called the wall, which integrates data from over 70 different existing systems, a customer service rep or a sales rep can get a single view of that customer. It looks kind of like, actually, if you see the screenshots of the application, it looks kind of like Facebook or some sort of social network, but instead the feed is all of the different interactions that a given customer has had with your business. It's phenomenal. If you've ever been on the phone with a customer service rep and they've asked you what your address was five times, every time you got transferred. This is dissolving that problem. It's decreasing the time to resolving issues, and it's, in addition to that, providing sales opportunities for those reps. So those reps can see the products that you're interested in. They can see what parts of the website you've clicked on and products that you've looked at in the past. So it's providing you not only with an opportunity to de-cost, but also to drive new revenue. The U.K. newspaper has over 20 million users. It's using MongoDB to serve users' dynamic content to its users in real time. So a little background on the Guardian, not surprisingly as it moved its business online, it found that increased user engagement was directly tied to ad revenue. So it looked at what were the ways that it could increase user engagement. What it does with MongoDB is it stores user data, things like login and SNS and that sort of thing, but clicking on data, it knows what articles you've looked at and what tests you've participated in and what areas you've commented on and used that to search content that it believes will be most relevant to you. And that has really two advantages. Not only does it make me a happier reader because I'm getting to look at the content that I care about, but it also for them drives ad revenue because it increases my engagement. So it's all very powerful. Another example of taking in new types of data, the variety component of what we were talking about before, and using that data in real time to do something meaningful. Here's your time to look at the market. So Intuit runs a real-time analytics platform for over 500,000 small and medium businesses. It used to take it months and quarters to push new versions of its application out. The dev cycles are now down to a week. Another example of that is MongoDB's flexible document model. So like we were saying before, that won't repeat too much, but if you want to add in a new column, you want to add a new feature, you've got to change the schema somehow for relational database. That takes time. With MongoDB and most of the SQL databases, you have a dynamic or a flexible schema that allows you to change the application on the fly, such that the database is no longer a blocker. Sys.com, same deal. It's dead for a couple of months to weeks. That's incredibly powerful. Imagine you've got users asking you for new features. You've got, they could be internal customers. They could be internal business users. They're asking you to change something. They're asking you to fix something. The ability to make that change quickly is very, very powerful. And no databases are enabling that sort of agility at the data layer. The benefit we'll talk about is a lower total cost of ownership. So there are a lot of ways in which no SQL databases can help save companies money, and one of which is that most of them are of an open source licensing model, which is much more cost effective than proprietary software from companies like Oracle and Microsoft. But additionally, the ability to use scale-out hardware, so instead of using monolithic servers, we're using cheaper commodity servers, scale-out servers. Instead of using shared storage networks, storage networks, we're using cheaper major drivers of cost savings. And for a tier one bank, another name that folks out there would know but that we have to keep confidential right now, we're saving $40 million over five years by switching a reference data management application to MongoDB. Not only are they saving money on licensing and on infrastructure, but the time it takes them to develop with MongoDB is much less that they actually save money on development. Compliance, they're saving money there because basically they're having so many operational problems with their relational database that they would fit in certain compliance standards and they would get fined. But because of the operational simplicity of MongoDB relative to what they had before, they're no longer being fined in that way. Another example is a major travel company saving tens of millions of dollars using MongoDB, not only again because of the infrastructure costs and the licensing costs that we were just talking about, but they're saving money on backup and disaster recovery. The reason is that with a relational database before, they had to store the data in so many different places because they kept having to convert from one form to another in order for it to be compatible with one system or another. They had to migrate it from X schema to Y schema to fit in this database to serve that application so they had way more copies of the data than they do now with MongoDB where they can all store it in a variety of different formats but in one single place. So that's saving them alone millions of dollars. So that's kind of the wrap up on NoSQL. I'll give you just a quick and dirty background on MongoDB but I don't want to spend too much time on that and I'd like to get to the Q&A for folks that still have questions. Okay, quick about MongoDB. TenGen is the company behind MongoDB. We develop and support the technology. We are the only company behind MongoDB, so as with a product like Hadoop, you might have a bunch of Hadoop distributors because they're licensed under a patent. That is not the case with us. We have a different type of licensing, open source license, and we are the only company behind MongoDB. And if you forget nothing else about MongoDB, excuse me, if you remember nothing else about MongoDB, it should be that it's a general purpose database. It's a dominant database. That's MongoDB in a nutshell. We've got lots of great customers like I just told you about. We have a huge community over 4 million downloads. We're the leading NoSQL database by all measures that we can find. We are the Agil and Scalable Database. We sell a bunch of subscriptions and consulting and training and all these great things. If you'd like some more information on us, here are some links that you can explore. But at this point, I'd like to open the floor to the Q&A where I had to find in my window over here. And we can find questions, y'all. I've got one question, which is, are these implementations primarily in the cloud or on-premises? It depends. A lot of folks use us in the cloud as some folks that have higher performance requirements or security requirements are using them on-premise, but it really varies depending on the application. Another question who asks about Telefonica and what type of application is on the front end, I don't think we would be at liberty to share that type of information. An enterprise architect who asks, do we have a real case supporting the claim that databases would be incapable of supporting dev processes and what is that case? So we have a number of customers. It's not that you can't do gradual development with a relational database per se. It can be very challenging. For the reasons that we described before. So if you design your schema and then all of a sudden you decide that you want to actually start tracking new types of information or you want to structure your data in some new way, it can be very challenging to all of a sudden pivot that schema on its head. Not that you couldn't do it per se. It would just take you longer and require a lot more work. So the idea is that with the dynamic schema or dynamic data model provided by MongoDB and other NoSQL databases as well, it's a lot more in line with how folks develop using the Agile method. There's a reason why NoSQL databases can scale better than a relational database. So why could a mailbox to plan MySQL? What issues would they have had if they didn't use MongoDB? So the reason is really about horizontal versus vertical scaling. As we've described before with a relational database, typically you want to have all of your data in the database. And the reason is that when you need to access data in multiple tables, for instance using something called a join or to execute a specific transaction, to grab that data across multiple different servers would just, it's expensive, it takes more time because you have to cross over the network. So basically doing those kinds of distributed, having a distributed relational database is very, very challenging for that reason because you have to unify those different tables or those different rows in order to execute certain transactions or queries. With MongoDB, that's not the case. Typically because the data that is accessed together is stored together, that's the way the document model works. So in a given document you would have, let's say, like going back to that car example, you would have all the information about again the person in the cars that they own and so you would be able, there wouldn't, it wouldn't be a requirement that you would go across multiple servers to get all the information you needed for a given query. And that mailbox chose, or one of the reasons why mailbox chose MongoDB. Now it's not necessarily the case that you cannot do so with a relational database. Oracle has a product called Oracle Real Application Clusters and there are products out there for scaling MySQL. There are cool reasons why I wouldn't necessarily recommend. Folks go down that path, one of the reasons being that oftentimes performance can degrade as you distribute the load and the data across multiple servers with a relational database for the reasons described. And also most of those features in order to do like efficient, low administration of horizontal scaling are not available out of the box. They require lots of custom work and operations overhead in order to make all that work. A question the same person is why no SQL MongoDB versus an MPP Comner type database for analytical applications. It would depend, there may definitely be situations in which it makes sense to use a stale and MPP database for certain types of analytics. Certainly if you're storing structured data and you have predefined queries, you know what you're planning on doing with data, it might very well make sense to use an MPP, you know, in your database. But in a lot of cases where you're still going to have unstructured data that doesn't fit well into a columnar database, that would be a situation in which it definitely makes sense to explore MongoDB. Someone asked a question about we're the only company behind MongoDB, how do we then think about companies like MongoLab and MongoHQ? So we can sort of the company that is developing the code base behind MongoDB. MongoLab and MongoHQ are partners of ours. For those of you out there who aren't familiar with those companies, they may want MongoDB available as a service, as understood, pay-as-you-go service for folks that don't want to manage the database later. And they're partners of ours, we're more than happy to have them as folks making the technology available to a wider group of people. Those are the ones driving the actual development of the technology. Another question about whether you can store binary files and WordDocs, yes, you can. You can store images and all kinds of things. We have a technology called GridFS, also open source that enables you to store pretty much anything you'd want in MongoDB. Another question is around whether there's a model for legacy applications integrating MongoDB with an existing relational database. Yes, absolutely. It really depends on what you want to do. Some folks who have basically wanted to migrate away from a relational database for a legacy application and move it on to MongoDB, what they'll do is they'll write an API, like a very simple service. They'll stand up an instance of MongoDB next to the relational database. They'll have a data layer on top, a simple API that basically says, okay, if this data lives in MongoDB, go get it from MongoDB. If not, get it from the relational database and write it back to MongoDB. In that regard, they're essentially using MongoDB as a cache. And once the cache is mostly filled, because MongoDB is not an in-memory database, it's a persistent database, they essentially migrate away from the relational database. That's one way. Another interesting use case that's come up in a number of customers is where they've got old legacy systems on which it's very hard to build new applications. What they do is they pull in data from those different systems, using MongoDB. They aggregate it all in MongoDB, and MongoDB now becomes the default for all new application development that needs to access the data from those legacy systems. Manif is a great example of that, but we've got a number of other very interesting use cases where folks are essentially mobilizing or making use of old data by pulling it into MongoDB, a more flexible data store. Someone asked about the pricing for MongoDB. MongoDB is free and open source just to be totally clear. We offer subscriptions for MongoDB for enterprise which comes with some extra enterprise grade capabilities around security and on-prem monitoring and that sort of thing, as well as support and commercial license. The pricing for that is I believe it's $7,500 per year per server. So it's not priced on a per-core basis, priced on a per-server basis. Per year comes with an SLA support and a few other things, but please feel free to try out MongoDB for as long as you want, for free, using the open source build. We will always remain an open source company and there always will be a vibrant and important open version of MongoDB. Someone had a question about can Sandra, how does MongoDB compare to Sandra? So I referred to a few different flavors of NoSQL databases before. I said there's a document database, which is MongoDB. There are key value stores. Some examples of that would be Redis or Ryuk. I also talked about wide column stores. Sandra is a wide column store. I modeled after Google's big table. It wasn't really the first wide column store. Other ones would be Google's big table and HBase and Acumulo and a few others. The thing that they're different is, again, really in the data model. So whereas I said with MongoDB, you're restoring your data in JSON documents, with a wide column store, you're actually storing your data in what they would call families. The big table with group columns is what I would describe it, but it's somewhere between basically a table and a key value store. The advantages to something like Cassandra is it's very scalable, has great write performance and is easy to manage. Like other NoSQL databases, it also has a flexible schema. The disadvantage is that it's still not really aligned in terms of the data model with modern application development. Modern application development is typically object oriented and that's why it aligns so well with the document model because the document is essentially an object. It's not easy necessarily to map data into a wide column store and more importantly there's a steep learning curve for building applications on Cassandra. So that can get a bit harder to get up and running. The last thing I would say about Cassandra is that it's got a lot of things going for it in terms of the management realm. It's limited in terms of the query language. One of the things that I said before about the document model in MongoDB is that the scalability and the performance from NoSQL while preserving the robust functionality of a relational database. So a lot of folks have come to expect certain things from the relational database. Rich data manipulation options the ability to do things like compound indexes and range queries and geospatial indexes and all these other things you lose a lot of that most of that really normally stores like Cassandra. Whereas you preserve that with a document store like MongoDB. That's part of what allows you to do some really special things like what the city of Chicago is doing for instance using MongoDB. What is a shard? Shards is the term for partition of data in MongoDB so I mentioned that MongoDB scales out horizontally. So a very simple example could be that let's say I have a list of 1 through 100 and I know that I can only reliably fit 25 entries in that list on a given server. So I'll put entries 1 through 25 on server 1 and 26 through 50 on server 2 and so on and so forth. Each of the servers would be a shard. Collectively those shards would make up the cluster and that cluster would store all the data that I needed in list 1 through 100. I had a question about so in a document you might have all the info about a person click stream and name, address, order history, etc. Or are there different documents related? It would really depend on the application and what it's trying to do and it would really depend on the use case. In some cases you might be storing all the information about a given person in a given document. In some cases you might have documents about some basic information about the person name, address, etc. And then you might have another place like an analytics database. Your analytics MongoDB cluster that's storing the data on click stream and other things. It's very use case dependent though, so I'm sort of hesitant to say anything too specific on that. I'm asking about whether MongoDB can be redistributed. I assume you mean like through a reseller or a partner model. If that's possible, feel free to email us offline. Is it possible to make analytics on MongoDB or is it necessary to use a specific application above MongoDB? So it really depends on what you would be trying to do. There are a lot of interesting things in MongoDB piece of functionality like atomic update modifiers and things like that. That makes MongoDB great to support analytics applications. Obviously, the database itself, there needs to be an application, some sort of interface that asks the database for the information. But these things like atomic update modifiers, like an integrated aggregation framework and integrated MapReduce, do allow you to do analytics in place in the data itself. The general rule that I would say is for real time analytics, I'm using MongoDB, for large batch oriented offline, type jobs. I would look at other solutions and using MongoDB in conjunction with them. So as an example, there's a MongoDB user that uses MongoDB as the real time operational data store to track things like click screens and other components of online user behavior. They then take that data, they funnel it into Hadoop using the MongoDB Hadoop connector They do a bunch of analysis on that data offline. That data is then piped back into MongoDB and then form things like real time ad serving and content. PowerGuard MongoDB is doing the real time component of the analysis, but Hadoop is doing some of the offline user sessionization and that sort of thing. In general, do you need an application server for the high volume input type applications? I'm not sure I 100% understand the question, but typically for most applications you would still need an application server of some sort. We don't normally recommend running the app server and the database on the same server, but I suppose it would depend. If it's high volume, you should probably have your app server separate from your database if nothing else just for redundancy. I asked a question about trying from relational database to a no-seq database, what are the possibilities for that? There are a lot of folks who come to us with this question. It definitely varies depending on the organization. Obviously, there are tons of possibilities. I could test those at length, but be happy to be up front about the drawbacks. Applications that were previously coded in sql, you can't execute sql queries on MongoDB, so you would have to run the queries for MongoDB. The advantage there is that MongoDB is extremely easy to use and easy to learn. In fact, we have free online training available to anyone around the world to train you on how to use MongoDB. One of the things that folks notice about it is that it's just so easy to use. Typically, you find that it doesn't take developers very long to figure out how to use it, and given the richness of the query language and the fact that it's providing you with a lot of the same functionality that you've come to spec from a relational database, it's typically not that hard to make that switch. Otherwise, you're straightening out so much of the complexity that you used to have in a relational database that developers don't want to deal with before, and they don't have to deal with when using MongoDB. It tends to be oftentimes a real pleasurable experience to make that sort of switch. What are the hidden costs you should be aware of, and what kind of skills do you need in-house to be able to use and sustain MongoDB? Do we need super good engineers to develop apps using MongoDB? You wouldn't have bad engineers doing any sort of development, but I guess that's pretty obvious. Like I said, MongoDB is pretty easy to use. There aren't a ton of gotchas. There are obviously like any technology. There are things to consider, but one of the things MongoDB is really around the ease of use. From the pop-up standpoint, we find that current DBAs and Linux admins really have no problem picking up MongoDB. It's not that complicated. You're still looking for the same types of things like index and query optimization. You're still doing the same types of things around backups and upgrades, and you're still doing the same types of things around backups and upgrades, and all that. And we also have an ops best practices guide available on the website for download under white papers and data sheets. So for anyone who's interested in that, please feel free to download that where we are in a number of those best practices. But a lot of folks find that really they can take resources that were previously devoted to relational database development and use them for other projects because they don't need as many devoted people to develop and manage against MongoDB. So as an example, Telefonica was being a user data management system with MongoDB. They spent 14 months with seven developers trying to build a system that ultimately didn't work. And then in three months using three developers they were able to get it to work pretty well, very well in fact with MongoDB. So I wouldn't be concerned about the ability to find folks that can do the development. It's relatively easy to pick up and there's plenty of knowledge and resources out there to ramp up your team. Some applications someone would ask what are some popular applications that use MongoDB other than the one that I've mentioned? Foursquare runs on MongoDB. Disney runs its entire gaming on MongoDB. MTV runs all of its content management on MongoDB. I'm getting into some customers I'm not allowed to talk about. Craigslist of course uses MongoDB. Guiltgroup runs on MongoDB. EA uses MongoDB heavily. Harfax recently migrated its entire business vehicle data management system over to MongoDB. And then unfortunately some other customers that I probably can't talk about as much. I think that's all the time we have for today. But like I said my name is Graham. You can feel free to email me with any other questions if you have them or if my email is now up there. It's gian at 10gen.com. Please email me with any other questions on MongoDB on something that I said in the webinar or anything else about 10gen. Graham, thank you so much. This is a great presentation. And thanks to the attendees for being so active and with such great questions. Really some great information coming through. And just let everyone know I will be sending out an email to everyone with links to the slides and links to the reporting of the webinar and all of that. And I'll send Graham contact in between as well. So you'll have to scramble right it down. I'll make sure you get it. Graham, again, thank you so much for this great presentation. And thanks to 10gen for sponsoring the webinar. And thanks to everyone for attending. Everyone has a great day. Thank you. Thank you.