 I just wanted to introduce our last speaker. Everybody knows that we have a lot of companies representing the graph store movement, and I think we are very fortunate to have Emil here. Even though we only have about 15 minutes, I think Emil has some of the best expressions of why graph databases really fit into the selection palette that we need to have for NoSQL systems. So, Emil, I'll let you get to it. Awesome. Thanks, Dan. All right, we're running a little bit late, so I'm going to be fast. My name is Emil Afrim, and I'm going to tell you a story in 10 minutes. But before that, I'm going to start with the ground rules for this talk, which is very simple. I only have one ground rule, actually, for all my talks, and that is I do not want your undivided attention. You guys are all online, you have laptops. This is a unique conference so far. It seems like the Internet, the Wi-Fi is actually working. So use that. Go online, tweet. I like my talks, generally speaking, to be interactive, but we only have 10 or 15 minutes. So I'm going to ask you instead to give me any comments, questions, et cetera, on Twitter. The only thing that I ask of you is that you use the Neo4j hashtag for anything, because I monitor that one religiously. All right, so I'm going to tell you a story, and it's the story about our industry. And it starts in the good old 70s, back when the hippies ruled the world, and which was sort of the infancy of our industry. Back in those days, there wasn't really a computer consumer industry out there. It was mainly all business-to-business or enterprise, i.e. companies using computers. And so the big thing that we tried to do, the main objective that we tried to use these computers for, was to sort of digitalize work processes. We wanted computers to be the, what did Steve call it, the bicycle for our mind, right? Help us amplify and reduce repetitive tasks. A very common thing might be that you would take a form, a work process that includes a form written on paper, and you want to computerize that. You want to digitalize that. As an industry, we built a tool chain around that. And that tool chain, of course, was adapted to the applications that we most commonly wrote. Forms are very tabular, very square, very well-structured. It makes sense then that the tools in the data layer exposes a tabular abstraction, a tabular representation format. It makes sense that they're very good at storing these objects and retrieving them. But that's pretty much it, storing the objects and retrieving them. Seems pretty simple. It turns out that a bunch of big companies were built just around this tool chain. This is Oracle as an example. $150 billion market value, give and take, a couple of billions. And other companies like Oracle grew up around this age, basically focused on digitalizing objects. They ended up being a lot of value, it turns out, in just digitalizing these physical objects. You can communicate them easily across the world. You can duplicate them for free. All those good things. Fast forward and look then at a couple of more recent examples of things, or people that have created a lot of value, recently in the world. We have the picture on the upper left hand is one of my favorites. That's Mark Zuckerberg, probably three years ago or something like that. I'm in his dorm in Harvard. He built, of course, Facebook, which it's always funny to be in the Silicon Valley bubble I just moved here. And he's being described now as a failure because he only created $50 billion of value in the course of less of a decade. Another couple, two entrepreneurs that built the most profound, I would say, company of the previous decade, Larry and Sergey. Jack Dorsey and Biz and Ev, who built Twitter. And if you look at a common pattern that these guys have used, we look at Mark Zuckerberg. The genius of Mark was not so much that he just stored that individual object, stored Tony's profile on Facebook, and stored my profile on Facebook, and stored it and retrieved it the way that we did in the previous generation. That was not the big thing, but the big thing was that he stored the connections between all these objects, right? How I relate to all my friends and all my ex-friends and all those good things, and how they relate to the world and to everyone else. The social graph is what he called that. What Larry and Sergey built their revolutionary search engine on was not to just store all the webpages in the world. They did store all the webpages in the world. That did everyone else all the other search engines. There was probably 50 or 100 search engines around at the end of the 90s. They did all that. They tried to store all the webpages in the world. But that was not the big thing. The big thing is that they stored the connections between all of these webpages, what they called the link graph. Jack and Biz and Ev said that, hey, let's not just store the tweets, you know, short text messages on the web, but actually let's store what people are interested in, who other people are interested in, the connections between them. So the common theme between all three of these entrepreneurs or entrepreneurial peers is that they figured out one thing, which is that graphs are everywhere. And this relating back then to Tim's previous talk, this is my form. This is my opinion. This is the way I look at the world. And these guys did as well. And they saw that if I am able to store and process these graphs, not just the objects in and of themselves, but how they relate it to the world that can unlock a massive amount of wealth. So graphs, when I talk about graphs these days, sometimes people understand what I'm saying, but more often than not, they get, you know, you talk about charts, Excel charts, for example. So what are graphs? A graph is basically a data structure which includes nodes, type relationships between nodes, and then key value properties that you can attach to both nodes and two relationships. That's a graph. And Tim mentioned social graph, and I mentioned social graph just recently. That's probably the most common and the most well-known graph these days. But there's nothing inherently social about graphs. Graphs can store anything. It could be chairs. It could be computers. It could be anything. In fact, examples of graphs in the real world, these are some customers of Neo4j that are using graphs to transform the way they do business. One example is network management in telcos where the nodes in the graph represent routers and cell towers and whatnot and the connections describe wires between all these things and they use graphs to figure out that what if this router over here goes down? How is that going to impact the entire network or the graph, right? Another example is content management. We have a talk from Adobe later today where they're going to talk about how they build basically a content or asset management system using graph technology. In here, the nodes are folders, but it turns out the nodes are content object, but it turns out that just the actual content is only one part of the saga when you work with content management. How that content is related to the world, which folders it belongs to, which people have access to it, et cetera. That's all part of the important thing that you need to capture when you work with content management. There's a bunch more examples in logistics in telecom. Once you start looking at this, you see that indeed graphs are everywhere all over the place. All right, so if then you have a bunch of data that is very graph-oriented, how do you work with them? Well, that's the wonderful thing about NoSQL, right? NoSQL fundamentally, we talked about scalability and a bunch of other things, but I think fundamentally NoSQL represents choice. We're now out of it. We are at the point as an industry where we can finally choose the right tool for the job. We can look at the shape of our data and we can find, you can look at... This is very key value-oriented data. Let's take a key value store for that. This is very document-oriented data. Let's take a document database for that. But this data is very connected, very complex, very graph-shaped. Awesome. Let's choose a graph database for that. And graph databases are currently taking off. In the past 12 months, we've seen an explosion of graph technologies being launched. At Neo4j, we've actually been at this for a while. We started, believe it or not, in 2000. So this is our 12th year working on graph databases, but it's very interesting to see how there's now an explosion of tooling around managing graphs. An analyst from Call Forester wrote a blog post in December where they talked about top three trends in big data and one of them was graph databases will come into Vogue. I'm not a native English speaker, so I actually had to Google what Vogue means. It means be in fashion. So I thought that was very nice to finally be in fashion for once. And they talk about how graph databases, the market for graph databases will boom in 2012 and goes on to say that graph analysis is the true killer app for big data. People have mentioned that graph databases may have a bigger impact on the database landscape than Hadoop. Okay, so a story. So we were contacted by a big social network a couple of years ago, and they said, you know, we've tried to use a bunch of no-sequels. We love no-sequels. We love key-value stores. We love document databases and calling family tools. But as we start using them, we look around at our data and we see that it's very, very connected. In fact, they use the words that when we look at our architecture, you know, graphs are everywhere. And so they said that, you know, we're sort of looking at graph databases. But, you know, we're big social network X and it turns out that the only thing we really care about is performance. So they asked it for a benchmark. And I had heard Tim Berglund give a talk about how benchmarks were even worse than statistics. So us being the honest geeks that we are, we said that, you know, come on, guys, we can prove anything with benchmarks. So how about you give us a scenario that's relevant for you guys and we'll show you, you know, how fast we are in that scenario. And so the scenario that they gave us was that, imagine that you have 1,000 people. Every person has 50 friends on average. You grab two people at random and you check if they're connected. Not even how they're connected, but if they're connected. You can imagine a Facebook, you know, a network like Facebook, for example, use that every time they render the news feed. So it has to run at real time multiple, multiple times per second. Probably thousands of times per second. So that's kind of the response that they need. We ran that using MySQL. Grab two people at random like this and the average response time for that query was 2,000 milliseconds. 2,000 milliseconds. That's enough that you can't use it at runtime. In Neo4j, this was a 2 millisecond operation. It's 1,000 times faster. So that's kind of cool. But it's also sort of the promise of no SQL, right? Once you choose a tool that is adapted to the shape of your data, you're supposed to get those kinds of performance benefits, right? So we upped the ante a little bit. We added not just 1,000 people, but a million people. And this is all on actually not on this laptop, but on my previous laptop using a 300 megabyte heap. A million people, 50 average connections, so 25 million connections in total. Grab two people at random and check if they're connected. So at that operation, Neo4j still performs at 2 milliseconds. I usually sum this up that we're 1,000 times faster than MySQL and 1,000 times as much data. Obviously, that's not true in the generic general case. But this shows the power of if you have a lot of data that is very connected to use a tool that is purpose-built for that kind of data. So today is the graph database day at NeoSQL. Now, that's not what it's called officially. Sorry, Tony. We almost called it that, so take it away. I didn't know he had a mic. Otherwise, I would just proclaim it as the graph database day. There's a bunch of graph database session. I hope this very, very tiny little intro has whet your appetite for what graph databases can use, can do. There's multiple graph database vendors here today. And there is, I think, what is that, six or seven sessions specifically on graph databases. A couple of ones that I would plug are the intro to graph databases with a venerable Andreas Collager, which is in about 20 minutes at 10.30. It's an amazing intro. Going to one of Andreas' presentation is like poetry. So if you're interested in graph databases, that's a great one. We also run a lunch and learn, where you can eat and learn about graph databases at the same time. Also, I'm wearing a t-shirt right now. Sorry, a t-shirt right now, which has GraphConnect. There's a conference coming up in November, November 5 and 6, which is all about graphs. And it's going to be an amazing conference with speakers from Twitter, from Square, from Adobe, from Cisco, where they talk about how they use graph technology to transform the way they do business. It's going to be an amazing conference, very affordable. You should definitely check it out. I want to end this little really brief. I have 24 seconds left with a quote from one of my actually favorite guys about NoSQL in general. It's a guy called Julian Brown. He's written some of the best treatments on high-scalability that you can find anywhere on the web. You can Google him. He's fantastic. But he talks about giving all these arguments about acid and scale and the cap theorem. It's just more human and agile to be graph-based. And I thought that was a great way to wrap it up and summarize it. So, I want to urge you guys now that you go out into this wonderful conference to be more human and be more agile and be more graph-based. Thank you.