Slides:
[Music] okay so Sila DB is a nosql database it’s distributed so the way it used to be 20 years ago or even more is all the data was on one big computer a Mainframe and prevent a situation um happened where there is more data than can fit on one computer and also users wanted to create a situation where there is no single point of failure and that led to distributed databases and um the start of nosql and with distributed databases there is something that’s called the cap theorem which you can see on the screen right now and basically the theorem says that there are three attributes which we would like to optimize for in a distributed database and those are availability which means that the system will always be able to serve requests even if some of the nodes are down consistency in the database means that the latest right sorry so when we’re reading data we’ll always get the latest right and partition tolerance means that even if there’s a network failure or some other network problem uh the system would still be up and running and serving requests now the cap theorem states that we can’t have it all and there’s a trade-off and we have to give preference to two out of those three attributes and you can see I put different databases here on the triangle and some databases like mongodb for example prefer consistency over availability whereas in Sila Sandra Amazon dynamodb just for example as well as many others availability is given preference over consistency which doesn’t mean that the database is not consistent but it’s very highly available and I’ll talk about that in just a bit another way to classify nosql databases is according to the data model so some examples going from less complex to more complex would be key value storage databases examples are redis and aerospike where we simply have a key and a value it’s quite simple as it sounds and there you don’t even need like a special query language because you simply query for a key more complex is a document store such as mongodb or couchbase where you store uh data that is structured for example in XML format next in terms of complexity is a wide column store and there we store data in columns that you can think about as tables and some example here are still ADB Cassandra and others and finally graph Data Systems where data is stored according to the relationships between the data in terms of edges and vertices some examples Janus graph and neo4j and by the way Janus graphs can work with Sila DB as the underlying data storage
great so what are some attributes of Sila DB um Sila DB is highly available and that means that we have no single point of failure uh data is replicated so each piece of data is replicated across more than one node a node is basically uh the cldb software running on a computer and that means that even if there is a network failure or some nodes are unavailable because I don’t know there’s an earthquake or a fire or the computer stopped working the system would still be up and running and serving quests second attribute is scalability so it’s easy to scale the system by adding more nodes and we just had Black Friday last week so let’s say you’re an e-commerce website and you know that for Black Friday you’re going to have more traffic you’re going to be serving more requests so you can simply scale up your system by adding more nodes and you can do that without any downtime so you can do that as the system is running um and then you’d be able to serve more requests and later on maybe after Black Friday you’re also going to be able to scale down again by removing those notes Sila is highly performant so um when comparing to some other databases some other nosql databases we have up to timestand the performance so that’s high throughput and low latency and you can see some of the examples and benchmarks on our website I won’t really get into that Sila is built with low maintenance in mind so it auto-tunes itself and requires the least possible maintenance to make your lives easier and very importantly Sila is a drop in replacement for Apache Cassandra and dynamodb and that means that if you have an existing application using Apache Cassandra or dynamodb as the underlying database you can simply change from those databases to Sila and have your application work pretty much as it is with cldb and then you get the benefits of better performance and lower cost and other things for example with dynamodb no vendor lock-in and if you’re interested in dynamodb then I recommend you check out um I believe it’s uh Felipe’s session in the advanced track I think it’s the third session so um Sila is widely used by some large companies you can see some logos here um you can see more use case stories on the website I don’t really want to get into that some of the design decisions so the chart per core architecture with Sila we have uh on the right hand side you can see that what we basically do in terms of architecture we take resources and we take data and each one is segregated so that we don’t have a thread pool like in Cassandra or other systems which is what you can see on the left hand side here so here you have 12 balls of food and 12 poppies but you can see some balls are nobody’s eating from them some puppies are eating from the same bowl and it creates quite a mess because they’re basically sharing the resources um and that relates to um bad performance and um High latency whereas with the sharp per core architecture because each puppy has their own resource it looks quite neat each one is eating from their own bowl and that translates to better performance in terms of the ecosystem so we have drivers in different languages Integrations with different third-party software just to name a few uh I mentioned Janice graph Kafka kubernetes spark and also if Cassandra is a popular database and if there is an integration with Cassandra then that is probably going to work with Sila as it is and we have a lot of information about the different drivers on Sila University
okay so I mentioned uh performance and also cost I won’t go into all the details but if we compare Sila to Cassandra in a benchmark that we did so we compared four sealer nodes working versus 40 Cassandra nodes and even though we were using less nodes we reached a solution that was uh 2.5 less expensive with uh 11 times better latencies and if you want to see the details you can see that on the website with exact benchmarks and um the share between read and write and you can recreate that and if we compare to dynamodb we got better better latencies at a reduced cost okay Sila comes in three different flavors so I didn’t mention it so far but Sila is open source software you can check it out on git and you can see this see the source code yourself play around with it make changes and it’s Community Based so you can also make contributions and add features and so on that’s the open source version second flavor that we have is Sila DB Enterprise which is based on Silo open source however we have some extra features for example uh still a manager and the main thing I think with seal Enterprise is that you get our full uh 24 7 support that’s Mission critical so if you’re running a database and you want to be sure that there’s no downtime you get help from us using Sila Enterprise and you can run seal Enterprise either um on on the cloud so AWS and others or you can run it on Prem and last but not least we have still ADB Cloud which is our managed database as a service offering and that’s becoming more popular and we see more and more users choosing that option and by doing that basically we manage the database for you and you don’t have to worry about things like backups repairs security hardening performance we do that for you and you can focus on your core business foreign foreign
