 From San Mateo, it's theCUBE, covering Scalar Innovation Day. Brought to you by Scalar. Hello everyone, I'm John Furrier with theCUBE. We are here in San Mateo, California for a special Innovation Day with Scalar at their headquarters, their new headquarters here. I'm here with Shia Liu, who's the software engineer at the team, good to see you. Thanks for joining me. Hey, thank you, John. So tell us, what do you do here? What kind of programming, what kind of engineering? Sure, so I'm a backend software engineer at Scalar. What I work on from the day-to-day basis is building our highly scalable distributed systems and serving our customers fast queries. What's the future that you're building? Yeah, so one of the projects that I'm working on right now is it will help our infrastructure to move towards a more stateless infrastructure. So the project itself is a metadata storage component and a series of APIs that can tell our backend servers where to find a log file. That might sound really simple, but at the massive scale of ours, it is actually a significant challenge to do it fast and reliably. And getting data is a big challenge. Everyone knows that data is the new oil, data is the gold, whatever the people are saying, these data is super important. You guys have a unique architecture around data ingest. What's so unique about it, do you mind sharing? Of course. So we have a lot of things that we do or don't do uniquely. I would like to start with the ingestion front of things and what we don't do on that front. So we don't do keyword indexing, which most other existing solutions do. By not doing that, not keeping the index files up to date with every single log message that's incoming, we save a lot of time and resource. Actually, from the moment that our customer's applications generate a log line to that log line becoming available for search in Scalar UI, that takes just a couple of seconds. And on other existing solutions, that can take hours. So that's the ingest side. What about the query side? Because you've got ingest, now query. What's that all about? Yeah, of course. Actually, do you mind if we go to Blackboard a little bit? No, let's take a look. Let me grab a chalk real quick. So we have a lot of servers around here. We have Q servers. Let's see. These are Q servers and a lot of back end servers. Just to iterate on the ingestion side a little bit, when logs come in, they will hit one of these Q servers, any one of them. And the Q server will kind of batch the log messages together and then pick one of the back end servers at random and send the batch of logs to them. Any Q can reach any back end servers. And that's how we're able to handle gigs of logs, how much ever log that you give us. We ingest dozens of terabytes of data on a daily basis. And then it is this same farm of back end servers that's kind of helping us on the query front. Our goal is when a query comes in, we summon all of these back end servers at once. We get all of their computation powers, all of their CPU cores to serve this one query. And that is just a massively scalable multi-tenant model. And in my mind is really economies of scale at its best. So scale's huge here. So you got the decoupled back end Q system. But yet they're talking to each other. So what's the impact of the customer? What's some of the order of magnitude scale we're talking about here? Absolutely. So on the log side, we talked about seconds response time from logs being generated until they see the log show up. And on the query side, the median response time of our queries is under 100 millisecond. And we define that response time from the moment the customer hit the return button on their laptop till they see results show up. And more than 90% of our queries return results in under one second. So what's the deployment model for the customer? So I'm a customer, oh, this sounds great. Latency is a huge issue. One of low latency, because latency is really the lag issue for data. Do I buy it as a service? Am I deploying boxes? What does this look like here? Nope, absolutely at all. We are 100 plan cloud native. All of this is actually in our cloud infrastructure and you as a customer, you just start using us as a software as a service. And when you submit a query, all of our backend servers are at your service. And what's best about this model is that as scalars business grows, we will add more backend servers, add more computation power, and you as a customer still get all of that and you don't need to pay us any extra for the increased query speed. What's the customer use case for this? Give an example of who would benefit from this? Absolutely, so imagine you're an e-commerce platform and you're having this huge Black Friday sales. Seconds of time might mean millions of revenues to you and you don't want to waste any time on the logging front to debug into your system to look at your monitoring and see where the problem is if you ever have a problem. So we give you a query response time on the magnitude of seconds versus other existing solutions. Maybe you need to wait for minutes anxiously in front of your computer. Shea, what's the unique thing here? This looks like a really good arc. You decoupling things, it makes sense. But what's the secret sauce here? What's the big magic here? Yeah, absolutely. So anyone can kind of do a huge server farm brute force query approach, but the first 80% of a brute force algorithm is easy. It's really the last 20% that's kind of more difficult, challenging, and really differentiates us from the rest of other solutions. So to start with, we make every effort we can to identify and skip the work that we don't have to do. So maybe we can come back to our seats, yeah. Okay, so it's exciting. Yeah, so there are a couple of things we do here to skip the work that we don't have to do. As we always say, the fastest queries are those, we don't even have to run, which is very true. We have this columnar database that we built in-house, highly performant for our use case that can let us only scan the columns that the customer cares about and skip all the rest. And we also build a data structure called bloom filters. And if a query term does not occur in those bloom filters, we can just skip the whole dataset that it represents. So that speed helps on the speed performance. Absolutely, if we don't even have to look at that dataset. You know, I love talking to software engineers, people who are on the cutting edge, because you guys are a startup. Attracting talent is a big thing, and people love to work on hard problems. What's the hard problem that you guys are solving here? Yeah, absolutely. So we have this huge server farm at our disposal. It's, however, as we always say, the key to brute force algorithms is really to recruit as much force as possible as fast as we can. If you have hundreds, thousands of cores lying around, but you don't have an effective way to summon them around when you need them, then there's no help having them around. One of the most interesting things that my team does is we developed this customized scatter gather algorithm in order to assign the work in a way that faster backend servers will dynamically compensate for slower servers without any prior knowledge, and I just love that. How fast is it gonna get? Well, I have no doubt that we'll one day reach light speed. All right, physics is a good thing, but it's also a bottleneck. Tell us about your story. How did you get into this? Yeah, so I joined Scaler about eight months ago as an API server, actually. Sorry, as an API engineer, actually. So during my API days, I used Scaler to the product very heavily, and it just became increasingly fascinated about the speed at which our query runs, and I was like, I really want to get behind the scene and see what's going on in the backend that gives us such fast queries. So here I am. Two months ago, I switched the backend team. Well, congratulations, and thanks for sharing that insight. Thank you, John, thanks. I'm John Furrier here with Cube Insights Day, an innovation day here in San Mateo. Thanks for watching.