SkyElectric provides a smart solar energy system that delivers clean, reliable energy in the developing world. Using lithium-ion batteries controlled by patented electronics and artificial intelligence, SkyElectric’s algorithms make intelligent decisions that maximize energy availability and minimize cost. The result is 24×7 sustainable, affordable energy availability for all.
Unlike many other companies in their space, SkyElectric engineers develop all of their products in-house, while customer systems are monitored 24×7 by those products. SkyElectric’s customer base is growing rapidly, and the company plans to expand internationally soon.
In 2017, SkyElectric was running legacy software, written in Java, against MySQL. As is common with IoT use cases, SkyElectric’s data size was growing rapidly. MySQL was unable to keep up; queries routinely took up to five minutes to return results.
Evaluating alternatives, the team focused on solutions appropriate to time series data, with a goal of organizing their machine data in an efficient way. The team initially looked at Apache Cassandra and Riak TS. After some testing, the team realized that Riak would be too restrictive; once the schema went live, they would be unable to make any changes. That proved to be a disqualifier.
While researching Cassandra, a software architect recommended Scylla to SkyElectric’s DevOps Lead, Meraj Rasool. Familiar with Java’s operational challenges, Rasool was intrigued to learn that Scylla is implemented in C++.
“I was very reluctant to go into production with Cassandra. So many articles and research papers emphasize Cassandra’s massive performance issues. We dreaded continuously tweaking and tuning the cluster to make sure it operates at the proper maximum resources. I was glad to find a superior alternative,” said Rasool.
“After running a production cluster of Scylla for a year, I just cannot stress this enough; I sleep very well without worrying that something might go wrong.”
-Meraj Rasool, DevOps Lead, SkyElectric
SkyElectric compared benchmarks on ScyllaDB’s website with their own Cassandra test runs.
“I was very impressed with Scylla’s speed and ease of deployment,” said Rasool. “Unlike Cassandra, Scylla didn’t need any tuning and was up and running very quickly and painlessly.”
Rasool identified operational ease as the key benefit of Scylla. While SkyElectric saw 10x better performance with Scylla, operational ease was still more important, and ultimately proved to be the key factor behind the team’s decision.
“After running a production cluster of Scylla for a whole year, I just cannot stress this enough; I sleep very well without worrying that something might go wrong,” exclaimed Rasool. “We do scheduled backups, but we don’t need to worry about performance at all.”
Starting out with three small AWS nodes, the team followed the documentation and launched bigger i3.large instances. SkyElectric runs three nodes but plan to double or triple those clusters this year.
For support, the SkyElectric team relies on ScyllaDB’s Slack channel. “I’m very happy with ScyllaDB’s support,” said Rasool. “There were a few times when I really needed help and got a response within a few hours. But they weren’t just boilerplate responses. They were actual solutions for my questions. I was able to directly apply the solutions to our running clusters.”
“Once we adopted Scylla, we were freed up to think about other things,” said Rasool. “For example, now we’re building a search engine and a stats engine. We are very confident that Scylla will help us, that Scylla will be there, and that it will survive the load. The overall performance of the system backed by Scylla, the speed, previously measured in minutes, is now measured in milliseconds.”
Rasool summed up his experience with Scylla. “Having worked in DevOps for the last three years, combined with IoT, I’ve found that you need extremely reliable technology. The only way to sleep well and basically live a good life is to select the best of the best. In that way, Scylla has helped a lot.”
|3-node Scylla Cluster||Previous MySQL Cluster|
|Storage||3x storage with no performance degradation|
|Average Write Latency||1.4 ms||~2 seconds|
|Average Read Latency||<1 ms||<1 second (often 2+ minutes)|
|Request Volume||5x MySQL throughput|