 My name is John Webster. I am the VP of products at Grid Gain, Grid Gain Systems here, located in the Bay Area. And what I want to talk to you about today is kind of an interesting bit of technology that we're bringing to market. It is in private beta right now. So if you are intrigued in any way after we have our session together today, I would love to speak with you about potentially using our technology in how it was putting it through its paces. So as I say, we're absolutely looking for beta customers right now. So what I'm going to talk to you about is increasing performance in MongoDB from two aspects, with respect to obviously just latency, so how fast am I going, but also with respect to scalability. We have an in-memory accelerator for MongoDB, so you essentially can take your data in memory and any volume of that data that you might actually want to put in memory, as a matter of fact, you can run the whole thing in memory. If you've got that much memory space, you can proxy things and sort of cache things in front of it. And what I do away with, without taking too much from a couple of slides downstream, I address some of the challenges around sharding and I address some of the challenges around sort of volume of nodes and scale on those kinds of things. So with that, if you are so inclined, you can follow me on Twitter at that handle. You can follow grid game at grid game. And if you happen to be tweeting away, I see in the audience or something, certainly if you could use that hashtag in addition to the conference hashtags, that would be just great. So a couple of things I already mentioned in terms of challenges with respect to scaling MongoDB. We really love the TenGen guys. We're in the TenGen Partner Program. Really, really great piece of technology, arguably the most widely deployed document API on the planet these days. A lot of great stuff. But there are some challenges with respect to, as I say, some of the sharding issues when you're doing stuff at scale, a little bit of scalability on that as well. And we'll talk a little bit about what it is that we do and then just kind of give you a couple of use cases and talk about how and why here. So these are really kind of the high points, if you will. So when we put this product together, we use these things to kind of drive the design, right? So plug and play integration. I don't want anything in your application to change today. You could be using Mongo Native Monday. Use grid game Monday afternoon, Tuesday morning, go back to Mongo Native. And from your application standpoint, there is no change. Nothing changes. Zero code change and you can use any Mongo client that you're currently using today. So any variety of the various things that you're looking for. You can run in two different fashions. So dual mode deployment, and this is what I mentioned a little earlier. You can be in memory solely. 100% running with an in-memory Mongo representation of your data, very, very low latency access to that data, very high performance. Or what you can do is you can, in some respects, it's a little bit more typical for what we're seeing, is you can actually run almost as though it's a caching layer, if you will, for MongoDB sitting on top of that. So pick your databases, pick your collections, whatever it is. We see very much often there's really kind of a subset of data that you're going to want to have here in memory. And that's typically what we say. Let's put that in memory, keep it hot, and you'll have very, very fast access to that. We have a broader technology set that this Mongo accelerator leverages. We have two classes. I guess there are two types of products that could gain. We have what I'll call our core technology, our core in-memory computing technology. This has got a long heritage been in market since 2007, hundreds and hundreds of deployments around the world. And the reason that I point this out, very, very robust scalable in-memory computing infrastructure. And in terms of our scalability and the ability to accelerate, I have thousand node deployments. And again, this is what's tucked in underneath our Mongo compatibility layer, thousand node deployments around the world, multiple thousand nodes. So my point being the Mongo accelerator itself is a new product that we're bringing to market, but it's based on a heritage of over, you know, about six or seven years of engineering. So you don't get to bring this accelerator market quickly without having the investment in the core technology that we have. And certainly happy to talk about that core technology that people are interested in that. And we'll give you a, you know, just a flat out performance boost, so latency, you know, how fast I can access my data out of Mongo. And obviously give you the scalability. And we'll talk in a minute about how we do what we do. We give you full support for the full MongoDB operation. Aggregation framework is supported. Sorting and grouping algorithms are sorted. And the point I'd like to make here is that we actually are optimized for a memory first architecture. So Mongo's got, you know, pretty good scale, you know, again, horizontal scalability across a bunch of different nodes. But we are, I guess our product, if you will, is predicated on the design of memory system memory being our primary storage. So you do different things when you do that, you don't optimize for block based devices, which is where you're just, you know, where you're writing out the disks, whether they be disk, whether they be SSD, whatever it might be. There's still block based devices. It's, it's, you know, it's a different kind of optimization, different kind of things that you actually do here. So we are memory first as opposed to Mongo, which I would argue is disk first on that and other database technologies as well. We completely get rid of memory paging. And we actually give you both on heap and off heap. So under the covers, we're a Java or JVM based technology will run anywhere, basically, that you can fire a JVM up on. And we provide you both support for on heap and off heap. And why this is important is as with any Java technology, not just ours. The standard JVMs are not very good at garbage collection. So if you're running, you know, if you attempt to run large on heap sizes to store your data, you're going to run into all sorts of garbage collection pauses, you know, you get, you know, we see kind of, I'm not really comfortable saying more than about 10, maybe 12, depending on your sort of object creation profile, maybe up into 16 gigs on heap. But other than that, you know, you're just, you try and get bigger than that, you're done. So we both on heaps, you sort of do that off heap gives you the ability to do scale up. So we can do horizontal scale out, we can do scale up, or quite frankly, we can do scale up and out as a matter of fact. So if you want to have sort of bigger boxes for your usage profile, we can do that. And again, that's what's sitting under the covers there. Java based in memory map reduce, we have an API for using us for embedded mode. And one of the things that we go fast about is that we collocate computations with data. And what that means is essentially if I've got a task or a job or a query or something that I'm executing that query knows where its data is. And again, we have this large sort of partition you can see in the yellow fashion in the middle here, all of these data nodes and essentially those are partitioned out over your infrastructure, your servers, your virtual machines, your cloud, wherever you want to put that. And the task essentially knows its data locality sends under the this is under the cover stuff sends the task to the data which actually allows you to go very, very quickly. Now, our dual mode operation, there's actually sort of two broad, broad swaths, if you will, of dual mode, depending on how you count. Primary is where we are only in memory. There is only an in memory representation of your data, 100% in memory, not persisting, not going out to durable storage. For some use cases, this is very appropriate, interim results, sort of things that are transient. What is more sort of more often seen obviously is at some point you have to address durability, you have to turn the system off, if you will, or you have to account for that turn off, turn on, and the cold start, or you know, the meteor has hit every data center that we've got and I've got to recover at some point. We can run in proxy mode, so we sort of snap in, and then this is actually native MongoDB. So essentially what this allows us to do is gather performance metrics about how things are operating in the Mongo cluster, but it's just a pass through. It's just exactly like a proxy. And then we've got two modes where we deploy in conjunction, dual sync and dual async. So dual sync is a synchronous mode where, well, of course, if you're loading files or loading collections, loading whatever you may be loading documents out of the data store on demand, reads are always synchronous, right? If it's not in memory, I've got to go get it from disk and it's a synchronous read until it's in memory, but then it's in, and it's good. But writes, I can either write synchronously, which of course is, I guess I would argue maybe a little bit more durable or you have a little bit better guarantee, if you will, with durability on that, if we're writing synchronously because your write doesn't finish until it's persisted to disk. Of course, that kind of carries the penalty because it sort of begs the question, why am I doing in memory if I'm writing that way? But for some use cases, it is appropriate. Dual async is actually what's really kind of interesting, which essentially is a write-behind modality. So I can be writing behind into MongoDB while my application gathers all the benefits of, you know, high performance reads and writes in a memory-based system. Talked a little bit about this already. You can put a database or a collection, you can store it in memory. You've got ability to load and unload data on demand. We actually do field main compaction as well. Now we are fairly concurrent. So our, sort of, if you pointed us, our Mongo compatibility layer and you're running on top of grid gain, we are fully concurrent. We have no global locks anywhere. Again, Mongo still got some of those in there. All reads and writes happen concurrently, and this is because we actually use a contention-free MVCC. So if you're familiar with that, Multi-Version Concurrency Control. It's a very high-performance algorithm. It's what most traditional RGBMS systems use in order to go fast, essentially. So we use MVCC under the commerce, and we have snap tree-based indices, and both on and off indexing. With our platform, we give you very robust management capabilities, command control, monitoring, and give you what we think is really kind of best of breed visibility into all of your infrastructure, running a distributed infrastructure. And for us, our distributed infrastructure is, as I say, run into the thousands of nodes. So managing and monitoring now has to be a primary consideration in terms of the run book and in terms of how you actually put all of these kinds of things. So we talk about Mongo's replication scheme. Fault-tolerant, secondary becomes primary. You know, queries can run in parallel across this, but in some respects there are some significant trade-offs for that, and most significantly what you've got is that data is actually not partitioned. So we, under the cover, is actually partitioned data across it, but it's replicated. Replicated is much more expensive than partitioning this across and in memory space. You end up with a lot of paging. It's very hard to fit sort of the whole thing in memory because of the way that you're looking at these kinds of things. And writes in this are not, you know, you can't do concurrent writes across your nodes and your grids. And then when you start to talk about charting, you get some parallelism when you're writing out to this. You've got fairly decent throughput on these kinds of things, but you're not fully parallel on writes. You've got, you know, very complex deployments across these things and you may not be able to access the charts here, or not be even across the charts actually, which is what we actually see a lot. Now, when you take a look at our infrastructure, what we've got here is that we actually don't chart, as I say. We take the charting sort of out of the picture. We actually do partition data management across the entire set of grid gain nodes and clusters and you're split into, I guess, what you'd call ranges and sort of not charts. And what you get is a very even, even as a system loads, even as you're sort of filling up your available memory space and the capacity of the system, you get a very, very easy, so evenly loaded and very evenly distributed infrastructure that you have out there. And reads and writes through all of this are fully concurrent. Now, the one thing I'll also point out is, although we have sort of a partition strategy here, you also configure backups. So it's not a, you know, a once and done because that wouldn't be, frankly, a very fault-polliner, a resilient way to actually do all of this across the infrastructure. So, fully concurrent reads and writes across that. So, typical use case across these things. We want to be able to handle a ton of queries in real time, being a very high performance here, handle about three to five terabytes of data across this and your updates are as frequent as your reads and we actually have, you know, an under one second SLA performance increase here. So this is actually in its, you know, kind of totality. It's actually a very, very, very, very challenging kind of thing. So they had three char, basically three shards, about a terabyte and a half each spread across this. The 10 replicas across each shard and that was about 30 servers and three configures. And the problem is you only had a very small piece of this terabyte and a half in memory on any one given server. And the problem is, is that your performance hits happen because you're just constantly paging in and out and you're essentially taking the penalties of a disk based system. So when we actually put the acceleration in place on this customer, we used the exact same set of servers. We put a grid game node on every piece of infrastructure across all of that. Three terabytes in this are now fully in memory. We had about 120 or so gig on each server. We handle the entire data set. The entire thing is sitting actually in memory, which of course, first off, no more memory paging. That's gone. And second across, we actually have a very even distribution, a load distribution, across all of these nodes and can handle sort of a higher volume, if you will, in a more sort of better utilized infrastructure, a fashion on the infrastructure. And we also support real-time repartitioning. So essentially, you can think of that as balancing your data across all of these nodes. This happens seamlessly in the background without any kind of any challenges. And the queries on this are now running in less than one second where they were not before. So let's talk a little bit about kind of a trade-off one side to the other, if you will. Grid games accelerator is memory first. I mentioned that before. Mongo disk first, right? And there's no problem with that. It's just sort of an architectural difference between the two. We will easily scale to thousands of nodes. I've got customer references you can talk to about grid game infrastructure scaling into the thousands of nodes. Very uniform deployment. This is one of the keys to grid games infrastructure and ease of use. The deployment nodes are very, very simple. They're very, very lightweight and they're uniform across the whole in-memory infrastructure that you have here. Even distribution on that, you know, you're going to get uneven distribution in Mongo depending on where the data is, where the things are resigning across there. We actually can do per document redundancy. So you're doing your backup and your redundancy on a document basis as opposed to doing it on a complete shard basis. And one of the things not to be underestimated, a lot of folks will talk about scalability. They'll talk about elasticity. It's a term that's bandied about just much too easily in my term. We can absolutely just stack and rack more servers in your running dynamic environment. And remember, you go back to what I said, automatic repartitioning, if you will, of all the data and automatic rebalancing. I'm starting to performance to grade, fire up 10 new servers, five new servers, 100 new servers, whatever it is you want. Seamlessly behind the scenes, all of the data will be rebalanced across the memory space as the new servers. And as they're coming up, they're immediately starting to take the load and sort of sort of squish down, if you will, the performance problems and characteristics there. So very kind of interesting things there. We have no global write locks, no global locking, and you've got database wide locks in Mongo. Again, sort of a well-known fact, nothing, nothing here. Absolutely fully concurrent writes. You can be writing across the entire set of nodes, the entire set of clusters. And in Mongo, your writes are sequential. You've got concurrent reads on top of the writes, and in the MongoDB case, you're going to have to wait for, the reads are going to wait for that. So a couple other things here. We don't have to do every single one, but I mean data is always in memory, I think, is the really key point. You only end up with a small subset cached when you're actually using Mongo without grid games accelerator in here. Zero memory paging with grid games accelerator. Very important. I keep coming back to that one. You've always got hot data, it's always in memory, and you get ultra high performance, high performance querying. So we're coming up here on the end of our half hour together. I just wanted to talk a little bit about our complete stack. This is what I alluded to earlier today. The accelerators are actually built on top of some of our core in-memory computing technology. So the things that you'll see in the sort of the big orange blocks in the middle of this diagram are our core in-memory technologies. Very robust, very high performance, very scalable technology, and of course enterprise grade management, monitoring command control across all of these assets. And we have an in-memory HDFS accelerator for Hadoop. We have in-memory Mongo. The Hadoop one is in market right now. The Mongo one, I'm actively soliciting data. If you have any interest in this at all, I would love to talk to you. We're at the booth right across the hallway. And we have several cloud-based accelerators are coming on towards the end of the year. So with that, that really kind of brings me to the end of the presentation, what we wanted to do here in terms of scale. I'm happy to answer a few questions if you have them. Otherwise I can give you back I guess six minutes in your day here from the plan schedule. And everyone into silence. Mostly it's probably just 9 30 in the morning on day two of a conference. Thank you very much for coming out. I appreciate you joining me today. And we're in the booth all day. My CTO actually just joined us in the room here, who you may have seen speak yesterday. I'm happy to answer any questions. Thank you so much.