 we can hear everybody. So I'm Don Marty. I'm with SOADB. We're coming up on our GA release. So before I get started, who is already running Apache Cassandra, or have you run it in the past? Okay, so I'm not in production. All right, so other NoSQL systems, Mongo? Okay. So Hadoop, React, any of the others? Redis? Okay. Big time Redis and Spark. And then is the back end for your Spark for the storage? Okay. Okay. So yeah, Spark, Spark Silla turns out to be a really good fit. So some of the integration work that has been done for hooking up Spark and Cassandra just plugs right into Silla. Ignite, I don't know about. I know Spark for sure because we just put up, or we recently put up an article about that. I don't know about Ignite, but I can check on that one. Okay. Okay. All right. Well, now that I have a little bit of a sense of where we're starting from, Silla is a new NoSQL database and it is, the claim to fame is that it does about 10 times the throughput of Apache Cassandra while maintaining Cassandra compatibility and with a lower latency in general. And Silla is open source. Founders, Avi Kaviti and Dora Lear are the two company founders. It is a commercial open source project. They're well known for the KVM hypervisor, which is the basis of the Google Cloud and many other cloud deployments, and the OSB Unicernal, which is an early full-featured Unicernal project, which is also open source and still out there. Silla, we've got people in 10 countries around the world. We are hiring. I don't know if you saw the jobs board, but we're looking for C++ developer, QA solutions engineer, a bunch of different roles within the project and the company. So what makes Silla so different from any other NoSQL database? Well, the design is completely different. It is completely sharded per core. Everything that has to touch memory, for example, is only working on an individual core. Cores communicate by message passing. So there is a send and receive queue for each pair of cores on the system, no lock. Throughput is depending on the system you put it on, a sort of mid-range to upper-mid-range system will give you about 1 to 1.8 million CQL operations per node. CQL is just a Cassandra query language. So we go by how many CQL statements we can execute in a second. The 99th percentile latency is consistently low. This is probably not surprising when we get into more about the architecture of how this thing is laid out. And then the feature set, it is compatible with Apache Cassandra. So here's a quick graph of throughput. The little green bars down here got the write throughput, the read throughput, and a read-write mix. The little green bar is Cassandra 2.1.9, and the purple bar is Silla on the same hardware. So this is running on bare metal with an SSD. And of course, I don't know if anyone went to Brendan Gregg's talk, he points out that most benchmarks are bogus, so it depends on your individual configuration. But you can generally expect to get an order of magnitude throughput improvement. With Silla. Compatibility, you can very often take the same workload, same number of clients, put it on fewer servers. Now, as far as how much of Cassandra did Silla copy over directly and how much of Cassandra did Silla completely reimplement, the stuff that makes it easy to switch back and forth between original recipe Cassandra and Silla is all the same. So Cassandra uses the SS table file format on disk. And the Silla file format is actually identical. So if you are migrating from a Cassandra server to a Silla server, you can simply shut down Cassandra on a node, copy the files over, and start Silla pointed at those same files. There's no conversion that needs to happen. Now of course, Cassandra and Silla may make slightly different decisions on where to split up those files. Cassandra will probably produce fewer and larger files, and Silla may produce a larger number of files because of that per core sharding. But either system will be able to read in the files that were written out by the other one. If you go to the Silla site, you'll notice there is no driver download section. Because all of the drivers for all the common languages out there, including C, Java, Python, Ruby, everything that has current Cassandra support, that same driver will work with Silla. The wire protocol between the Cassandra client and the Cassandra server is implemented exactly by Silla. Same goes for the CQL language. The query language is the same from Cassandra to Silla. The config file, some of the entries in the config file refer to details in the Cassandra implementation that Silla will simply skip and have no effect. But the same config file format will work on both systems. So you can copy your Cassandra.yaml over to Silla.yaml and start up Silla, and it will work, and it will use the right IP addresses and ports and snitch configuration for communicating among those. Management, yes, it is managed with the same JMX endpoints. Now this is not because Silla is a Java program. It's because there's a separate JMX component that starts up and will translate between Silla's own native REST API for management and the JMX endpoints that are provided by Cassandra. So we're actually filling in a few more of these JMX endpoints as we go along. So any third-party tool that you're able to use to manage Cassandra, you'll also be able to use that to manage Silla. Code is all the same. You can copy the Cassandra. Database is the same, and as I mentioned before, the integrations for other tools like Spark will work with Silla as well. And this is just the details on the versions of Cassandra that the current version of Silla is implementing. So the CQL language version 3, the SS table format is the same as Cassandra 2.1.8, JMX that's also the same as 2.1.8. The configuration file is the same. Now Cassandra, when they first started up, they had an older protocol called Thrift for storing query and data. The Cassandra Thrift protocol is not implemented in Silla, so you would need to use a current Cassandra driver that uses CQL. At some point we will have Thrift support, but almost all of the new Cassandra applications have been CQL for quite a while now, and so that's where Silla is focused. Yes, question in the back? The missing Thrift, that would affect you if you had developed a Cassandra application using a very old driver that uses Thrift. So if you've gotten your Cassandra driver within the past couple of years when everything has been focused on CQL, then your CQL based Cassandra application would just work. It's just some of those like Cassandra 0.9 vintage applications are not going to run with Silla yet. Yes, Cassandra is a distributed NoSQL database. At the very basic level, it's like a distributed hash table where data is given a persistent identifier, and then it's stored on multiple nodes around a ring. That level of the system where you can choose how many copies of a piece of data are stored is tunable. So you can actually tell Cassandra, I want to store copies of this data on three out of the five nodes of this ring, but when I do my write, I want it to come back when one of them is written, and then Cassandra has to take care of replicating it itself. Or you can say, I don't want my insert statement to return until I know my data has been persisted to a quorum of the nodes where it's supposed to be. So one of the things about developing for Cassandra as a developer or as a systems architect is you can decide how you want to balance out speed versus safety. So you could, for example, have certain items of data, like some cached data from a user session that you can regenerate. You could take some data and run it very fast but with fewer copies. Or you could say this other set of data is something that I can't easily regenerate. Therefore I'm going to set the replication and the consistency level for that data to need to be on more nodes. SILA copies all that exactly from Cassandra. So if you've done the process of going through and reasoning about your data and deciding how you want to trade off performance versus safety, then all those same decisions will be reflected exactly in your SILA configuration. Yes, there's a repair functionality that will let you repair your ring when you replace a node. There are different levels that you can apply when querying your data as well. So you could say I want my reads to only come back if I'm reading a quorum of all nodes. Or you could say, well, I just need to hear back from one node about this particular piece of data. The Cassandra design is possible that you could misuse it. You could build something that was both unsafe and slow if you really tried. But if you go through and figure out the possible failure scenarios and how you want each piece of data to be protected, then you can balance out and get the right level of speed versus safety for all the data you want to preserve for your application. If there's something that you would cry if you lost, then look at quorum. So your write will not come back until a quorum of nodes has a safe copy of it. Yeah, it's the same. The Apache Cassandra project has a lot of interesting discussion of different data models. There's also a regular Cassandra meetup. So if you go to the Cassandra meetups, very often there will be a talk from somebody who has gone through exactly the kind of process we're talking about of saying, well, here's our initial data model that we came up with. And then we decided that for whatever performance or safety or ease of administration reasons, we went through a couple of different versions of it. We have done some reporting back to the Cassandra project, and there are several people on the Cassandra list and I think vice versa. So it is kind of symbiotic and it's all open source. So if you like the Cassandra model and you like the drivers, then it's a – We don't want the performance. We are going to offer training, but not yet. Right now we're focused on GA. So if you're looking to develop applications for Cassandra, then yeah, there's some good tutorials there. There's an O'Reilly book on Cassandra out too, but I think the O'Reilly one is kind of old. And either A-Press or Packet Press had a good one out more recently than the O'Reilly one. But the good news is that there's a lot of good information about it. And if you go to Stack Overflow, there's some good discussions of different Cassandra options as well. But if you can't get something – Oh yeah, from an open source point of view, you can always get on our user mailing list and ask. And then there's also a support line that you'll be able to get on and get a support line too if you're interested in that. For now, the user mailing list has all the main developers on it too. So you'll get good answers to any FILLA user questions as well. Oh, Gossip is the way that both Cassandra and FILLA share information about which nodes are up, which nodes are down. So FILLA copies the same general principle for communications between nodes of the cluster. However, you can't take a FILLA node and add it to a Cassandra cluster or vice versa. The wire protocol of what travels between nodes is a little different. Yeah, you would need to replace all the nodes in a cluster at once in order to do the migration. Each individual node is easy, but you can't do one node at a time. Now, Cassandra does have the concept of – and so both have the concept of data centers where you might have a duplicate of the same data in different regions for resilience. And so in the near future there's going to be an option of having a Cassandra data center and a FILLA data center that cooperate, but that's a near future thing. It's not something you can do right now. One of the things that some sites do when they experiment with migrating across NoSQL systems is they will do a right. So you would be writing to both systems for a while and then cut over at some point. So that's fairly common in large scale NoSQL situations where you can't afford to have something go down. But we are going to do the translator functionality soon. Okay, so how does it work? How is it possible to do all that stuff but so fast? Well, this is Lady Ava Lovelace and before she even actually had a computer to program on she came up with this which is surprisingly accurate. How multifarious and how mutually complicated are the considerations which the working of such an engine involves? There are frequently several distinct sets of effects going on simultaneously all in a manner independent of each other and yet to a greater or less degree exercising a mutual influence. To adjust each to every other and indeed even to perceive and trace them out with perfect correctness and success entails difficulties whose nature partakes to a certain extent of those involved in every question where conditions are very numerous and intercomplicated. How many have dealt with that? Yeah, so most of today's server software was designed back in the day when you had one core per processor and SMP systems were out there but it wasn't so big of a thing. Even your typical mid-range system was a single core. Today, excuse me, today you can go down to well maybe not target but certainly fries and buy a 10 core processor. You can click on a cute little web form and get a machine with 20 or 28 cores by the hour. So the difference in how these systems have to be coded for is remarkable. Instead of the processor spending most of its time doing actual work when you take an application that has thread pools or a lot of contending processes at the OS level, the cores are spending most of their time contending for locks and getting in each other's way. So what SILA does is let each core run flat out by giving each core its own dedicated set of resources. So in a classic multi-threaded application you've got a lot of threads going on and the threads need to make system calls into the kernel and of course when something wants memory the kernel has to handle allocating memory to many different threads running in the same process. And what SILA does is SILA is based on a thread per core architecture called CSTAR. And in CSTAR every core has its own chunk of memory to be allocated. And so when one core needs to allocate memory it doesn't have to take a lock. It can just get memory that's dedicated to that core. For writing to the disk it isn't a multi-threaded application. All of the writes in SILA are done with Linux asynchronous IO. Now what this means is that SILA becomes sensitive to the performance of the file system. So the performance of the database is no longer the issue and now it's how well does your file system handle asynchronous IO. And what that means is that the kind of performance results we're seeing with SILA will show up with XFS which happens to have excellent asynchronous support. But you're not going to see the dramatic high SILA performance with file systems that don't have as solid support for asynchronous IO. Now I said something a little bit earlier about the speed of development that SILA was able to achieve taking a fairly complex NoSQL development project and making it happen in a year. And this doesn't sound like the kind of thing that's possible to achieve with a thread per core architecture and every core having to communicate with every other core by message passing. That sounds like a really hard system. The big win from the CSTAR framework that SILA is based on is it gives the C++ programmer a set of abstractions to work with to make it possible to develop with that model in a reasonable amount of time with a high quality level. So the constructs of futures, promises, and continuations make it so that the programmer who's developing SILA can work with functions that return values that you can reason about rather than just handling message passing across cores by hand. Now a lot of database tuning is based on tuning how Linux handles the page cache for disk IO. And SILA has taken the approach of instead of relying on the OS to cache blocks the SILA design has a built-in cache. And then everything that goes to disk is asynchronous IO. And what this means is that instead of in a conventional layout where the database might modify one row within a 4K block and then the OS has to spew that whole 4K block out to disk in SILA it would be modifying data in memory. And then when that cache gets written out to disk SILA has application level knowledge of the cache and can just write out the data that needs to be written out. So there's no such thing as a parasitic row which is a row that needs to be or a row that doesn't need to be written out that kind of tags along with one that does. Oh, okay. Yes, yes, yes. The SS tables are written in a different way. They're written using asynchronous IO. They're using a more efficient mechanism. But the bits that end up on disk are the same as what gets there from the old school Cassandra way. Yeah, well if you look back in the day how did Linux get asynchronous IO in the first place? That was Oracle developers saying we need this feature. So Linux didn't have asynchronous IO to the best of my knowledge until the Oracle people were working on porting their database and they ran into a very similar issue. So a lot of the high performance techniques in SILA are things that have already existed in operating systems and in relational databases. However, they haven't yet been applied to NoSQL. So there's some computer science wisdom of the ages that's being dug up and reapplied to this kind of task. As well as some of the more innovative sharding and the futures promises continuations model, there's also some, well let's go back and look at things that Oracle had figured out in the late 90s or early 2000s and other relational databases have also taken advantage of. Oh yeah, sure, sure. Well repairs can be faster because when your round trips are significantly faster because you never have a Java garbage collection for example instead of having some transactions face a high latency then everything comes back quickly then a complex operation like a repair is going to complete more quickly as well and in a more predictable amount of time. Okay, so this is the simple version if you need a pony. Okay, so I didn't know about the 1024x768 requirement. I can show you the SILA CQL request served per second. This is a system that's doing about two million requests per second and you'll notice it's consistently high and this is across a three-node cluster by the way, two million across a three-node cluster and there are details on this benchmark on the SILA block. And it takes a little while to come up to speed and the overall throughput is lower. That's just the basics. Now the interesting metric here is latency and this graph is a little complicated. The throughput is here so SILA is doing over 250,000 CQL requests per second and Cassandra is doing about 150,000. So SILA is running a little bit higher throughput than Cassandra in this scenario and then the y-axis over on the other side this is latency in milliseconds. Okay, so mean latency SILA is a little quicker than Cassandra or substantially, median still substantially quicker. 95th you can see a little bit more in the 95th percentile for Cassandra latency but once you start to get into that 99th and 99.9th percentile you start to see these over 5 millisecond latencies on the Cassandra side while SILA is still consistently pretty low. So this is the latency of the slowest .1% of requests. The slowest of the slow, the ones that happen to hit a slow path in the system. It doesn't mean that one box is slow it means that if a box is serving a million requests it will serve a thousand slow requests. There are a bunch of these that actually the SILA developers are running all the time so the ones that we make the graphs for tend to be the ones that are more representative. Yeah, yeah, yeah, and we do them on different infrastructures so we've done some on different bare metal configurations and on Amazon. What's SILA written in? What's SILA written in? SILA is written in C++14. It's the first database that we know of to be written in the latest version of the C++ language. Yeah, and the horizontal lines go with the numbers on the right side and the bars go with the numbers on the left side. Yeah, yeah. Well, it's not necessarily because of low latency that the throughput is high. It's possible to have a system that has very high throughput and very high latency. And so as the throughput goes up then the latency also tends to go up in a production system. So yeah, you have to balance them. And in this case it's a test where Cassandra actually got a little advantage because it's running at a lower throughput and being compared straight up on latency. And this is just an example of a quick repair. This is using the node tool command for Cassandra. And it starts a repair at 1733.44 and it's done at 1734.10. So we'll have some more detailed benchmarks on quick repairs too. So once you have the speed what can you do with it? And it's not just a matter of paying a smaller bill to your cloud provider, although that's nice too. You can shrink the overall number of nodes in the cluster. You can make it faster to scale your cluster up and down for big events such as Black Friday for retail or for example if you're doing an online game and you have a big release of an expansion pack or something and a lot of people are playing you can ramp up the number of nodes for your game. You can do more with modeling your data instead of simplifying your data model on a performance-driven basis. Cassandra lets you do a lot and so it all lets you do the same stuff but you can do more interesting designs of your data model. And operations like repairs can happen without bogging down the cluster. There's just extra performance overhead to play with which means that administration becomes a lot less painful. So what's that? Because you have the extra performance you can use a more sophisticated data model. Sometimes in designing a Cassandra data model you end up having to denormalize things and make extra tables just to handle specific queries. With SILA you still have to do some of that. It's not going to do your computer science for you but you have more options in how you design your data. Different data models can be acceptably fast. No, not necessarily. But because you have more performance you can either use that to have fewer boxes or you can have more performance overhead to use for things like running your repairs online or doing more sophisticated queries on the same data. And so that just means that you can chill. I saw this building and I had to take a picture of it because this is the data center where people who have simple NoSQL databases can go. It's not the stuff that has to be tweaked and babysat constantly. Alright, so what's coming up next with SILA? Well, we're looking to build a community. People who want to do stuff that plugs into SILA are especially welcome. You do not have to be a C++ expert to get into it. We have some DevOps stuff that we're working on and looking for anybody who wants to make something interesting and have a good NoSQL data store for it. Of course the core database continues to improve. We're already integrated with Apache Spark but of course there's a huge stack of stuff that will connect to Cassandra and we're hooking all that up to SILA as well, including management tools. And then there's the possibility of having SILA also implement more protocols and not just the Cassandra protocol. So if you have ideas there then please get on our mailing list and we can discuss that. Stuff that we just come up with in the past couple of releases. We're doing a beta release every few weeks now. Past few releases have had a new official AMI. This one's using CentOS 7. We recently introduced SSL support and the alter table command so you can change your schema on the fly. Sleep mode, this is good. At the very first few releases of SILA we had a polling mode where every core is running flat out waiting for more inbound traffic. This is great for speed, not so great for your battery, if you're developing on a laptop. So sleep mode will now let SILA go to sleep and wait for you to run your tests on your laptop again. I'm especially happy about this one because now I can just turn my laptop around and do my SILA development and test on it. We have a project that is not actually even part of SILA. It's called Cassandra Test and Deploy. That is based on Ansible. It's a way to easily spin up a bunch of Cassandra nodes and test different failure scenarios on them. Or of course SILA nodes. Any time you want to test SILA against something else or just try something out on Cassandra, then check out the Cassandra Test and Deploy project. It's on GitHub. Go to GitHub SILADB and all our projects are there and you can find our GitHub page from the main website. There's a very simple contributor agreement that we ask people to accept in order to get code into the main SILADB project. That's just to say what you wrote and we can take it and do our stuff with it. We do commit to it being open source in that agreement. The way that the development process works is the code is hosted on GitHub and we use GitHub issues. However, we do not use GitHub pull requests. So if you have a change that you want to discuss and have the team consider for acceptance into SILA, that would be something that you would post to the mailing list. We have a document on how to make Git do that automatically. The Linux kernel developers have come up with a pretty slick system for taking a Git branch, turning it into a series of patches and posting it to a mailing list, and we use all that exact same stuff. It's essentially Linux kernel style development. As I mentioned before, you don't have to be a C++ programmer. If you're into Python, let me know. We'll do some DevOps. I'm building out from demo scripts to more deployment and easy ways to manage my SILA projects or projects that I have that are on top of SILA and I need to deploy SILA along with everything else. There's a knowledge base, so if you want to write something up for that, let me know. We'll see what kind of projects you come up with.