 All right, I guess it's time to get started here. So before we start, I'm curious a little about the people in the room. How many of you all are already using Node SQL? OK, it's about half. And then how many people in the room are mobile developers? OK, so about half, they're not necessarily the same half. That's anytime in the right room. So I'm a co-founder of Couchbase. I've been working on technology for about four years now. And over the last few years, the key period for users, one of the things that Couchbase has done well is stay above the competitive parade with all this Node SQL action that's happening right now. But our 2.0 release is our beta of 2.0 that was right around the corner. And so it's time for the gloves to come off. It's time for you to competitive. And the best way to get competitive is with a wrap battle. So I'm going to start this with my wrap battle and then end it with my tech. So you might find also in the lyrics that Couchbase is a abbreviation for mobile music. So cluster up on, stop, bubble, commodity hardware, allocating so enterprise, low latency, maximum cash D. Watch the disk, write Q, Couchbase keep it clean, index your data with JavaScript, hit a couple lines of code, pick the keys you admit. For 809.1.1.1 to 11, for Couchbase, data is a serious obsession. Simple, fast, elastic, synchronizes, sizes to your workload. We are the reliable beings. So I hope to hear some of the other simple winners with their raps soon. That's all in another series. So mobile. Mobile is different from what's come before in the web. And I think these are the big four differences. I'm just starting to believe over the rest of the web, but I really see mobile as leading this growth. There's a whole different environment in which apps can grow. And if you've got mobile app, you're talking about different dynamics for user acquisition, and it can be more challenging to scale than the web dynamics that you're maybe familiar with. Speed, right? The mobile devices, it's in the user's hand, and so it's therefore more personal, and they're gonna take latency much more seriously. If your app is slow, they're gonna feel that in a way they might not if it was on their desktop. Flexibility. The mobile world is inherently harder to control than the web. And the web, you can run software update, and all your users get the new software. On mobile world, you don't have that latitude. You may have software that shifts on carrier handsets that you have no control over. You may have software running on old iPhones and new iPhones and a rolling upgrade with that you don't have much control over. And then the last thing that mobile's really brought into the mainstream is push, and the need to send messages to the user where they are based on and some of it that happened in your cloud. So that's what we're gonna talk about today, those four topics. Growth. Again, here's some numbers to give you an understanding of just really how big it is. There's 2.2 billion internet users. 50% of Americans use smartphones. So that's not even your regular mobile phones. And you're having to go over that and look at some examples of that. So these charts here are showing in smartphones, that's the breakup of 50% of Americans using smartphones, and most of them are on Android and iPhone. This graph down here in the corner is number of mobile game players and social game players, that's hundreds of millions of people right there. So there's a lot to be ready for when you're scaling your mobile app. For instance, Instagram, this is a graph of their monthly active users from just before the Facebook acquisition. So they launched on Android and they gained a million active users, literally over that. They were able to take that because for them it was only a small amount, I mean it was a minimal fraction but it was sort of ready for it. Still, there's all these people ready to run your app and they can install it and now your traffic is up at that next level. So I want to redefine the units here. For a while people were talking about an Instagram made a billion dollars but with the recent stock market action that doesn't really quite hold anymore. But I still think it's fair to look at the amount of traffic they were pushing at the time of acquisition and call that an Instagram. So an Instagram is 7.5 million monthly active users. And by that metric, Instagram itself is up to like three or four Instagrams already. They've been growing. So nothing holds still here. But now that we know, on Instagram that's about as much traffic as a billion dollar web service pushes we can use the T8 other stuff. So who here has played the game draw something? That's probably more popular outside of this room but I know that I played it with family members and it was downloaded by 50 million people in the first 50 days after launch. In the first two months it scaled to five Instagrams of traffic. And I'm here to talk about how they did that and how it's gonna be. So let's zoom in to the beginning. The beginning of this stuff is the hard part, right? You're already over the hump. You know your game is a hit. You know your site is a hit. You know your app has a business case. You can scale that. That's all the problem. It's the part where it's a surprise that you have to scale that is really interesting here. So we can zoom in on this chart. The larger context of getting the 35 million monthly active users is that orange line that the first three weeks here are these data points you can see. And so what happened was draw something was out there was getting modest traction but nothing really huge. And then they got on TV. So the answer is if you want to have a hockey stick broker get on television. But the other thing they did is they were ready for it. So there's sort of a phrase that goes around in the online gaming world of escape velocity. How much traffic is this app gonna get at its peak? And then there's a whole science that's figuring out what that escape velocity is early on. And then the only thing that really throws a wrench in that science is that the faster your app is growing the more likely it is to crash and burn. So it's essentially the apps that have a really high escape velocity that don't crash and burn that turn into $200 million properties. So how do you keep crashing and burning in that crucial window? That's a $100 million question. And underneath all that traffic what does it look like to the database? It looks like 5,000 drawings per second. And this isn't even the peak this is just around the time of the single acquisition of draw something. And over 100,000 database operations per second and a few terabytes of data. It's grown since then by at least amounts. But even at the acquisition that's some pretty heavy traffic. It won't let me tell you exactly how many servers they were rolling on. But it's not like as many as you would expect I think because catchphrase is pretty fast. By contrast this is what can happen if you get it wrong. They got everything right. They got everything right except for the $100 million app where the game took off faster than the back end to handle it, the game performance started to drop and they had the full game from the app store. So your worst case scenario isn't that nobody ever sees your work it's that everybody wants to see it and then you have essentially technical difficulties and go out of business. So don't let this happen to you. So growth is very critical to getting these games right. Speed, it's a different angle right. You can have something to grow as well not all that fast. You know something that's super fast that doesn't really scale. But if your thing's gonna grow a lot it's probably gonna be fast in the first place because there's so much research out there that shows that users' response does speed. So users don't like to wait. If you've ever been in this situation, I've been in this situation and a lot of times by the time this happens I've forgotten why I was even running that search or I went off and checked my email and said that the loading bar anytime your back end is being slow for your users it's a good chance for them to go somewhere else. So don't let it happen to you. And there's a lot of objective data to back this up. So even going back to 2006, Google was running experiments where they would extend the number of search results on the front page instead of showing 10 results they showed 30. You think oh that's fair, right? More richness there. Try to drop off measurably because it takes longer to render 30 results at 20. And users care about being able to iterate on their search it's not to scroll. So this is gonna show up in pretty much every application you look at that's interactive where users are connecting to the cloud. There's been more research if you follow that link, the cost of latency. Amazon has done research to show that it doesn't take a whole lot of slowness to have the user essentially get that bad experience once maybe just one page request but you've poisoned your brand to that user for a measurable amount of time. So again in mobile and this is really talking again about the growth question but in mobile you don't know when the fundraiser is gonna hit you don't know when you're gonna get talked about on television and then there's this hatred of business. So are you gonna invest equally in scaling all your apps or are you gonna wait until it matters? And it used to be how to invest equally right in all of them because scaling is hard but hopefully you can ride that curve a little more closely and save some money on the way up. So what counts as fast? This is a benchmark, I guess the numbers are too small to see here with at the slowest of that graph it's just half a millisecond. And that's with your standard kernel kind of slow internet cards with the 10G internet cards and the user space drivers slow on this chart is 150 microseconds. So this is for as you go to the right on the latency chart but the payload is getting larger. As you see it's even flat there. This kind of sub-tonal second latency is good for keeping your users engaged where it's really important is it has to be a time-based service level if you're doing advertising or those kinds of things where you have a contract that says you're gonna turn around the whole thing in 20 little seconds and your database better not be a big part of that in a new one. So a very interesting thing from this Cisco benchmark is that as they add nodes to the cluster the throughput goes up better than linearly and that's not gonna continue to happen all the way up to an infinitely sized cluster but CouchBase at least opens up someone between five and 30 nodes. You get some benefits, right? It's less crowded, each box is doing a little bit less busy work and more day to work. So it's nice to see that that shows up on the graphs as well. Can you show them the number on the table? Sure. Yeah, yeah, that just tends to hold the seat. I'll just walk down here and look at it. I think we're talking about three node cluster is about 3,000 ops per second and five node cluster is about 1.6 million ops per second. When you say nodes, is it between shots? I mean, I forget exactly what hardware they were running here. But the shots are? No, these are visual boxes, I think they had SSDs. I'll get into later to talk about CouchBase, spread your data across the cluster. But essentially, you can just throw boxes at your cluster and you get groups like this. So, you might have to scale in a hurry. Hopefully it's a surprise. One of the key points I really want to make here is not a technical point, it's a sort of a business or organizational point. When you get on Jersey Shore and all of a sudden you have 20 million more app downloads than you did yesterday, you don't want to be thinking about scale your data layer. You want to be thinking about all the other good things that come with that. So, that's why we encourage people to get out ahead of the curve and be ready to scale rather than get hit with long nights and potentially tell you the truth. And I don't have the time to just talk to it, actually do a demo and bring up screens and stuff, but part of the reason is why operations folks have the success they do with CouchBase is that it's been built from the ground up for operations. A lot of the times, at least I've done enough of going into the organization and describing the database, you can get the developers excited about it. Oh, look, some neat new capabilities, oh, isn't that fast? But it's hard to sell it into ops because these guys are on the disks, they don't want to do new stuff. I mean, they have a good reason for that. But if you get the right technology and I've seen this happen a lot with us, talk to the ops team, the ops team will turn around and sell it to the developers. It says, oh, you can do a hop backup without downtime. It does the various things they want. You give the make ops team happy and they don't make the developers happy for you. Feature that is necessary, if you care about low latency, is this cross stage center replication, where you can have multiple points of presence that are all asynchronously communicating. They're gonna have longer latency between clusters than you'd like to have between your app server and a cluster. But this means that you can offer low latency to people no matter where they are on the world and give them a roughly consistent snapshot of the whole dataset that the other users are seeing. So this feature will be new in CouchBase Togato and we think it's a big differentiator. Flexibility, I mentioned earlier that mobile apps have a different upgrade in the last cycle than web apps. Web apps, you just hit deploy and maybe you have a rolling deploy that takes 10 minutes, but you don't have a rolling deploy that takes a few weeks while users consider it to be upgraded. So if you're gonna be talking to these old clients out there, they're sending you old schemas over the wire, it sure is helpful if you don't have to enforce a rigid database schema. So JSON is, I'm gonna assume everyone here is comfortable with JSON, other audiences may be new. But the key here is that you just put your data structures that your application server deals with into the database. There's a bunch of benefits you get from that. Flexibility of course being a key one, but there's also performance benefits become purely just by using a denormalized approach to data access, right? Martin Pollard in his book calls it aggregate oriented. So when you have these aggregates and you're interacting with the database in terms of aggregates, now the database has visibility into your data access patterns in a way that it wouldn't have with a relational database. The relational database, you build a schema that has some sort of measure of correctness. Maybe it's good from a data pressure standpoint but essentially, aside from the indexes and hints you get it, all access patterns are considered equal to the relational database. With no SQL, the access patterns in your application is doing our privilege, right? They're gonna be faster because it's a much simpler operation for the rely software. And for mobile developers, I know that at least today, dealing with JSON and Objective-C is not as fun as dealing with certain other data structures. But there are some changes coming in the compiler that allow for some neat macro stuff that makes JSON inside of Objective-C look a lot more like it does in JavaScript or other kind of more scripted languages. So that's just one thing that points toward the momentum of JSON. Becoming the default, I think, maybe I'll already say it has, XML will be around for a long time, but JSON has a lot to recommend it and not the least it wishes the fact that developers seem to like it. So if when I was talking about scale and speed, that's just a little bit, oh, I don't really care about that. Some people, so it was we that started it. And we thought that the number one reason that no SQL users were interested in no SQL was scale. And we thought the number two reason was performance, the speed. But it turns out that all those are important. The number one reason that people get into no SQL is because they want a flexible data model. They don't want to deal with scale migrations. So that was a learning experience for us. And I don't have that much of a surprise, but I like to point that out because the sort of softer reasons for doing things get left behind, right? Talking about business, it's a total cost of ownership, but having happy developers is worth a lot. So one kind of unique strength of the counter space query model is the ability to query messy data. A lot of the JSON IC is just like a big bag of a mess, right? It's just somebody import this API into the database and they came along and put this API in and then this API has an inversion if you're just gonna keep importing into the same container. And before you go, there's just mess. And so do you want to have a bunch of code in your application that's job is to figure out the different versions of JSON that you stored and what's the right way to display this? And does this field null to an empty string or should it be left out? And of those kinds of questions, it's nice to have those live in one place, but it's actually in the relational database world. The database has been in charge of those kinds of questions. And with counter space, give you the opportunity to do that as well. So the query model uses JavaScript to inspect your data and figure out how to index it. And aside from that, I call it macros and I call it JavaScript and both of those things are gonna sound kind of different from the relational model. Really, we're talking about alter table add index. So you write alter table add index and you put a SQL expression on the end of there and it drills into your table and it makes this column or these two columns and now you have an index. So we've all done that. With mac reduce, you're doing the same thing. You have a JavaScript function that's drilling into your document and figuring it out. So let's say you have held the tickets and you want to sort them by date and the user ID or user ID date, right? So your old held tickets were just something typed into a Word document and your new ones are structured based on there's some stuff actually between in your history of things your application has done over the years. You can write this one function that, if doc.body is made in our upstream, run regex to extract the username and the timestamp, if doc.body is nicely structured with version one, drill down here, timestamp with user ID, else is doc.body, whatever is the new structure, well then the timestamp is already in format, we'd like to have to convert to timestamp format, say. So you can have that kind of complex richness of extracting the salient information from messy data in the database in a way where it will maintain the index for you. So this allows what I would say, normalize after the fact. So say what you've got, capture the user's intent. Don't worry about cleaning up the data too much on the way in. You don't want to save fraudulent data or users who haven't logged in or put the wrong user ID on something. Those are application concerns. But your application doesn't need to be concerned with how the data used to look or how it looks now and how it's going to look in the future. You just want to save what the user gave you to the database and then normalize it every time. And because of that, you're essentially compatible with all the existing days on APIs that are out there. You could go type from Twitter to college base and then reformat it so it gives the same output format as the Flickr API because you already have a bunch of Flickr data in your database. So that's really flexibility in a nutshell. This is some of these topics I won't get to go back to later in the talk. Folks have questions about that. This is a good time. Is it important that any kind of map reduce? Yeah, so that's, I didn't say incremental map reduce, but that's what we do. It's, that's why I say, alter table add index. You define an index we maintain for you and queries around it to do this. And the details are the index is maintained behind the rights. So like in a relational database where you have like some form key indexes that need to be checked before the right commit, we just write it. And then the indexer, every time there's a query, it says I need to bring myself up to date for what's happened since the last query. So push, push is the last of these things that I see as being really kind of new in mobile. And we all know it is your application or your cloud, your application is everything from client all the way to the cloud, is somewhat context aware or event aware and can give that information out to the user in a timely manner. So this is just a little bit of a tease for upcoming functionality in 2.0. But as I mentioned earlier, we have the cross data center replication capability and I'm an engineer. I don't like for one piece of code to just do one thing. That's in stream that keeps your other data center up to date. You can hook whatever onto that, right? Your code onto that stream and gather events. So write stuff over the database, you have an entry coming off the database and you're able to convert that into push notifications. And it's as simple as, in this case, an onchange function or if you're an ADM, it would be a different language, right? But you just kind of end feed and things are happening in your code because things didn't happen in the database. And then avoidance, you know, you having to do something in your application server that really should have an asynchronously after the data is committed or if you want to have a cluster that's hooked up with the across data center replication to other clusters and these are all in your live traffic and the data flows to a cluster that's essentially just back into event processing. And the same events will eventually come through that queue as well. So the question is, can your database do this? And some can, some can't. I would almost say that this is strictly the domain of CouchBase, but it's easier to do these sorts of things with no SQL, that's for sure. So now, to take the last two minutes of the presentation and just kind of give it an overview of CouchBase. We pride ourselves on being simple and that goes so far as that the current release version 1.8 is strictly a key volume interface. You talk to a given cache deep protocol. All the glory capabilities, those are coming in 2.0 beta and they're developer preview goals available of 2.0 of now. So we keep it simple. Use protocols that you already have in your data center. Fast of course, that's where, at least we make our money, right? Is that if you really need to be fast, there aren't a whole lot of other options, especially when you may have to grow in a memory as a surprise. That said, everything we do is open source. So most of our users don't pay us. Now, the traditional database, maybe I'm reaching an inquire here, but who here has ever had to just give a bigger and bigger box on their database until they gave up? Yeah, I think that's how I got into SQL in the first place. So, scale out your data layer, like your application layer, of course that's what we're all here to talk about. So let's look at how CouchBase does it. So here I've got two application servers and three database servers. And the documents are spreading evenly across the database servers. And now each application server is gonna be aware of the cluster topology. So reads and writes will go directly to the data nodes that own the data. As we see here, the document number five is under heavy mutation for multiple application servers. Maybe that document itself is, you know, fueling 100,000 updates per second. You can use CouchBase for a strong agreement because there's a single physical owner of any given document at any given time. So you've got these application servers interacting in this document. And if they're, again, the thing to note is that they're not going through a proxy. The application servers are topology aware so as the document moves, they'll go make a direct connection to the new home of the document. And we'll see how that happens as you add nodes here. So now we're gonna bring two additional nodes online. What CouchBase does is rather than as you add a node, now it's participating in the traffic and then kind of have this, you know, problem of adding nodes and the rebounds kicking off right away, instead you can join nodes to the cluster. So say you have a three node cluster and you throw 10 more nodes on there and nothing happens yet, except before they become aware of each other. Then you press the button and they all re-balances at once. So this prevents you having to do a bunch of little moves that allows it to be much more efficient. You could even say have a five node cluster of version 1.8 and add five nodes of 1.81 and remove the old nodes in a single operation. So that's how people will do upgrades. So what'll happen is they'll figure out the right way to move the data. The granularity of the way to move the data is some of the earlier ruck shards. We call them V buckets, virtual buckets, let's call them shards, doesn't matter, right? It is what we do is we pre-shard the data into 1,024 slices and then we put those slices evenly on the servers you have. So you have one server that's got all the slices. If you have two servers, they each have 512 and as you add servers, we're just moving slices around. So you're not going to have more than 1,024 servers that hasn't been a problem for us yet. And so as you're moving these slices, the client libraries, all they have to do, they don't have to know for each document where it lives. They just have to know for each slice where it lives. The mathematics or the hash function from the document ID to a particular slice is strictly known by the clients. So we've re-balanced the data over and what will happen is, well there's kind of a popular code classic happening depending on what your client libraries look like, but basically, we'll start getting the data and the location without skipping a beat in the best case. And in the worst case, it will make a single request that fails with a, you know, my shard has moved error and then the client resets itself and gets the new cluster back. So you may be talking about, set state one millisecond latency and then on rebalance per application server a two millisecond latency once for each application server. And so now we have those same application servers are aware of the documents and looking directly at the new locations. Things aren't always that easy, right? What happens if you're talking to a node that goes away? It's not fun when it happens, it's hard for our server to go away. And so, in our older versions, we didn't do anything. We just got sad through errors and then the errors made it clear enough that the user, the administrator should press the fix button and fail over the node. Now we have auto failover so if it detects a node that's missing for longer than the time I specify, it'll do it for you. And there's some nuance there, I don't want to cause cascading failures so it won't auto failover twice in a row. But when you do failover a node, what it means is we promote the replica copies to active. And that's nearly instantaneous because the replicas are already in RAM on all the other nodes. So you flip a bit and now they're promoted to active. And we republish the cluster map and the clients will go reach the data at the new location. So that's the essentials of how failure recovery happens. And there's all kinds of pathway failures. The node going away is almost easier, right? It's kind of more interesting when the node is still there but not really. For instance, Amazon, elastic watch store a few months ago had a cascading failure and the symptom was these storage devices were no longer accepting operations, read the rights. And so now your data's not gone, it's just inaccessible. Well, a lot of the internet was down that day. We saw outages from various high profile properties. A lot of the cloud space customers were minimally affected because any user whose data was already in RAM, it was already in RAM, the rights grew up to disk, oh, this disk is very slow, right? That's what cloud space saw. This disk is just frustrating and slow. So the right view backs up. And of course, any sessions that were not currently active, right, that weren't in the working set, they're unreachable. But a lot of Zincos games stay online during this because the data that mattered was already in RAM. And then when the disks started being operable again, that data would flow down to the disks and it was as though they hadn't had an outage except for that slice of users who tried to log in and establish a session during the last block storage. So there's just a couple of examples of mobile usage here. One of our customers is Concur. They do expense tracking. For them, the big challenge is how do I track millions of receipts as they flow through workflows? The JSON document model is really nice for workflows because you can just take the data that you've got and then tag it with different states. You have more than one state machine floating along on the same document if you want to. Makes it really easy. Anything you do on paper today or 10 years ago, right? It's a great fit for an document out of this. Another one of our mobile use cases is NTTDocomo. They're the largest mobile provider in Japan and they use us for some heavy data analytics stuff which is pretty interesting. I guess we've got to help them get it. And this is a lot more, and it's building a partial list with, not all of these are mobile. I wanted to get a slide with just people who use kind of a sort of mobile backend. So hopefully we'll see that soon. So we're running up against the end of time here. The last thing I want to make sure everyone knows about is that in San Francisco, on September 21st, we'll be having an all day couch base event. So please join us there. Speakers are gonna be interesting. It's a lineup with a bunch of enterprises that are doing serious stuff with high velocity data. So with that, I'd like to open up for any questions. There were physical graphics, seems like you just made coffee on wherever the rice are being written and you just made copies into a different physical note for the cherries in the case, right? So it seems like it's not a master's day, it's not like you give a replica IP address and so we need to copy. So can you tell us more about the graphic I've done? So the question is, how does the replica system work? And the way, I'm sure we have the data in 1,024 slices. So you can set the replication factor for the cluster. Typically people will run with one or two, we have the option of running three replicas, but that's gonna, he had a lot of ramp, right? So every time a write comes in, it hits a node. That hits a new cache heap and it commits it to memory and returns to the client by default. And so that's as safe as a new cache heap now. But what you want to say for, you want a replica safety. And so the very first thing that I've accepted that is it gets in queued into a couple of queues, one queue for disk and one queue for remote. And so that will stick it on another node of the cluster. And if it got here in one millisecond, it'll get here in two or three milliseconds. And so, and that can be one replica of our two or three. Now the reads and writes, it's a strongly consistent system. For him, the key, the reads and writes always go through the active copy. And so then we fail over atomically to a replica when we need to. So the replicas are hard to analyze. They're never live, read, write, copies. Whenever they read, it's gonna go with a master copy of the latest copy, right? If you don't read the replicas, until master fails. Exactly. Yeah, we don't read the replica because it's over, we'll interact with them. But for the scalability, don't you think that's a good practice for the replicas? There are many reads, it's an interesting problem. Where it comes up for us is that when you get clusters larger than 15 nodes each, that's when you're gonna see nodes falling out of the cluster that aren't dead and then they come back. And as people know, failure is gonna be less than 30 seconds. So it's kind of gone and then it's back. And when you have those kinds of scenarios, that's when you really want 30 reads, or even 30 writes. And so we are planning on that sort of thing in a future release with taking inspiration from some of the vector block stuff and the dynamo stuff. But we don't really think the eventually consistent model is what developers want. They wanna have consistency on a key. So you can run one of these keys as an in-cash key counter. I did a textual analysis. Toki has a text every time you say token anchored in that counter. And then on that we're just gonna get the results. It's kind of a new thing, I had no room for it. So using those keys for strong agreement is an important engineering goal for us. And that said, there's some validity, right? And the idea of a replica being different from your live data set, and it's sort of different ideas. Is a replica really there as a backup? Or is it there to maintain high availability? For us it's really about high availability. You have other stories for backup. But you can take policies and snapshots and those kinds of things. Other questions? Do you really have access from the client side or from the job side? And so then what do you handle security in terms of? So that's a good question. The question is the client access method and security. And with how much space you talk to via the in-cash key protocol? And so you're not really, it's not designed as a protocol. It's a mobile device to talk directly to your database. Our security model isn't designed to that either. We have sassel authentication and the in-cash connection layer. But that's not really what you want to do from a mobile client. And then more importantly, you're asked to authenticate into this giant game space with all the user's data in it anyway. So yeah, that's what your application servers work essentially. For security, encryption, application, or privacy? Yeah, I get the question that is about security. And in most of the time, I say all of the time, people are running these inside of a security group on EC2, otherwise they're strictly accessing firewalls. And then as far as security, what we have now is by default, if you can connect to the server, you can do any data operations. But it's possible to lock down a bucket, lock down an in-space, where it requires password for access. And in the future, we'll be adding reopen modes so that you can have less workload users. Anything else? Thank you, and come catch me afterwards.