 Well, I think I should probably start. Thank you all for coming. My name is Mitri Cetrakin. I'm a Chief Technology Officer at GridGain Systems. And I appreciate you coming here, spending time with me. I'm sure there are plenty of other things you'd like to be doing this morning. I hope you'll find the presentation interesting. Today, we're going to be talking about our in-memory accelerator for MongoDB product. This is officially the launch of this product. So let me switch to the next slide. We have several products already available on the market. But this conference, we're using to launch our in-memory MongoDB product to the open. Essentially, this is the first day the world is hearing about it. So let's talk a little bit about agenda. We definitely are going to be talking about in-memory accelerator for MongoDB. That's our product. I'm going to be describing features. I'm going to be going over use cases that are potentially solving problems versus using native MongoDB installations. We will also, at the end, I mean, this presentation is scheduled for 45 minutes. So depending on how fresh I am, how much coffee I have this morning, it may go anywhere between 30 minutes and 45 minutes. So if I have time at the end, I will give an overview of other grid game products. But I will briefly mention them right now as well. And again, if you do many live tweeting, I would appreciate that you use hash grid game tech. It makes it much easier to find, much easier to search. We like to look at the tweets. We like to respond to them whenever we can. A little bit of a company history. We've been in production for five years. Actually, Nikita Ivanov, the CEO of the company, and myself, I'm the CTO. We are both founders. We started the company in 2007. And the first production release was in 2008. At that point, the first product we released was exclusively computational framework, what we called at a time compute grid. Since then, we went through several releases. It was five years. We went through several rounds of finding. We're recently close to our round B fund. So we're extensively rapidly growing. We doubled our team pretty much in the past three months, which is some people call it healthy, some unhealthy. But we're trying to grow fast. And since then, we released quite a few products. I'll just briefly mention the names we have in-memory HPC for your distributed computational needs, high performance computing, distributed map reduce, et cetera. In-memory database, your key value store that is, again, distributed across the network, fully asset, fully transactional compliant. That's our structured data store. Also supports SQL queries on the data that is stored in memory. We have in-memory streaming to satisfy streaming and complex and run processing needs. And at the same time, we have accelerator products which are in accelerator for Hadoop and accelerator for Mongo. And today, we'll be talking about accelerator for Mongo. We've been around for a while. We have hundreds of customers using us in various capacity and production. Some of the pretty large deployments I'm going to be mentioning. The product starts every 10 seconds around the globe. So this is not a guesstimate. Every time I say that, I get eyes rolling saying, how do you know that? Well, I mean, essentially, whenever you start any product, any infrastructure product, any middleware product, it will do an update check. It will essentially contact the home server and find out if there is a newer version. So to notify you about that update, all we do is count those checks. And every 10 seconds, somewhere in the world, the grid node has started. Since we started five years ago, we now have 15 million stars globally. This is a pretty impressive number. And our stars are growing exponentially and very rapidly. So from month to month, we're enjoying a very healthy growth. Let me ask you before I continue, because this is a MongoDB presentation, essentially, how we use MongoDB and how we can accelerate MongoDB. I'm going to find out, are you guys familiar with MongoDB? Are you guys users of MongoDB in production? Some are some? All right. Are you guys familiar with what MongoDB Sharding is? All right. So if you're not familiar, don't worry. I will explain how it works. There are slides that are essentially copied of the 10-gen MongoDB documentation site. Hopefully they don't mind, because I will be explaining 10-gen MongoDB product on those slides. So why in-memory acceleration? Why we need it? Well, obviously, when you load data in-memory, it's always faster, all right? So there is essentially a notion. If it's in-memory, it's faster. But that's not the only reason it's faster. Essentially, when you load data in-memory, it opens a whole slew of possibilities. It's a whole slew of new paradigms, new design algorithms that are possible for interlocking of data, of distribution of data differently. We have concepts called MVCC in-memory, MVCC in-memory hyperlocking that allow us to achieve a very different concurrency on our deployments. And this how we actually, with our in-memory DB Accelerate, it's a very long name for the product. I have a half-time pronouncing it. In-memory Accelerator for MongoDB, we already achieving 10x performance or better performance. And when I say performance, I want to be very specific about it. We're not improving latencies per se. So if you had one of query, if you send one of query, it'll probably take as much time as it would execute, as it would take when you're running it on Mongo. But what we provide value is when you use Mongo under load. And it's an old issue MongoDB does have problems under load. I'm not sure if any of you are running to those. But once you scale beyond 24 nodes, once you scale beyond terabytes of data, you will at some point run into performance and scalability issues. So essentially what this means, we're not increasing latency, but we are increasing throughput. And we are removing bottlenecks. So overall, you can say under load, where the latencies do decrease. But essentially, this is to get your throughput better. So just as an example, if your system can process 5,000 requests per second, with addition of our accelerator, it will be able to process 50,000 requests per second. That's a significant boost. And I'll be talking about it more in detail. Horizontal scalability to 1,000s of nodes. It almost sounds like a cliche. You open any website, any product line. So with 1,000x faster, we deploy on 1,000 nodes. I can tell you this much. We have really been deployed on the customer production sites on 1,000 nodes. It's a financial institution in London. I cannot mention the name, as with many financial institutions. But essentially, they put up through the most vigorous tests that I've ever seen. They deployed a cluster of 1,000 nodes. It's pretty much a whole data center, I mean, when you talk about 1,000 nodes. And they started plugging in and unplugging the nodes, removing ethernet cables, restarting stuff, moving data around. And the test was to make sure that no job is lost and no data is lost. And Greenwoods, too, are happy users. I mean, they're using Greengame for several years in production and already in several deployments. So we like them very much. We like this use case very much. Having said that, I don't want you to think that we only add value on 1,000 plus nodes. Essentially, I mean, nobody is probably, this is a very one-off case. This is an edge case. Nobody, majority of our customers, do not see topologies this large. As a matter of fact, most common topologies are between 20 and 40 nodes with sites of about 100 to 200 gigabyte of RAM each. And that may also seem like a lot of RAM, a lot of memory, but let me tell you, memory is getting very cheap. Right now, if you have a very commodity low-end blade, which is maybe 32 gig of RAM total, if you try to upgrade to 250, where essentially increasing memory capacity eight times, you'll probably be paying 1.5 2x times of price. So memory is a lot cheaper than the value it provides. So the clusters or 25 40-node clusters, you can literally store five, six, 10 terabytes of data depending on what kind of data approach you take. Versical scalability, that also very important because as RAM grows, we have to be able to make sure that we're able to utilize all the memory that you provide us. Otherwise, we would be wasting memory. Ideally, any memory product, you wanna load as much data in memory as possible. Ideally, I would load the whole data into memory, but unfortunately, that's not always possible. So we have to pick and choose, and I will be talking about that as well. Fully concurrent and memory processing. We will be talking about that pretty much extensively throughout the slides, mainly because Manga is known for its concurrency issues. And mostly it has to do with global logs. I mean, they used to have a log the world kind of approach when you're doing a right, everything else has to wait. Queries have to wait for a rise to complete. They improve that significantly. They're doing a great job at Tengen. And now they have, instead of global logs, they have per database logs. And now they're working on per collection logs and we'll see where that goes and at which time they achieve it. But even with that, the concurrency is still not there. You do not get concurrent writes and concurrent reads. There's always waiting. Especially if you hit the same database, the same collection a lot, and you're doing updates as frequently as writes, you will have sequential operation issue. Writes are not in parallel. Reads are waiting for writes to complete. So we'll be talking about that as well. Efficient and balanced memory management. I'll be touching that. It essentially has to do with equal load and data distribution across your cluster. You don't get that a lot. Sometimes you don't get that with MongoDB, although they are doing a pretty good job at it as well. Transparing backgrounds, repartitioning. And lastly, I wanna mention, last but not least, I should say, is embedded MongoDB, MongoEPF for in-memory computing. And that actually opens a whole new paradigm of how you can compute when you embed Mongo directly into your application. And I'll be covering that going forward on upcoming slides as well. So now let's take a look at some of the features we have in our product. Let me start before we look at the diagram. By the way, you'll be seeing this diagram on several slides ahead too, just because I'm going to be talking about the features of in-memory MongoDB Accelerator. But hopefully as I progress through the slides, you'll gain better and better understanding of what we do. Actually, before I even say that, I don't want you to get the impression that we're competing with Tengen or MongoDB in any way. We actually love them. We're partnering with them. We are going to be partnering with them. I believe, my personal belief, MongoDB API, MongoDB API is one of the best document store APIs out there. Used by a million of people, it's well-vetted and it's fairly flexible, especially with addition of aggregation framework. That is a great job of actually making queries very fairly flexible. So our goal is for you to continue using MongoDB. And in majority of the cases, you will never need the acceleration. So most of the time, you probably will not need our product because in your use case, MongoDB performs well and scales well. But at some point, you will reach a certain threshold in your business where you're either based on data, based on number of servers, or based of new SLAs, maybe lower latencies, you will run into some performance issues. And at that point, we hope you come to us and we'll provide the acceleration for you. And the coolest thing about our acceleration is that it's plug-and-play. And by plug-and-play, I mean, you literally, if you look at the diagram on the right, everything can orange and yellow as grid game. So the team boxes are the client, are the MongoDB clients. And as you can see, they just, as they were, we are not changing clients. As they were, they continue talking to MongoDB. But now they're talking through grid game layer in between. So grid game will process MongoDB requests, whatever, execute the queries in memory whenever possible and whenever it has to, and I'll talk about that too, it will delegate those requests to MongoDB database. And MongoDB database is the same installation you guys have. We're not asking you to change that at all. And just briefly, whatever we have on every node is data partitions that belong to that node and local indexes that are stored on that node. So essentially the deployment is very even. If you look here, we have no complexity of query routers. We have no complexity of config servers. Every node is equal. There are no shards. Let me say in advance and I'll be touching that again. There's no sharding for in-memory MongoDB acceleration. So you can still keep your deployment, your Mongo deployment the way it was with shards and everything else. But in memory, we remove shards. And we believe it's a much better approach. It gives you much better concurrency when you don't have shards. But we do have partitions. We do partition data very effectively. But we're not using the quote unquote sharded approach that Mongo has. Do you know? So if you look at this diagram again, let me use my laser actually. Yeah, there it is. If you look at this diagram again, you can see that grid game is sitting in between clients and MongoDB installation. That means it serves as a cache and layer. So essentially all the reads come from here. All the writes go to here and also get propagated to MongoDB database either synchronously or asynchronously. So that's a write-through behavior where grid game serves as a separate cache and layer for MongoDB installations. There's also another mode that is very interesting because when you have data that does not need to be persisted, volatile data collections that do not need to be in memory, do not need to be in disk. And for those you can simply store them in memory without ever propagating them to disk. So grid game essentially becoming an in-memory MongoDB database. And not grid game, it's grid game accelerator for MongoDB essentially becoming an in-memory MongoDB database. We have plenty of those in SQL world. There are plenty of embedded or external in-memory databases for SQL. I mean, I'm not gonna list them, there are probably 10, 20 of those. But there are none of them for unstructured data for no SQL world. So that's exactly another one of the cool advantages you get from our accelerator that you can use as standalone as an in-memory MongoDB database. And we accelerate, again, Mongo deployment, thousands of nodes as I mentioned, and you gain up to 10x performance on those. Let's talk about the operations we support for MongoDB. So essentially all the core operations are supported. And otherwise we wouldn't be plug-and-play. You wouldn't be able to simply plug the game in between. All the aggregation operations are also supported. So if you utilize a MongoDB for like utilizing core operations or aggregation framework functions, all of that should work out of the box. You should never actually have to change the line of code. Just plug-and-play this very easy to try. You will immediately see if it adds advantage or if it doesn't. If you use some admin functionality in Mongo, creating some, changing some installation configuration, giving priorities to your replica sets or whatnot, that does not make sense for our in-memory mode. So we'll most likely simply propagate them to underlying Mongo or Ignore them or depending on the operation or give you an error that this operation simply does not support, is not supported. But those I'm talking about admin functions. So day-to-day operational functions, your queries, your operations. May I have your attention, please? May I have your attention, please? A fire has been reported in the building. Are you kidding me? Do we continue or do we evacuate? Is that a drill? The fire has been extinguished? This was a false alarm. No, no, no. You're not evacuated. Okay, that was interesting. So I lost my train of thought. What was I talking about? So full operations are supported and let me talk about that our accelerators optimized for disk-first approach versus, for memory-first approach versus disk-first approach. And this very important distinction. Lots of database systems are built with the disk-first in mind. They're primarily a disk-based system including MongoDB installation. MongoDB is a disk-based database. They do have caching. But the assumption that always happens in that approach is that majority of data is on disk and very little of data is in memory. So you get about 90% of data stored on disk, about 10% of data stored in memory. So with the memory approach, there's actually a reverse of that, the 100% of data stored in memory. So you actually get, you never get memory paging. Because whenever you have a majority of data on disk, there's constant paging back and forth happening. Happening and you essentially end up hearing disk a lot and queries get slowed down a lot. We entirely remove audio from disk which also gives us a performance boost. Dealing with, being a Java product and dealing with huge amounts of memory space, we have to make sure that our Java garbage collection works effectively. So Java is known for not being very efficient whenever you exceed go beyond 20 gig of RAM, you get minutes and minutes of pauses of garbage collection. Those are usually like the world. For that we actually manage data on heap and off heap. We put on heap exactly what Java can handle and the rest of the data is handled off heap. You can get a ratio of 20 gig on heap, 20 gigabytes on heap, 300 gigabytes off heap generation. Direct memory access versus block access. Whenever you work with disk, whenever you work with files, you load data in blocks. So that's how you're operating system works. It accesses data in blocks, loads it and unloads it in blocks. Whenever you have an in-memory approach, data is accessed directly. You need a certain data, you simply access the pointer, you get the data that is stored in memory. There's no marshalling and marshalling, serializing to and from disk at all. So, and on top of that, since all our servers are equal when they're deployed, we're entirely removing it for, on this layer where grid gain is, we're entirely removing it for MongoS and that actually removes an actual network hub for us. Usually network hub generally is equal depending on your network capacity, to X performance, it adds latencies every time, especially when it goes through software and not through hardware, it adds latencies. So we remove MongoS, which actually already gives us a significant performance advantage. And also what we can get here with a memory first approach, as I mentioned, we get to utilize much more efficient algorithms like hyperlocking that we have, which is group locking, very concurrent free NVCC approach, which is very efficient. You never get any contention within grid gain. Due to operation mode, that actually goes together with probably effective memory management. So we have four modes in which this accelerator can operate. One mode is a primary mode when essentially everything is stored in memory, not everything, the collections and databases you choose are stored in memory and will never be persistent to disk. All the queries and updates can still happen, probably a lot faster than they would happen if they were persistent. But at the same time, you have to realize everything that is stored in memory will not survive a restart. If your whole cluster crashes, even though we provide redundancy, if a last note in the cluster crashes, you lose your data that is stored exclusively in memory. We also have a proxy mode. So we let you pick and choose which collections are stored in memory, which collections are stored only in Manga, and which collections or databases are stored in both places, Manga and memory. So proxy mode is exactly for the cases when collections are stored in Manga on disk. Essentially, we simply will proxy your request through to Manga without even doing any processing. And those are usually the collections that you don't care about in your application, the ones that are accessed infrequently and you do not care how slow they are. So you don't wanna put them in memory simply because you do not want to occupy memory with something that you do not need. And dual sync and dual async modes are exactly when you utilize here again as a caching layer for MangaDB. All the update, it's essentially a write-through. All the updates happen in memory and can be persisted to MangaDB either synchronously or asynchronously. In asynchronous mode, it will be a lot more efficient, we'll accumulate them together and then we'll send them in in bulk. However, you do get additional delays. My experience, MangaDB users already used to delays. There are several write concerns that already say like if you use acknowledged or unacknowledged write concerns for instance in Manga, then the replicas will not be updated or maybe even the primary node will not be updated and operation can already finish. So essentially a lot of Manga deployments already used to delays and used to lags. So a dual async mode, we find that people are actually reacting to it very positively and not too concerned that some data may be lost. And that goes with efficient memory management. As I said, you can pick any database, you can pick any collection to store either in memory or on disk. So yes, go ahead. I actually am gonna go through an example that actually shows how you split them up, but I recommend that anything that you want persisted use either in dual async or dual async. Anything that you don't care about performance use as a proxy. Yeah, if you use dual async, of course, there's gonna be overhead to write because now you have to update memory on disk. If you use dual async, no. You're as fast as memory because the async flash happens in the background by another process. We identified the gain on performance. I mean, with dual async, we're not gonna beat Manga on performance for writes simply because we're doing them synchronously. So essentially what we're talking about, I'm gonna use my laser pointer again, what we're talking about, that whenever an update comes first, this is updated. And when I say this is, I mean one or two nodes are updated here. The game does not have to update all the nodes. Data is partitioned. And then MongoDB has to be updated synchronously and then a response is sent back. So you cannot, since MongoDB update is part of your processing, you cannot be faster than MongoDB update here. However, in async approach, you update couple of nodes here, send the response back and then asynchronously update MongoDB. And in that case, you're getting in-memory speed but you still get this base persistence. So my recommendation, whenever you can use this, dual async. Right, but with dual async, you can lose, you can potentially lose some data that has not been flushed to MongoDB yet. In other mode, you can have us, you can have dual sync mode and flush to Mongo but have it in a journal, around MongoDB in a journal fashion when it will immediately reply but will not flush the disk itself. But at the same time, it will keep journal. So whenever you restart MongoDB, it will still not lose the data. So in that case, you will have minimal data loss if any but you will still get pretty close to in-memory speeds. So ideally here, I mean, we're fixing performance, we're fixing throughput and performance. So we wanna make sure that the modes in which you utilize Mongo have the least effect on overall latency and overall throughput that you in-memory layer can handle. Does that answer the question? Okay. And another cool thing I wanna mention, I mean, we do have custom load and load data, command collections data. So we actually have commands for loading collections and databases from Mongo to in-memory layer either through our management console or directly from command line in Mongo. And one cool thing is field name compaction. I'm sure Mongo will eventually probably do it. I mean, this is fairly simple feature to ignore but with field name compaction, we're able to save about 30, 40% of memory. So if it occupies one terabyte on disk and you utilize field name compaction, you can get it to 500, 600 gigabyte in memory. And the thing is, I mean, field names repeat and for us a field name becomes an integer, not a string. So we always use no more than a four byte for field name. Locally on every node, I mean, it doesn't even have to be distributed. Every node has its own field name compaction and then whenever we have to, in our cases, when data has to move and I'll talk about why they're rare, we'll uncompact and move. But the idea here is to, memory is a scarce resource, right? So the idea here is to minimize the use of memory. So if you have terabyte and you can feed it in five, in a half a terabyte, why not, right? So that's exactly what field name compactions do. Another cool thing to think about it as we're on the topic, that every data gets backed up, right? I mean, if you optionally gets backed up. Here you have redundancy in grid game layer. You do have redundancy and you can actually optionally say that every key stored here gets backed up either here, here on other nodes. With field name compaction, you almost get backups for free. So if your data occupied one terabyte on disk, you can continue to occupy it in memory also within one terabyte, but now you do have backups. So if one node crashes, another node, other nodes will still have the data so you don't have data loss, in-memory data loss. Fully concurrent. This is probably the most important feature that our in-memory layer adds. Essentially, as I mentioned before, Manga does have this concurrency problem. I mean, there's a lot of blogs on the internet. People are complaining about it left and right. Essentially, global right log does not allow you to perform concurrent right operations. Moreover, whenever rights happen, you cannot perform any read operations. So all the reads get queued up waiting for rights to complete. With a memory approach, we're actually capable of fully removing it. So the reason is simply because we have a very efficient in VCC-based architecture. It's essentially lock-free, contention-free. So any write, any read can happen in parallel. Actually, there's absolutely no waiting between any operations that happen in memory layer. And that's where actually majority of performance gain comes from because our in-memory approach makes concurrent reads and writes possible. And also, the same thing comes to document indexing. If you did update our files, but indexing is slow, it still adds no advantage. So we add concurrency to our indexes as well. We actually use a very effective modified by our engineers very effective approach using snap trees. Have you guys heard about snap trees? It's essentially very effective way to create a tree-based representation of data in memory, essentially that's how your index looks. But all the updates are concurrent. And one of the coolest feature here is that snapshot of a snap tree is instantaneous. Whenever you're working with indexes, I mean, you're utilizing an index and you're pulling out data, you wanna make sure that all the data you're pulling out is consistent because index is changing in the background, potentially with all the updates that are going on. So you wanna take a snapshot of existing index and work on that. And snap trees, one of their main features, they give instantaneous snapshots. The complexity of constant time, big O of one. And that's exactly what makes it very efficient for indexing. And the indexing is actually utilized, also utilizes on heap and off heap memory in Java. And last but not least, I wanna mention embedded mode. And the reason I wanna actually dedicate a whole slide to it because it actually changes the paradigm how you actually utilize your unstructured database. This is actually only for JVM clients. Since we Java product, we can only embed within JVM. But if you are using any JVM based client, like Java, Scala, Groovy or what's not, you can actually utilize this approach. And this approach is actually a collocation or whenever you actually collocate your manga to be data together with your application logic. So traditionally, the way you have a deploy it is you have an application layer and then you have a database layer. And then in the middle, you also have a manga S, layer query router config servers. And application layer constantly goes through all these hoops to get to the data and get it back. With this approach, you locate the data directly on the application server. So you still get the same API, you're still using same API, but all those network hubs are gone. This actually gives us five extra additional performance. So now we're talking about 50X performance boost whenever you're using this approach. Absolutely, yeah. You can have, first of all, you still have manga. You still have this persistence whenever you want. It's either nothing changed from that standpoint. It's either synchronous or asynchronous. But we, right, and we store it in memory close to your domain logic. At the same time, we have in-memory read on it. So you can configure one, two, three, 10 backups. You can have as many backups as you like. Same, cool thing about it, that you still utilize the same APIs for manga drivers. So pretty much very minimal code changes for you. But now you can actually do a lot more than you used to be able to do. Now you're able to, we provide a lot of APIs just to tell you which node, which server the data is located on. Now you can actually send closure, send your functions to execute directly on the nodes where the data is. It actually changes the paradigm entirely because in traditional approach, you bring data to the application. You constantly bring data from database to the application. Now, in this deployment, in embedded deployment, you can achieve an architecture where you have zero data movement. The movement data is actually the most expensive operation your cluster can do. It's actually your involved serialization, the serialization, when a lot of it happens, it can actually saturate the network, bring your servers to their knees. Here, you minimize that by only sending lightweight computations to the nodes where the data is. So that actually creates a whole new paradigm, whole new range of possibilities that were not possible before. So whenever possible, whenever it is possible for you to use it in embedded mode, I strongly recommend you do that because the performance gain and scalability gains will be enormous. You have questions about this? Well, first of all, it will not work if you are not using, since we're a Java product, we can only embed into JVM-based applications. So if you're using Ruby, you're using Python, you would still have to use external mode, which will also support and which also gives you a good productivity boost, but in those cases, you would not have an option of bringing it in. So it works only for JVM-based languages. Does that make sense? Any other limitations? Well, I mean, essentially what this approach means that you collocate your data with your app servers. So your app servers have to be powerful enough to hold that data, right? So if your app server have 10 gigabyte of RAM, probably collocating half a terabyte of Manga data with it probably will not do any good. So essentially if your app servers are powerful, 120 gigabyte of RAM to 50 gigabyte of RAM, then you can actually use this approach quite effectively. And as a matter of fact, my majority of our customers, even in not only for Manga, but also for our in-memory database and memory-scale database approach, utilize this. So they throw away the app servers, upgrade them, and bring the data to the app servers because this approach removes network hubs and that's exactly what you wanna achieve. Because those powerful data servers, you need them regardless to store your data. So it's a matter of fact, actually to move your application logic there and remove part of your infrastructure. So it actually simplifies their deployment. Any more questions about this? All right. And this actually is screen shot. I'm not gonna spend too much time on this slide. This is actually a screen shot of our management console which actually shows lots of graphs, lots of metrics about everything that goes on in your in-memory layer. You can even run queries to look into production data directly from your management console. So let's take a look actually at how Manga replica sets are working and how MangaDB natively charting is working. This actually picture taken directly from MangaDB documentation site. And essentially what we have here is a primary replica set has to have a master or a primary node and then as many secondary as you like. So essentially this actually a pretty standard size replica set with three nodes. And the pros about it is it's full torrent. If primary fails another node that assumes primary responsibility. But the cons are the data is not partitioned. You got four replications, four data replications across all nodes. So if your primary node holds a terabyte of data, all secondary nodes also hold a terabyte of data. So replicating between primary and secondary becomes especially you have to move large amounts of data. Excessive memory paging. And the reason it's excessive is because you cannot load the whole terabyte of data in memory on every server. You probably will load 250 or maybe 120 gigabyte of RAM, 250 gigabyte of RAM. So memory constantly gets paged in and out from memory to disk, from disk to memory. That is one of the major pain points that our customers complain about among lots of paging, slow down the queries. And again, the rights are still not concurrent because all rights go through the primary node. And while the rights happening, the queries have to wait. So the concurrency suffers here. So this one replica set, essentially this is one shark. This is how a Mongo shark looks. Now let's take a look at shark detection. Now you have more than one replica set here and here. Now you're also at a config service and you Mongo has query routers. You can handle bigger throughput with it. You get more parallelism on rights because now rights here in this shark do not conflict with rights in this shark. So they can have a concurrency. But they're still not fully parallel. And especially when your queries spend both shards, they have to wait for rights now happening in both shards. And deployment is somewhat complex. I do not like this deployments when every server is a designated server. Like in grid game, we have a deployment, every server is equal. You never have to worry what's master, what's secondary or config service. We don't have those deployment pieces. You just bring up a grid node and it just starts working. So that's your MongoDB sharding. Let's take a look at how grid game data partition is different. First of all, we have no sharding. Very important point, sharding is removed. No need for query router. Data can go, your query request can come to any of these nodes. And that node will router properly within the grid if needed. So we do not have that extra network have that present among the SS. Data is split into ranges or chunks amongst not shards. So essentially if MongoDB has five shards, grid game has one cluster. All nodes are equal. And if you have 10 nodes in a grid game cluster, every node will hold one-tenth of data. That 20 nodes, every node will hold one-twentieth of data. So we partition data across without having to physically shard them and provide some extra level of redundancy and complexity on deployment. Data is equally distributed within shards, within partitions. So data is partitioned and every partition, since our partitions are smaller and constantly get repartitioned in memory, data is very evenly distributed and load is very evenly distributed as well. There's redundancy and writes and reads are fully concurrent. So that's actually the difference. This is where we get performance boost. Let's actually, what am I doing on time? I have about five more minutes. I'll go quick. Let's actually go through sample use case. This is actually a customer for which we did our beta deployment and which our accelerator really helped. Let's imagine a case where you have very many large amount of queries in real time. And they had a use case where they had to sort three to five terabytes of data. They had updates coming in almost as frequent as reads. So essentially they had a lot of concurrency issues, but SLAs were under one second. So let's see the problem that they had. First of all, they had five charts. Every chart was holding one terabyte each. Every chart had three replicas in a chart. So one primary, two secondaries. And so they had about 15 servers total and three config servers and their deployment and a couple among the SS. So their problem statement is this. Since every chart holds one terabyte, only a small portion of that terabyte fits in memory. And before performance gets poor, the more data the queries touches, touch the poor the performance gets because the data keeps constantly getting paging in and out of memory. And this gets even slower when the queries span multiple charts. And they had cases where some queries were taking minutes, not seconds. So after they introduced grid gain accelerator into the mix, first of all we were able to utilize their existing infrastructure. We have not added a single node, single server to their existing infrastructure. You start a grid gain node on every server, only put highly utilized collections in memory. So they had about three or four collections that were hit the heaviest and the rest they didn't even care about performance. So those the heaviest collections they wanted in memory, they were the biggest collections, they were pretty heavy, they wanted them fast. So only those that put in memory and from five terabytes we went to three terabytes including with field compaction. So we were able to feed them on 15 servers with 56 gig of RAM per server. Essentially now all the data is in memory, all the queries are extremely fast. There's no paging, there's no hot data or cold data. All the data is in memory, it's always hot. It's always at the fingertips, you always access it right there in your application logic. There's even low time data distribution because of our ranges are smaller and we constantly reputation in the background, the data is evenly split. So all the, you don't get into cases when one node is loaded 90% and another is 20. All the nodes are always fast. And just by adding this literally with almost zero code change, that most of their queries started taking under a second. Imagine going from minutes to seconds just by adding this in memory layer component. That's actually a pretty powerful message. All right, and this is just recapping this stuff. I'm gonna go pretty quickly here. I have about one minute. Actually, you know, I'm going to skip it, but I pretty much give you a comparison already of what in-memory approach, advantage of in-memory approach versus disk approach and make sure, remember that you always have to use it in conjunction. MongoDB is not going anywhere. We love it, we want you to continue using it, but do add this in-memory layer whenever you actually have performance issues and you start me with performance. And just a quick overview, and I just want to spend one minute here on our overall product stack. So these are the products offered, oops. What did I do? These are the products offered by Grid Game. And these are what we call our platform products and this what we call our integrated products. So for platform products, we have in-memory HPC, in-memory database, and in-memory streaming. Essentially, Grid Game is, should be your one place stop for a majority of your computing, in-memory computing needs. In-memory HPC provides you in-memory map reduce, full-torrent, slow-dancing, distributed closure execution, distributed thread pools. All the power that you need to compute across multiple nodes you will see in in-memory HPC. In-memory database is our structured database. So we have actually two products in our, in Grid Game for one for structured data and one for unstructured data, which is our MongoDB accelerator. So structured database is actually your key value store with full, which is fully transactional, provides a lot of full asset support. But the coolest feature about it is that it allows you to execute SQL queries over your key value data stored in memory. And in-memory streaming is actually the cool use cases when you get huge amount of data streaming into your system and you have to process it without bottlenecking. Because there are plenty of ways to process it with bottlenecks because I mean, you can load it in an Oracle database all the time. But that will be slow. Once, with streaming, you can never hit disk. So that's exactly the feature that in-memory streaming provides. It provides you everything that storm provides, essentially, but it also provides you this sliding window approach. It lets you answer questions such as, what is my top 10 popular users over the last 24 hours? Because as your streaming data never ends, this window of 24 hours, for instance, or five last hours will always move forward. So this answer will constantly be changing. So it will allow you to index into this window and provide answers very fast. And lastly, our accelerators in-memory accelerator for Hadoop and in-memory accelerator for MongoDB for which I already talked about. So I'm going to conclude it now. Do visit our site, do download our product. And we use Twitter actively. You can follow us on Twitter, at GridGain, or follow myself, at DCTracking. Please do check us out, and please do post about us. So that's about it, and unfortunately, I'm out of time, so I have to conclude this. Thank you.