Summary
If you like the features of Cassandra DB but wish it ran faster with fewer resources then ScyllaDB is the answer you have been looking for. In this episode Eyal Gutkind explains how Scylla was created and how it differentiates itself in the crowded database market.
Preamble
- Hello and welcome to the Data Engineering Podcast, the show about modern data infrastructure
- Go to dataengineeringpodcast.com to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch.
- You can help support the show by checking out the Patreon page which is linked from the site.
- To help other people find the show you can leave a review on iTunes, or Google Play Music, and tell your friends and co-workers
- Your host is Tobias Macey and today I’m interviewing Eyal Gutkind about ScyllaDB
Interview
- Introduction
- How did you get involved in the area of data management?
- What is ScyllaDB and why would someone choose to use it?
- How do you ensure sufficient reliability and accuracy of the database engine?
- The large draw of Scylla is that it is a drop in replacement of Cassandra with faster performance and no requirement to manage th JVM. What are some of the technical and architectural design choices that have enabled you to do that?
- Deployment and tuning
- What challenges are inroduced as a result of needing to maintain API compatibility with a diferent product?
- Do you have visibility or advance knowledge of what new interfaces are being added to the Apache Cassandra project, or are you forced to play a game of keep up?
- Are there any issues with compatibility of plugins for CassandraDB running on Scylla?
- For someone who wants to deploy and tune Scylla, what are the steps involved?
- Is it possible to join a Scylla cluster to an existing Cassandra cluster for live data migration and zero downtime swap?
- What prompted the decision to form a company around the database?
- What are some other uses of Seastar?
Keep in touch
Links
The intro and outro music is from The Hug by The Freak Fandango Orchestra / CC BY-SA
[00:00:14]
Unknown:
Hello, and welcome to the Data Engineering Podcast. The show about modern data management. You can go to www.dataengineeringpodcast.com to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch. You can help support the show by checking out the Patreon page, which is linked from the site. And to help other people find the show, you can leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media. Your host is Tobias Macy. And today, I'm interviewing Eyal Gutkind about Cilla DB.
[00:00:41] Unknown:
So, Eyal, could you please introduce yourself? Sure. Thank you, Tobias, for having us. My name is Eyal Gutkind. I'm a solution architect at CLDB, and, basically, we're working to help people put databases in a more efficient way, and that's what we do today. And how did you first get involved in the area of data management? So I started, 6 years ago. I started coming up from the hardware part. I was part of a company named Mellanox. We did, high performance networking, and 1 of the use cases are databases, high performance databases.
This is how I got involved. Later on, I moved through a company named, DataStax, which, provides Cassandra solutions today. And from there, I moved to Cielo DB. So that's my journey.
[00:01:31] Unknown:
That's interesting that you, had the experience in DataStax before moving to the competing product of silo or at least the, supplemental product. So for anybody who isn't already familiar with it, can you explain a bit about what Cilla DB is and what some of the advantages are that it has over some of the other products that are available?
[00:01:49] Unknown:
Sure. So c cilla DB, basically, it's, it's it's the world's fastest column store database. Basically, we are delivering the same functionality as Apache Cassandra, but the speed that we are providing, on top of it is basically the speed of, I would say, the lightest and the most, efficient key value store you can find in the market. But raw speed is is is not is just nice. It's a benchmark. CLLA is actually bringing you an order of magnitude, improvement to the performance, and we do it by basically redesigning the whole engine underneath the database and provide a very efficient usage of your either cloud based, on premise, or any type of other, infrastructure you use to make sure that, basically, the processes of using transactions and, back end processes are made in the most efficient way.
It's, the main core functionality that CELA brings into the market. For the more higher level, basically, you can think of us think of us as the next generation Cassandra solution out there. This is how we will be basically addressing ourselves.
[00:03:02] Unknown:
And what was the initial problem that was being faced when CillaDB was first created?
[00:03:07] Unknown:
Sure. So so let's I'll go to the roots. CillaDB started, as a programming framework. That's, called Cstar. Basically, the the the Cstar framework, it's a c plus plus framework. It's a shared nothing, architecture in a very efficient way that takes every process and attach it to a core inside your system. Making sure that any process you have in your application basically is able to use system in efficient way without getting clogged on CPUs or latencies on Ios and other, good stuff. When we were looking where to we can apply those type of that type of framework, we basically looked at databases, and 1 of them was Cassandra. Applying c star to Cassandra was fairly a straightforward process from our perspective, and this is how we found out that we can actually provide sometimes a tenfold performance, over current implementations of Cassandra.
More than that, the simplicity of usage is another aspect that you are when you're using a database, it's something that is is is almost, I would say, sometimes impeding the the ability to scale. Using a simple way to scale a solution without a lot of tuning is the other aspect of it. And looking at Cilla, basically, you can you can forget about all type of JVM tuning that, in many cases, you need to do in a Java based application. Those, tuning are not there anymore. We are able to provide a very efficient IO scheduling to make sure that we utilize your media as well as the CPUs in a more efficient way.
[00:04:46] Unknown:
So it's interesting that you ended up building a database from an even lower level of the underlying framework as a way to test out that framework, and then ended up moving forward with the database project. So 1 of the things that first attracted me to CLLA DB is the fact that it has that same capability and promise of Cassandra without the necessity of me having to run and manage the JVM. Because if you don't do that full time and make that your life, then it can be difficult to really understand what it's actually doing at all times and how to make sure that you can get proper reliability out of it. So on the note of reliability, particularly given the fact that Scylla is still a somewhat recent entree to the database market, I'm wondering what are some of the mechanisms or testing approaches that you use to make sure that the underlying engine is sufficiently reliable and accurate for, storing peep and managing people's data so that they can be confident that they can use it in a production context?
[00:05:46] Unknown:
Sure. You know, it's gonna be a little bit, cocky initially, but I'll go into the details later on. First of all, it's our customers, the guys who are actually using today's CELA in their implementations. We don't. We never heard a problem of stability. Yes. You know, sometimes we are lacking a fixture, here and there that they're looking for another management, capability they would like to have, but we have never heard about stability issues. And, also, even with what you called graceful failures, are something that we are able to provide them, and that that's the first part of it. The second 1 is there are, you know, during the process of of development, we have our own QA team who runs, different longevity tests on CELA and a constant benchmarking that is running whether it's by our team, the solution architects, to make sure that we are providing the customers with the right solution and and other capabilities in terms of benchmarking that is always being updated for our from our perspective.
We just published, a week ago, a benchmark of processing CELA on Oracle Cloud Bare Metal Services. And, you know, again and again, we're testing the solution on a constant level to make sure that we don't crash. But I think the best testimonial that we have is our customers.
[00:07:11] Unknown:
And so what are some of the technical and architectural design choices that have been made to enable you to ensure that faster performance and that, reliable uptime without, without resorting to the DVM while maintaining compatibility with Cassandra?
[00:07:28] Unknown:
Sure. So the for the performance side, there are, I would say, 3 aspects to it. First 1 that I mentioned is the basically the share nothing, architecture, and make sure that every core by itself has its own capabilities. And the second 1 is our memory management that we have at insula. So we don't, basically, our cache and code, there is nothing like that at Scylla. It's only 1 cache memory, so we are more efficient in in usage of that memory. Second 1 is, we don't have what's called phantom rows, so we don't fetch a prescribed block of information from the from the media.
We fetch the information you need, the the the information that is actually required by the the by the query to to make sure that we are very, very efficient in the usage of this extremely pricey resource. That that's the first 1. That's that's another technical part. Another, item is our networking stack, which is it's more efficient as well. So all these 3 items provide us the actual, ability to provide that specific performance. Have and in addition to that, if you think about the JVM processes, we do not need that, you know, memory management or garbage collection that you have in a JVM or in Java based application, basically, we are able to provide a very robust, all server included, capability.
If you look on the on the different applications, how they actually tell you which part of the JVM setting to put. For example, limit your memory, limit your CPUs, use which which, you know, how to use cache pages, etcetera. All that type of or needs are not there anymore. So it's a more tuned well tuned solution. I I want to add something to that. When you start CELA, basically, the first thing we do is we evaluate the system that you we are working on. So the actual, I would call it, quote unquote physical, whether it's cloud or physical server, we boot up sila and we learn what are the capabilities inside that machine. So sila will basically basically auto tune itself to the host that you're running with and making sure that we don't over subscribe, don't overcommit, don't underutilize this, again, the the the the price to resources that you have paid for, whether it's gonna be on the IO side, whether it's an SSD or a spindle disk, the amount of memory, the amount of cores that you have in the machine. All those parameters will be taken into CELA and basically auto tune itself, to that specific instance that you have provided us to put it on.
All these type of all those type of of, metrics provides you basically with the ability to be very, very accurate in terms of capacity and capabilities, and prevent, at the end of the day, overcommitting, oversubscribing, and then the end of the end of it is basically either a crash or a very poor performance from your side as a user.
[00:10:43] Unknown:
And are some of those auto tuning capabilities a byproduct of the fact that it's using the c star framework? Or are some of those routines something that's specific to the implementation of Cilla itself?
[00:10:55] Unknown:
Some yes and some no. For example, we are as I said before, we are actually tuning or learning what's the, let's say, your SSD capabilities are. We will learn exactly what is the most efficient point in terms of both latency and throughput of your SSD. Taking it back to CELA into the c star framework, we know exactly how many requests of IO we can actually, put concurrently into, that specific SSD. If we provide more if we actually put more concurrency to that specific use case, what will happen is the latency will just jump high and the performance and the capabilities from from you as a user are actually degraded.
So using that optimum point, it's something that you have to learn the system you're working with. It's impossible for any other framework to to actually use that type of, information. We take that information. We'll learn exactly what's the IO capabilities are and push it down to Cstar.
[00:11:58] Unknown:
And on more of the tuning piece in terms of the deployment environment, I know that, I was recently working on doing a test deployment of Cilla, and it was recommending the XFS file system for being able to get appropriate use utilization out of the underlying hard disk. So I'm wondering, if XFS itself has been deemed to be the best file system or if there are any other considerations that would factor into choosing 1 or another file system or any other specific, configuration parameters of the, OS that that that Silla is running on?
[00:12:33] Unknown:
So XFS, I think and it just not just me saying it or other or Cilla saying it. Other are saying it. It's the most today, it's the most efficient and most performant, file system out there. Having said that, we do understand that there are customers who, for example, want to stick with the EXT 4. It's not something that we don't see it. We do plan to support, e x t 4. If if customers are willing to understand that they might, you know sometimes they were willing to pay for performance for the usability. So that's that's the idea. We still recommend XFS as the most efficient, file system from our perspective.
[00:13:10] Unknown:
Yeah. I can back that up, experientially having used XFS for a particular use case where you need to write out and read back a lot of small files as rapidly as possible for something unrelated to databases, but specifically for small image formats. And in my experiment, I was able to get a drastic speed up by switching to XFS from XFS. So it it's understandable why you would recommend that as the underlying storage for the actual database system itself.
[00:13:40] Unknown:
Yeah. That that that's the main the main reason because, we we hate additional layers of either inefficiency or latency that actually impede our ability to provide, value to customers.
[00:13:54] Unknown:
So Cilla aims to be API compatible with the Apache Cassandra database. So I'm wondering what are some of the challenges that are introduced as a result of needing to maintain that compatibility? And are there any plans or even current implementations of, additional or alternative feature sets from the Apache Cassandra project?
[00:14:17] Unknown:
So so we definitely follow, what's going on on the Apache community, and we encourage everybody on the Apache community to come and and and follow us as well. We do want those community to, you know, help each other. Having said that, on the API part, it is sometimes a challenge. I must admit, it's not straightforward. But providing a a compatible IPA from our perspective is actually helping the Cassandra customers to understand the value that they can get from Cilla or the users themselves. It's it's a challenge to follow-up, sometimes on on a protocol. For example, we do want to support the 4, of CQL, and this is something that we are planning and and working on to bring it to the market as well. And, we do support, for example, the legacy Thrift protocol.
So we do have other protocols that we are able to implement on top of, CELA and provide that compatibility. It's it's not fun to play. I must admit, it's not fun to play always the game of catch up, but we also think that, in order to make sure that the usability of Scylla is easy, this is something this is a price we're willing to pay.
[00:15:31] Unknown:
And I know from speaking to people who have done similar approaches where they need to replicate the functionality of another system that oftentimes you not only have to replicate the intended use of the APIs and the intended output, but also the bugs that are implemented in different versions so that you can have a truly drop in replacement without any surprises. So I'm wondering,
[00:15:52] Unknown:
what, what kind of experiences you've had on that front? We did have some of those, and I'm lucky because, it's something that recently happened. And, you know, it does happen. There are sometimes, bugs that exist in a certain API that you replicate it and you find out people say, and you by the way, we fix some of those issues, and then people say, hey. It doesn't behave the same. So we have to replicate the bug as well. It it does happen. But but looking forward, definitely, it's something that we we do want to make sure that, our APIs are compatible, but we do think that there are other APIs in the market that we can definitely help and create, value in. And there are tons of them out there, whether there are caching systems, other databases, that are very, very I wouldn't say, dominant, but definitely is something that they are in the market. And we think that, using seal as the underlying asset for them, is something that can be useful.
[00:16:53] Unknown:
And I know that there are a number of plugins or, additional layers that can be run on top of Apache, such as the, open TSDB, and I believe it's Titan DB that was recently acquired to, be to to operate as a graph database layer on top of Cassandra. So I'm wondering, given the fact that Cilla doesn't use the JVM, whether it's possible to use those additional plugins or additional layers on Cilla the same way as they are used with the original Apache Cassandra project.
[00:17:24] Unknown:
It is possible. So so for example, you mentioned, Titan. Basically, that can use, Thrift protocol. 1 of the reason we provided Thrift protocol at Cilla is to be able to support Titan. So that's that's something that you can do today. Use Titan over Cilla. It works. People I think it was actually presented by, Jason Plurad from IBM, on our CELA summit in in September. Other ones that you would, you know, find very dominant and very, I would say, pervasive is the Keras DB 1. It's something that you can do that as well as the Apache, Spark.
So all those protocols are supported and are functional on top of CLLA.
[00:18:12] Unknown:
And so do those just run-in a JVM process, and they just use the standard of Cassandra APIs to send data back and forth just as with any other client library?
[00:18:22] Unknown:
Correct. For example, the Spark 1 will use simple, I would say simple, but use, the regular CQL, commands to move data back and forth. Same thing with Kairos, as I said, or Taitan, it's gonna be the 3rd protocol. So all of them, it's gonna be yes. It typically is an adjacent cluster that just put transactions back and forth to CLLA.
[00:18:45] Unknown:
So as new APIs are added to the upstream project, what's the lag that you typically have between when it's released upstream and when you're able to replicate it?
[00:18:55] Unknown:
It it depends. It sounds funny. Basically, we make sure that if if there is something new and we find out that it is something that most user look for it, but will be faster to implement, even with our current solution without going to through major revisions. It's something that we always look look to. It's it's not every API that we think that is available on the Apache Cassandra is is something that is highly usable. We try to make sure that, the APIs that we provide actually help, users to use cilla /Cassandra
[00:19:33] Unknown:
in a more parallel way, let's call it. And if you already have an existing Cassandra cluster and you're interested in moving all or at least a portion of the your data to Cilla, is it possible for Cilla to join that cluster that existing cluster and do a live data migration via replication so that you can have a 0 downtime swap so that you can bring Cilla into production without ever having to take your cluster down?
[00:19:58] Unknown:
So the the the the short answer is is yes, and the the longer answer is no. So CELA has a a a a different gossip protocol. So you cannot join a CELA node to an existing Cassandra cluster. They just would not talk to each other. That's not gonna happen. There are 2 ways you can do that type of migration. 1 option is to stand up a parallel sila cluster next to your Cassandra 1 and do a dual write and dual reads. And once you feel confident enough that those transaction transactions are not, deferring in any way or shape, we can we can shut down your Cassandra cluster and use only the c l a 1. That's the most straightforward way to I would say.
And the the more enterprise y way, we do have a solution to help migration, from Cassandra do Silla. This is part of our enterprise product, and this is something that we are able to provide you. It's we basically hook up on your, Cassandra cluster and replicate the transactions into the silo 1. That's a that's a possibility. Most of our customers choose the first option as of today, and that's, something that it's very popular. Basically, they don't need our help at that point. Stand up a sila cluster, stand up a Cassandra cluster. We do have compatibility on the SS stable format. So if you're using it to the 1 dot x as a stable format, you can copy the SS tables to the sila cluster. Make sure that you have the right token ranges in every node.
Fire up the cluster and let it catch up with your customer cluster. At the end of the catch up process, basically, you can shut down the Cassandra 1.
[00:21:46] Unknown:
And given the fact that you are able to get such higher throughput and performance on a sila cluster from a correspondent Cassandra 1, I imagine that there are times where if you're not running a substantially large Cassandra cluster, that it might make sense from a cost perspective to actually run Cilla in a single node environment. But at the same time, you'd be trading off the, redundancy and high availability guarantees that you get by running a cluster. So I'm wondering if you've had people run into that kind of situation or if it just makes sense for them to simply run it on smaller hardware and still cluster it together.
[00:22:22] Unknown:
I would argue that if you're trying to find a way to whether it's Cassandra or Celera, run it on a single node for a production environment, I think you're doing a disservice to both technologies. That I would say that that's it's an anti pattern for the actual implementation. The idea of of Cassandra slash CELA is high availability and and basically, resiliency, And you would need cluster. You can definitely shrink the cluster. So we have seen clusters of a 100, 200 nodes of Cassandra shrinking down to 30 and 50 and 60 nodes. So then the cost saving is significant and imminent to the operation team. It's not just the cost of the hardware or the cost of the cloud services, it's also the cost of managing it.
Managing a 200 node cluster or a 100 node cluster requires a lot of resources, both human as well as as as systems, and shrinking down by 3, 4 folds, the size of the cluster basically release those resources to do more efficient and more adequate processes for your business and not, you know, just help help them, look on on on metrics that come from a 100 nodes. That that's something that we have seen, and we we are seeing it every day that we work. Those are the those are the main gains that we are able to see in terms of shrinking. Going down from 3 to 1, I I wouldn't say it's not possible. It's possible. Most of functional tests that, for example, I do will be running on my, virtual box on my laptop.
But definitely, it's I wouldn't recommend any production system to go that route.
[00:23:59] Unknown:
Yeah. I I would definitely agree on that front. Being somebody who manages infrastructure for my day job, anytime I see a potential for a single point of failure, it, just makes me cringe. So I I definitely appreciate systems like Scylla and Cassandra that are easily clustered for high availability and reliability because it makes me sleep easier at night knowing that even if I do have a catastrophic node failure, I can still just continue sleeping because everything will stay running until the
[00:24:26] Unknown:
morning. And that's the main use. And and not just that. Think about multi data center replication that comes automatically in this architecture. It's the 1 of the, I think, the key values for using such a master multi master architecture that we have. And I we see those as the most, we'll say, dominant use cases.
[00:24:45] Unknown:
Yeah. Being able to replicate across data and across regions is definitely highly valuable for latency purposes if you're serving a global audience because of the fact that you can locate the data closer to the consumer as opposed to a more traditional database like MySQL or Postgres where it becomes fairly difficult to handle sharding or replication just because of the nature of the database itself and the way that it's structured. When you do need to go multi region, it's typically quite a headache or it even potentially necessitates a complete architectural shift in the way that you manage your data.
[00:25:20] Unknown:
That that's exactly the other cases. We see people shift when when they need to scale and mostly in the, I would call, web front applications when they find out that, okay. That's it. We scale to the maximum we can get from our current solution. The first thing they they find out is basically the SIL architecture. And that's, I would say, the the number 1 transformation phase we have seen.
[00:25:44] Unknown:
And you've you've mentioned a couple of times some of the services that you provide as a company around sale of the database. So I'm wondering what prompted the decision to form a company around the database once it was created, and also some of the challenges that you faced as a company that is trying to make money off of an open source database, particularly in light of recent failures such as RethinkDB?
[00:26:06] Unknown:
So I think we all read the RethinkDB blog, an excellent blog, by the way, in my opinion. I present so it it is it is a challenging environment. Don't get me wrong. And the the value that we're bringing in is basically our knowledge of both the database itself, how how it is operating, as well as the additional capabilities. We do have an enterprise version that we have additional enterprise features that people are looking for. For example, security, and you can think of any other type of, enterprise grade capabilities you need. So that's an enterprise version.
And in terms of information, that we provide to the users, we do have our own professional services to help users that need those capabilities to, you know, speed up their ramp up or don't have the technical depth to to maintain a cluster like that, we definitely come in and help them. Those are the services that we provide for a fee, and we see more and more customers looking for those services. So both the support, the enterprise features, as well as the, services on top of them is something that people are use using us for. We do also provide training. So if you are a novice or even if if you are, you know, a proficient user of CELA, we are more than happy to come in and provide you with training whether it's gonna be just, if you just need a jump start. So it's typically a single day, or you need a deep dive, to seal up to the architecture and the way it's it's it's operate.
That's a 3 day class that we provide. So this is how we make money. In terms of competition, as as always, I think as any other open source, we typically compete with ourselves. The open source competes with the enterprise. And but that's, I think, the nature of this business. If we're gonna be successful, I believe that we do. I think we have a winning product. I do think we have an advantage of the current, implementations that that are out there in the market. I do hope that customers are are able to see those value values and willing to pay for them. And, that's that's the idea at the end of the day.
[00:28:23] Unknown:
So going back to the c star framework, you were saying that, Sylloa was essentially initially created as a proof of concept for the c star framework. So I'm wondering if there's any intent to maybe build out different types of database systems with c c star or other kinds of applications? And, also, what are some other uses of c star from other projects that you're aware of that, you found particularly interesting?
[00:28:49] Unknown:
Sure. Sure. So there is 1, Systar is, again, is an open source. So we have seen, somebody took, Sysstar and created a a Redis database on top of it. So it's called pedis, p e d I s. So we encourage those. By all means, we think it's a it's a it's a value that, Sysco can bring to the market. I can tell you that right now, our hands are full both with customers and features that we want to bring into CELA. But if you look on the presentation by Abhikiviti, CELA's CTO, You'll see that we have multiple ideas in the analytics space and in the search space, in terms of storage efficiencies, and many more goodies that we want to bring into the market. So I I think that we really have a a handful tasks to make, and I don't think there is enough time in the in the day to complete them all.
So we do look outside our box and understand exactly what the applications are going and what are the use cases, and those are the items that we're looking for. I'll give an example. We see a lot of people using CELA, for example, for their IoT project or sensor data.
[00:30:03] Unknown:
It's something that we definitely want to look into. Yeah. And that brings up another interesting point is when you are working on providing compatibility with an existing existing system so that you can be a drop in replacement. Wondering what you see as the areas of innovation given that you that most of it can't be done externally in terms of the interfaces that you provide to other people using the system. So it means that a lot of the innovation needs to happen internally or under the covers. So I'm wondering what your experiences are with that. I I will not disclose probably most of the information, on this podcast as a public 1,
[00:30:40] Unknown:
but definitely, it's something that we take the feedback in. We try to find the solutions and, as you said, to bring the innovation to the customer under the umbrella, of, CQL and and the actual a p APIs that we have today. However, we are not we're not gonna be shy if there is a need to provide some type of, a specific capability to a specific use case. We think it's something that, we will be able to provide customers in addition to the implementation that they are familiar with and the drop replacement capabilities.
[00:31:14] Unknown:
Are there any other subjects you think we should cover before we start to close out the show? Use Cielo. You know, it's, I do think that Cielo can provide value to customers who are
[00:31:25] Unknown:
either struggling with their current Cassandra implementation or they want to use it as a on a greenfield type of implementation. I think we are we able to be very efficient, very easy to deploy. It's something that, you know, sometimes people don't discount, the time to to working. So if you are you know, you you don't want to make you want to make sure that database installation is not your business, but something else is your business, for example, whether it's a customer's retention program, IoT, time series, implementing sila is very simple. It's a it's a it's a simple 1 script that makes all the tuning for you and bring you a working, database in into your front door. That's that's the idea here.
[00:32:15] Unknown:
And that, reminds me 1 thing that we didn't cover yet is given that it is a more low level language implementation, I imagine that that somewhat restricts the platforms that it can run on. So the JVM, you could potentially run it on Windows or OSX and Linux. But I'm wonder I'm assuming that the platform, the the deployment targets for Silla are a little bit more constrained. Is that correct? Well,
[00:32:40] Unknown:
yes and no. I have not yet notes haven't seen any implementation of Cassandra or Cilla, on other systems in Linux. And I think that most implementations of the NoSQL space are on on a Linux based machine. Yes. There are implementations that use both OS X and and, Windows, but I think there is a a vast market that is using the, Linux space. We are supporting both, you know, Reddit, CentOS, Ubuntu, Debian, platforms. So I think it covers, most of the market that I don't think that should be the the preventing item from actually implementing,
[00:33:25] Unknown:
a silo. Yeah. I I can agree on that front. I I I don't think I would want to run it on Windows or OSX, but I suppose if somebody did want to, they could. I I I just, wouldn't be the 1 supporting it for them.
[00:33:37] Unknown:
Yeah. It's it's I'm not I'm not bashing those operating system. I am, I'm not I'm I am an an avid OSX user. I don't I don't get I don't I'm not shy of it, but I I don't think that's the right platform for such a database. As we said before, it's it's it's for a clustered, system. That that's where we're targeting Cilla.
[00:33:55] Unknown:
For anybody who wants to keep in touch with you and Cilla, I'll ask you for your preferred contact information, and I'll add that to the show notes in case anybody wants to get in touch and, dig a bit deeper into Silla.
[00:34:07] Unknown:
Sure. So couple of things. If you want to, join Silla or you want to work with Silla, I highly recommend we have our website, which is at, www.silla db.com. We have our public Slack channel. We have a public mailing list. Please jump on it. Use it. We are constantly listening, and we're constantly answering. And I can tell you, answering is darn fast, these days. So we have, people really jumping on to help customers, board Scylla.
[00:34:40] Unknown:
Well, I, appreciate your time this evening. It was a pleasure to get to learn a bit more about Scylla and how it came to be and some of the different ways that I can leverage it. And I'm sure a number of other people will be giving it another look. So thank you for your time, and I hope you enjoy the rest of your evening.
[00:34:56] Unknown:
Thank you very much, Luis. Appreciate it.
Hello, and welcome to the Data Engineering Podcast. The show about modern data management. You can go to www.dataengineeringpodcast.com to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch. You can help support the show by checking out the Patreon page, which is linked from the site. And to help other people find the show, you can leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media. Your host is Tobias Macy. And today, I'm interviewing Eyal Gutkind about Cilla DB.
[00:00:41] Unknown:
So, Eyal, could you please introduce yourself? Sure. Thank you, Tobias, for having us. My name is Eyal Gutkind. I'm a solution architect at CLDB, and, basically, we're working to help people put databases in a more efficient way, and that's what we do today. And how did you first get involved in the area of data management? So I started, 6 years ago. I started coming up from the hardware part. I was part of a company named Mellanox. We did, high performance networking, and 1 of the use cases are databases, high performance databases.
This is how I got involved. Later on, I moved through a company named, DataStax, which, provides Cassandra solutions today. And from there, I moved to Cielo DB. So that's my journey.
[00:01:31] Unknown:
That's interesting that you, had the experience in DataStax before moving to the competing product of silo or at least the, supplemental product. So for anybody who isn't already familiar with it, can you explain a bit about what Cilla DB is and what some of the advantages are that it has over some of the other products that are available?
[00:01:49] Unknown:
Sure. So c cilla DB, basically, it's, it's it's the world's fastest column store database. Basically, we are delivering the same functionality as Apache Cassandra, but the speed that we are providing, on top of it is basically the speed of, I would say, the lightest and the most, efficient key value store you can find in the market. But raw speed is is is not is just nice. It's a benchmark. CLLA is actually bringing you an order of magnitude, improvement to the performance, and we do it by basically redesigning the whole engine underneath the database and provide a very efficient usage of your either cloud based, on premise, or any type of other, infrastructure you use to make sure that, basically, the processes of using transactions and, back end processes are made in the most efficient way.
It's, the main core functionality that CELA brings into the market. For the more higher level, basically, you can think of us think of us as the next generation Cassandra solution out there. This is how we will be basically addressing ourselves.
[00:03:02] Unknown:
And what was the initial problem that was being faced when CillaDB was first created?
[00:03:07] Unknown:
Sure. So so let's I'll go to the roots. CillaDB started, as a programming framework. That's, called Cstar. Basically, the the the Cstar framework, it's a c plus plus framework. It's a shared nothing, architecture in a very efficient way that takes every process and attach it to a core inside your system. Making sure that any process you have in your application basically is able to use system in efficient way without getting clogged on CPUs or latencies on Ios and other, good stuff. When we were looking where to we can apply those type of that type of framework, we basically looked at databases, and 1 of them was Cassandra. Applying c star to Cassandra was fairly a straightforward process from our perspective, and this is how we found out that we can actually provide sometimes a tenfold performance, over current implementations of Cassandra.
More than that, the simplicity of usage is another aspect that you are when you're using a database, it's something that is is is almost, I would say, sometimes impeding the the ability to scale. Using a simple way to scale a solution without a lot of tuning is the other aspect of it. And looking at Cilla, basically, you can you can forget about all type of JVM tuning that, in many cases, you need to do in a Java based application. Those, tuning are not there anymore. We are able to provide a very efficient IO scheduling to make sure that we utilize your media as well as the CPUs in a more efficient way.
[00:04:46] Unknown:
So it's interesting that you ended up building a database from an even lower level of the underlying framework as a way to test out that framework, and then ended up moving forward with the database project. So 1 of the things that first attracted me to CLLA DB is the fact that it has that same capability and promise of Cassandra without the necessity of me having to run and manage the JVM. Because if you don't do that full time and make that your life, then it can be difficult to really understand what it's actually doing at all times and how to make sure that you can get proper reliability out of it. So on the note of reliability, particularly given the fact that Scylla is still a somewhat recent entree to the database market, I'm wondering what are some of the mechanisms or testing approaches that you use to make sure that the underlying engine is sufficiently reliable and accurate for, storing peep and managing people's data so that they can be confident that they can use it in a production context?
[00:05:46] Unknown:
Sure. You know, it's gonna be a little bit, cocky initially, but I'll go into the details later on. First of all, it's our customers, the guys who are actually using today's CELA in their implementations. We don't. We never heard a problem of stability. Yes. You know, sometimes we are lacking a fixture, here and there that they're looking for another management, capability they would like to have, but we have never heard about stability issues. And, also, even with what you called graceful failures, are something that we are able to provide them, and that that's the first part of it. The second 1 is there are, you know, during the process of of development, we have our own QA team who runs, different longevity tests on CELA and a constant benchmarking that is running whether it's by our team, the solution architects, to make sure that we are providing the customers with the right solution and and other capabilities in terms of benchmarking that is always being updated for our from our perspective.
We just published, a week ago, a benchmark of processing CELA on Oracle Cloud Bare Metal Services. And, you know, again and again, we're testing the solution on a constant level to make sure that we don't crash. But I think the best testimonial that we have is our customers.
[00:07:11] Unknown:
And so what are some of the technical and architectural design choices that have been made to enable you to ensure that faster performance and that, reliable uptime without, without resorting to the DVM while maintaining compatibility with Cassandra?
[00:07:28] Unknown:
Sure. So the for the performance side, there are, I would say, 3 aspects to it. First 1 that I mentioned is the basically the share nothing, architecture, and make sure that every core by itself has its own capabilities. And the second 1 is our memory management that we have at insula. So we don't, basically, our cache and code, there is nothing like that at Scylla. It's only 1 cache memory, so we are more efficient in in usage of that memory. Second 1 is, we don't have what's called phantom rows, so we don't fetch a prescribed block of information from the from the media.
We fetch the information you need, the the the information that is actually required by the the by the query to to make sure that we are very, very efficient in the usage of this extremely pricey resource. That that's the first 1. That's that's another technical part. Another, item is our networking stack, which is it's more efficient as well. So all these 3 items provide us the actual, ability to provide that specific performance. Have and in addition to that, if you think about the JVM processes, we do not need that, you know, memory management or garbage collection that you have in a JVM or in Java based application, basically, we are able to provide a very robust, all server included, capability.
If you look on the on the different applications, how they actually tell you which part of the JVM setting to put. For example, limit your memory, limit your CPUs, use which which, you know, how to use cache pages, etcetera. All that type of or needs are not there anymore. So it's a more tuned well tuned solution. I I want to add something to that. When you start CELA, basically, the first thing we do is we evaluate the system that you we are working on. So the actual, I would call it, quote unquote physical, whether it's cloud or physical server, we boot up sila and we learn what are the capabilities inside that machine. So sila will basically basically auto tune itself to the host that you're running with and making sure that we don't over subscribe, don't overcommit, don't underutilize this, again, the the the the price to resources that you have paid for, whether it's gonna be on the IO side, whether it's an SSD or a spindle disk, the amount of memory, the amount of cores that you have in the machine. All those parameters will be taken into CELA and basically auto tune itself, to that specific instance that you have provided us to put it on.
All these type of all those type of of, metrics provides you basically with the ability to be very, very accurate in terms of capacity and capabilities, and prevent, at the end of the day, overcommitting, oversubscribing, and then the end of the end of it is basically either a crash or a very poor performance from your side as a user.
[00:10:43] Unknown:
And are some of those auto tuning capabilities a byproduct of the fact that it's using the c star framework? Or are some of those routines something that's specific to the implementation of Cilla itself?
[00:10:55] Unknown:
Some yes and some no. For example, we are as I said before, we are actually tuning or learning what's the, let's say, your SSD capabilities are. We will learn exactly what is the most efficient point in terms of both latency and throughput of your SSD. Taking it back to CELA into the c star framework, we know exactly how many requests of IO we can actually, put concurrently into, that specific SSD. If we provide more if we actually put more concurrency to that specific use case, what will happen is the latency will just jump high and the performance and the capabilities from from you as a user are actually degraded.
So using that optimum point, it's something that you have to learn the system you're working with. It's impossible for any other framework to to actually use that type of, information. We take that information. We'll learn exactly what's the IO capabilities are and push it down to Cstar.
[00:11:58] Unknown:
And on more of the tuning piece in terms of the deployment environment, I know that, I was recently working on doing a test deployment of Cilla, and it was recommending the XFS file system for being able to get appropriate use utilization out of the underlying hard disk. So I'm wondering, if XFS itself has been deemed to be the best file system or if there are any other considerations that would factor into choosing 1 or another file system or any other specific, configuration parameters of the, OS that that that Silla is running on?
[00:12:33] Unknown:
So XFS, I think and it just not just me saying it or other or Cilla saying it. Other are saying it. It's the most today, it's the most efficient and most performant, file system out there. Having said that, we do understand that there are customers who, for example, want to stick with the EXT 4. It's not something that we don't see it. We do plan to support, e x t 4. If if customers are willing to understand that they might, you know sometimes they were willing to pay for performance for the usability. So that's that's the idea. We still recommend XFS as the most efficient, file system from our perspective.
[00:13:10] Unknown:
Yeah. I can back that up, experientially having used XFS for a particular use case where you need to write out and read back a lot of small files as rapidly as possible for something unrelated to databases, but specifically for small image formats. And in my experiment, I was able to get a drastic speed up by switching to XFS from XFS. So it it's understandable why you would recommend that as the underlying storage for the actual database system itself.
[00:13:40] Unknown:
Yeah. That that that's the main the main reason because, we we hate additional layers of either inefficiency or latency that actually impede our ability to provide, value to customers.
[00:13:54] Unknown:
So Cilla aims to be API compatible with the Apache Cassandra database. So I'm wondering what are some of the challenges that are introduced as a result of needing to maintain that compatibility? And are there any plans or even current implementations of, additional or alternative feature sets from the Apache Cassandra project?
[00:14:17] Unknown:
So so we definitely follow, what's going on on the Apache community, and we encourage everybody on the Apache community to come and and and follow us as well. We do want those community to, you know, help each other. Having said that, on the API part, it is sometimes a challenge. I must admit, it's not straightforward. But providing a a compatible IPA from our perspective is actually helping the Cassandra customers to understand the value that they can get from Cilla or the users themselves. It's it's a challenge to follow-up, sometimes on on a protocol. For example, we do want to support the 4, of CQL, and this is something that we are planning and and working on to bring it to the market as well. And, we do support, for example, the legacy Thrift protocol.
So we do have other protocols that we are able to implement on top of, CELA and provide that compatibility. It's it's not fun to play. I must admit, it's not fun to play always the game of catch up, but we also think that, in order to make sure that the usability of Scylla is easy, this is something this is a price we're willing to pay.
[00:15:31] Unknown:
And I know from speaking to people who have done similar approaches where they need to replicate the functionality of another system that oftentimes you not only have to replicate the intended use of the APIs and the intended output, but also the bugs that are implemented in different versions so that you can have a truly drop in replacement without any surprises. So I'm wondering,
[00:15:52] Unknown:
what, what kind of experiences you've had on that front? We did have some of those, and I'm lucky because, it's something that recently happened. And, you know, it does happen. There are sometimes, bugs that exist in a certain API that you replicate it and you find out people say, and you by the way, we fix some of those issues, and then people say, hey. It doesn't behave the same. So we have to replicate the bug as well. It it does happen. But but looking forward, definitely, it's something that we we do want to make sure that, our APIs are compatible, but we do think that there are other APIs in the market that we can definitely help and create, value in. And there are tons of them out there, whether there are caching systems, other databases, that are very, very I wouldn't say, dominant, but definitely is something that they are in the market. And we think that, using seal as the underlying asset for them, is something that can be useful.
[00:16:53] Unknown:
And I know that there are a number of plugins or, additional layers that can be run on top of Apache, such as the, open TSDB, and I believe it's Titan DB that was recently acquired to, be to to operate as a graph database layer on top of Cassandra. So I'm wondering, given the fact that Cilla doesn't use the JVM, whether it's possible to use those additional plugins or additional layers on Cilla the same way as they are used with the original Apache Cassandra project.
[00:17:24] Unknown:
It is possible. So so for example, you mentioned, Titan. Basically, that can use, Thrift protocol. 1 of the reason we provided Thrift protocol at Cilla is to be able to support Titan. So that's that's something that you can do today. Use Titan over Cilla. It works. People I think it was actually presented by, Jason Plurad from IBM, on our CELA summit in in September. Other ones that you would, you know, find very dominant and very, I would say, pervasive is the Keras DB 1. It's something that you can do that as well as the Apache, Spark.
So all those protocols are supported and are functional on top of CLLA.
[00:18:12] Unknown:
And so do those just run-in a JVM process, and they just use the standard of Cassandra APIs to send data back and forth just as with any other client library?
[00:18:22] Unknown:
Correct. For example, the Spark 1 will use simple, I would say simple, but use, the regular CQL, commands to move data back and forth. Same thing with Kairos, as I said, or Taitan, it's gonna be the 3rd protocol. So all of them, it's gonna be yes. It typically is an adjacent cluster that just put transactions back and forth to CLLA.
[00:18:45] Unknown:
So as new APIs are added to the upstream project, what's the lag that you typically have between when it's released upstream and when you're able to replicate it?
[00:18:55] Unknown:
It it depends. It sounds funny. Basically, we make sure that if if there is something new and we find out that it is something that most user look for it, but will be faster to implement, even with our current solution without going to through major revisions. It's something that we always look look to. It's it's not every API that we think that is available on the Apache Cassandra is is something that is highly usable. We try to make sure that, the APIs that we provide actually help, users to use cilla /Cassandra
[00:19:33] Unknown:
in a more parallel way, let's call it. And if you already have an existing Cassandra cluster and you're interested in moving all or at least a portion of the your data to Cilla, is it possible for Cilla to join that cluster that existing cluster and do a live data migration via replication so that you can have a 0 downtime swap so that you can bring Cilla into production without ever having to take your cluster down?
[00:19:58] Unknown:
So the the the the short answer is is yes, and the the longer answer is no. So CELA has a a a a different gossip protocol. So you cannot join a CELA node to an existing Cassandra cluster. They just would not talk to each other. That's not gonna happen. There are 2 ways you can do that type of migration. 1 option is to stand up a parallel sila cluster next to your Cassandra 1 and do a dual write and dual reads. And once you feel confident enough that those transaction transactions are not, deferring in any way or shape, we can we can shut down your Cassandra cluster and use only the c l a 1. That's the most straightforward way to I would say.
And the the more enterprise y way, we do have a solution to help migration, from Cassandra do Silla. This is part of our enterprise product, and this is something that we are able to provide you. It's we basically hook up on your, Cassandra cluster and replicate the transactions into the silo 1. That's a that's a possibility. Most of our customers choose the first option as of today, and that's, something that it's very popular. Basically, they don't need our help at that point. Stand up a sila cluster, stand up a Cassandra cluster. We do have compatibility on the SS stable format. So if you're using it to the 1 dot x as a stable format, you can copy the SS tables to the sila cluster. Make sure that you have the right token ranges in every node.
Fire up the cluster and let it catch up with your customer cluster. At the end of the catch up process, basically, you can shut down the Cassandra 1.
[00:21:46] Unknown:
And given the fact that you are able to get such higher throughput and performance on a sila cluster from a correspondent Cassandra 1, I imagine that there are times where if you're not running a substantially large Cassandra cluster, that it might make sense from a cost perspective to actually run Cilla in a single node environment. But at the same time, you'd be trading off the, redundancy and high availability guarantees that you get by running a cluster. So I'm wondering if you've had people run into that kind of situation or if it just makes sense for them to simply run it on smaller hardware and still cluster it together.
[00:22:22] Unknown:
I would argue that if you're trying to find a way to whether it's Cassandra or Celera, run it on a single node for a production environment, I think you're doing a disservice to both technologies. That I would say that that's it's an anti pattern for the actual implementation. The idea of of Cassandra slash CELA is high availability and and basically, resiliency, And you would need cluster. You can definitely shrink the cluster. So we have seen clusters of a 100, 200 nodes of Cassandra shrinking down to 30 and 50 and 60 nodes. So then the cost saving is significant and imminent to the operation team. It's not just the cost of the hardware or the cost of the cloud services, it's also the cost of managing it.
Managing a 200 node cluster or a 100 node cluster requires a lot of resources, both human as well as as as systems, and shrinking down by 3, 4 folds, the size of the cluster basically release those resources to do more efficient and more adequate processes for your business and not, you know, just help help them, look on on on metrics that come from a 100 nodes. That that's something that we have seen, and we we are seeing it every day that we work. Those are the those are the main gains that we are able to see in terms of shrinking. Going down from 3 to 1, I I wouldn't say it's not possible. It's possible. Most of functional tests that, for example, I do will be running on my, virtual box on my laptop.
But definitely, it's I wouldn't recommend any production system to go that route.
[00:23:59] Unknown:
Yeah. I I would definitely agree on that front. Being somebody who manages infrastructure for my day job, anytime I see a potential for a single point of failure, it, just makes me cringe. So I I definitely appreciate systems like Scylla and Cassandra that are easily clustered for high availability and reliability because it makes me sleep easier at night knowing that even if I do have a catastrophic node failure, I can still just continue sleeping because everything will stay running until the
[00:24:26] Unknown:
morning. And that's the main use. And and not just that. Think about multi data center replication that comes automatically in this architecture. It's the 1 of the, I think, the key values for using such a master multi master architecture that we have. And I we see those as the most, we'll say, dominant use cases.
[00:24:45] Unknown:
Yeah. Being able to replicate across data and across regions is definitely highly valuable for latency purposes if you're serving a global audience because of the fact that you can locate the data closer to the consumer as opposed to a more traditional database like MySQL or Postgres where it becomes fairly difficult to handle sharding or replication just because of the nature of the database itself and the way that it's structured. When you do need to go multi region, it's typically quite a headache or it even potentially necessitates a complete architectural shift in the way that you manage your data.
[00:25:20] Unknown:
That that's exactly the other cases. We see people shift when when they need to scale and mostly in the, I would call, web front applications when they find out that, okay. That's it. We scale to the maximum we can get from our current solution. The first thing they they find out is basically the SIL architecture. And that's, I would say, the the number 1 transformation phase we have seen.
[00:25:44] Unknown:
And you've you've mentioned a couple of times some of the services that you provide as a company around sale of the database. So I'm wondering what prompted the decision to form a company around the database once it was created, and also some of the challenges that you faced as a company that is trying to make money off of an open source database, particularly in light of recent failures such as RethinkDB?
[00:26:06] Unknown:
So I think we all read the RethinkDB blog, an excellent blog, by the way, in my opinion. I present so it it is it is a challenging environment. Don't get me wrong. And the the value that we're bringing in is basically our knowledge of both the database itself, how how it is operating, as well as the additional capabilities. We do have an enterprise version that we have additional enterprise features that people are looking for. For example, security, and you can think of any other type of, enterprise grade capabilities you need. So that's an enterprise version.
And in terms of information, that we provide to the users, we do have our own professional services to help users that need those capabilities to, you know, speed up their ramp up or don't have the technical depth to to maintain a cluster like that, we definitely come in and help them. Those are the services that we provide for a fee, and we see more and more customers looking for those services. So both the support, the enterprise features, as well as the, services on top of them is something that people are use using us for. We do also provide training. So if you are a novice or even if if you are, you know, a proficient user of CELA, we are more than happy to come in and provide you with training whether it's gonna be just, if you just need a jump start. So it's typically a single day, or you need a deep dive, to seal up to the architecture and the way it's it's it's operate.
That's a 3 day class that we provide. So this is how we make money. In terms of competition, as as always, I think as any other open source, we typically compete with ourselves. The open source competes with the enterprise. And but that's, I think, the nature of this business. If we're gonna be successful, I believe that we do. I think we have a winning product. I do think we have an advantage of the current, implementations that that are out there in the market. I do hope that customers are are able to see those value values and willing to pay for them. And, that's that's the idea at the end of the day.
[00:28:23] Unknown:
So going back to the c star framework, you were saying that, Sylloa was essentially initially created as a proof of concept for the c star framework. So I'm wondering if there's any intent to maybe build out different types of database systems with c c star or other kinds of applications? And, also, what are some other uses of c star from other projects that you're aware of that, you found particularly interesting?
[00:28:49] Unknown:
Sure. Sure. So there is 1, Systar is, again, is an open source. So we have seen, somebody took, Sysstar and created a a Redis database on top of it. So it's called pedis, p e d I s. So we encourage those. By all means, we think it's a it's a it's a value that, Sysco can bring to the market. I can tell you that right now, our hands are full both with customers and features that we want to bring into CELA. But if you look on the presentation by Abhikiviti, CELA's CTO, You'll see that we have multiple ideas in the analytics space and in the search space, in terms of storage efficiencies, and many more goodies that we want to bring into the market. So I I think that we really have a a handful tasks to make, and I don't think there is enough time in the in the day to complete them all.
So we do look outside our box and understand exactly what the applications are going and what are the use cases, and those are the items that we're looking for. I'll give an example. We see a lot of people using CELA, for example, for their IoT project or sensor data.
[00:30:03] Unknown:
It's something that we definitely want to look into. Yeah. And that brings up another interesting point is when you are working on providing compatibility with an existing existing system so that you can be a drop in replacement. Wondering what you see as the areas of innovation given that you that most of it can't be done externally in terms of the interfaces that you provide to other people using the system. So it means that a lot of the innovation needs to happen internally or under the covers. So I'm wondering what your experiences are with that. I I will not disclose probably most of the information, on this podcast as a public 1,
[00:30:40] Unknown:
but definitely, it's something that we take the feedback in. We try to find the solutions and, as you said, to bring the innovation to the customer under the umbrella, of, CQL and and the actual a p APIs that we have today. However, we are not we're not gonna be shy if there is a need to provide some type of, a specific capability to a specific use case. We think it's something that, we will be able to provide customers in addition to the implementation that they are familiar with and the drop replacement capabilities.
[00:31:14] Unknown:
Are there any other subjects you think we should cover before we start to close out the show? Use Cielo. You know, it's, I do think that Cielo can provide value to customers who are
[00:31:25] Unknown:
either struggling with their current Cassandra implementation or they want to use it as a on a greenfield type of implementation. I think we are we able to be very efficient, very easy to deploy. It's something that, you know, sometimes people don't discount, the time to to working. So if you are you know, you you don't want to make you want to make sure that database installation is not your business, but something else is your business, for example, whether it's a customer's retention program, IoT, time series, implementing sila is very simple. It's a it's a it's a simple 1 script that makes all the tuning for you and bring you a working, database in into your front door. That's that's the idea here.
[00:32:15] Unknown:
And that, reminds me 1 thing that we didn't cover yet is given that it is a more low level language implementation, I imagine that that somewhat restricts the platforms that it can run on. So the JVM, you could potentially run it on Windows or OSX and Linux. But I'm wonder I'm assuming that the platform, the the deployment targets for Silla are a little bit more constrained. Is that correct? Well,
[00:32:40] Unknown:
yes and no. I have not yet notes haven't seen any implementation of Cassandra or Cilla, on other systems in Linux. And I think that most implementations of the NoSQL space are on on a Linux based machine. Yes. There are implementations that use both OS X and and, Windows, but I think there is a a vast market that is using the, Linux space. We are supporting both, you know, Reddit, CentOS, Ubuntu, Debian, platforms. So I think it covers, most of the market that I don't think that should be the the preventing item from actually implementing,
[00:33:25] Unknown:
a silo. Yeah. I I can agree on that front. I I I don't think I would want to run it on Windows or OSX, but I suppose if somebody did want to, they could. I I I just, wouldn't be the 1 supporting it for them.
[00:33:37] Unknown:
Yeah. It's it's I'm not I'm not bashing those operating system. I am, I'm not I'm I am an an avid OSX user. I don't I don't get I don't I'm not shy of it, but I I don't think that's the right platform for such a database. As we said before, it's it's it's for a clustered, system. That that's where we're targeting Cilla.
[00:33:55] Unknown:
For anybody who wants to keep in touch with you and Cilla, I'll ask you for your preferred contact information, and I'll add that to the show notes in case anybody wants to get in touch and, dig a bit deeper into Silla.
[00:34:07] Unknown:
Sure. So couple of things. If you want to, join Silla or you want to work with Silla, I highly recommend we have our website, which is at, www.silla db.com. We have our public Slack channel. We have a public mailing list. Please jump on it. Use it. We are constantly listening, and we're constantly answering. And I can tell you, answering is darn fast, these days. So we have, people really jumping on to help customers, board Scylla.
[00:34:40] Unknown:
Well, I, appreciate your time this evening. It was a pleasure to get to learn a bit more about Scylla and how it came to be and some of the different ways that I can leverage it. And I'm sure a number of other people will be giving it another look. So thank you for your time, and I hope you enjoy the rest of your evening.
[00:34:56] Unknown:
Thank you very much, Luis. Appreciate it.
Introduction and Guest Welcome
Guest Background and Journey
Overview of Cilla DB
Origins and Initial Problems Addressed by Cilla DB
Reliability and Testing Approaches
Technical and Architectural Design Choices
API Compatibility and Challenges
Data Migration and Deployment Strategies
Cluster Management and Cost Efficiency
Company Formation and Business Model
Future Plans and Innovations
Closing Remarks and Contact Information
