 So one of the things I talked about this morning was how to help people get the most out of this conference. And one of the things that you're kind of overwhelmed at is that you're in this room with really, really smart people, and they're all kind of intimidating. So one of the things I suggest is just go up and talk to these people, come up and introduce yourself, tell them the types of problems that you're working on, and I'll bet you they're going to be very interested in telling you how they would approach your solutions. So there's so much brain power here. There's being in a room full of PhDs and query theory and things like that. It's just intimidating, but they're all friendly. So I just encourage people to walk up to people, get conversations going, and we kind of see that right now. Everybody's very approachable. So my advice for anybody who's never used NoSQL before, the best place to start is to really pick up a good book on the NoSQL patterns and understand the major architectures and some of the business problems that they're really good at solving. Our book is a really good place to start from. One of the things I think it's best to do is start to look at some of the case studies. Our book is full with a lot of case studies, and this conference, a lot of the material has good case studies of people who have real business problems and how they're using NoSQL solutions to give them a competitive advantage. And these are often places where the traditional SQL systems simply can't meet the scalability or extensibility or agility guidelines that they need to be competitive. So start out with a good book, look for case studies, and then talk to people in your community about other people in similar situations. This is a great conference for you to network with other people in similar regions that have had those problems. So our new book is called Making Sense of NoSQL, and it's really written for people that have had no exposure to this field, but people are coming up and saying, what is this new field and why should I care? And it's a very general overview for people that are interested in the topic and the architectures and the trade-offs. We spent about a year collecting case studies and interviewing different people that have used to solve different problems. It has a lot of focus on pictures and diagrams. We've collected a lot of metaphors to help non-programmers and non-tech people understand some of the biggest benefits of moving this architecture. We introduced the core patterns, we introduced the terminology, and then we go through a lot of case studies of different business areas. We talk about problems in big data, problems in search and retrieval, problems in high availability and problems in agility, and trying to bring it all together and help you pick out a method for selecting the right NoSQL database for your business problems. So yeah, so in addition to the traditional patterns of relational databases and analytical databases, the NoSQL movement has brought four broad new patterns. Key value stores, column family stores, graph stores, and document stores. Each of them are a little bit different and each of them have a unique property that they have ways that you can scale using a lot of different hashing and caching techniques to work on clusters of nodes that share this data and still provide that reliability and availability that you need in a system that never goes down and always has scalability as you add more nodes to the cluster. These four new patterns really aren't designed to replace the high-quality transaction control that you'll get in relational databases, but really designed to complement those so that you can build hybrid systems that integrate all those together and the four new systems are really ways that you can bring out the most in a very cost-effective data center if that data is in the cloud or if it's posted on your site. There's many different solutions to solve different business problems. So if I was going to have to provide a brief explanation for each of these patterns, key value stores are unique because they have a very simple architecture. Given a key, you'll present a return of value and that value can be any byte stream that describes a chunk of data, a lot of data. Key value stores are very simple, they don't need it for your language and because of that simplicity, it's very easy to scale them to very high qualities of service level signals. The second pattern, column family stores, is similar in the way to key value stores, but the key is really composed of two pieces, a row and a column, just like a spreadsheet. You'll use that, but we have then what's called a sparse matrix system where you're going to put a blob of data at the intersection of a row and a column. And the beautiful thing about this is you get the same scalability of key value stores, but you get a more fine-grained control over selecting the items that you need by specifying column and row information. The third pattern, graph stores, really excel when you have a network of information where relationships really dominate the type of information you have. Graph stores are unique because by doing traversals of these graphs and not just traversals of small sets, but you can traverse millions of nodes every second, you can search for patterns in these graphs that you couldn't search for by storing it in traditional relation databases. The last data pattern that we use, document stores, is really kind of one of the most popular and the most flexible. And by using a document store, you store your data in a hierarchy of nodes and those nodes are all grouped together in a natural collection. So your invoices and your sale orders are actually going to need containers of documents that represent those sales transactions. Document stores are great because they completely eliminate the need to take these natural documents, shred them up and put them into rows and columns, and reassemble them. They all live together in the database, so you can have very clean and fast and cashable interfaces between the people who are storing the documents and fetching those documents. So each of these patterns exist and they're separate, but they have different problems that they excel at.