As word about Scylla continues to spread, we’re seeing more and more downloads of our open source software. We’re not always privy to our users’ experiences, but we’re very glad when we have the opportunity to share their results. A recent example of this is from Alexys Jacob of Numberly, who shared his experience evaluating Scylla for production on his personal Blog. In the first installment of a 2-part series, he describes his preparation for a successful POC-based evaluation with the help of the ScyllaDB team.
This is the second post in a series of four about the different compaction strategies available in Scylla. In the previous post, we introduced the Size-Tiered compaction strategy (STCS) and discussed its most significant drawback – its disk-space waste, a.k.a. space amplification. In this post, we will look at Leveled Compaction Strategy (LCS), the first alternative compaction strategy designed to solve the space amplification problem of STCS, and show that it does solve that problem, but unfortunately introduces a new problem – write amplification. The next post in this series will introduce a new compaction strategy, Hybrid Compaction Strategy, which […]
This is the first post in a series of four about the different compaction strategies available in Scylla. The series will look at the good and the bad properties of each compaction strategy, and how to choose the best compaction strategy for your workload. This first post will focus on Scylla’s default compaction strategy, size-tiered compaction strategy.
In the context of graph databases, the performance of your storage backend is paramount. In the world of edges and vertices, graphs (and the data required to support them) can grow exponentially in a point-to-point fashion. In their talk at Scylla Summit 2017, Ted Chang and Chin Huang, both engineers at IBM, decided to add Scylla to the mix of backends which has traditionally included Cassandra and HBase. They ran test scenarios which covered high volume reads and writes, and provided comparative test results for the three backends, along with lessons learned for each.
For the past two years, we have helped users build fast, resilient, and stable applications with Scylla, an enterprise-grade database solution. During these two years, our early adopters migrated from a variety of database solutions, and while most of the migrations we successfully completed were Apache Cassandra (enterprise and open-source versions), we have seen users migrate from MongoDB, HBase, relational systems such as MySQL and Postgres, and key/value stores like Memcache and Redis. Migration strategies differ between users and systems. In general, we can divide Apache Cassandra-to-Scylla migrations into two main strategies, cold migration and hot migration. Cold Migration […]
2017 was an exceptional year at ScyllaDB. We were successful in all the areas that really matter—our product, our staff and, most importantly, our user community. And while there’s still much work to do, I’d like to take a moment to reflect on a few of our bigger accomplishments from the year.
They may not have time machines or lightsabers, but they do have the Higgs-Boson and they’re looking for the most scalable framework with which to study it. At CERN, the problem of the day is scaling out their AliEn global file catalog and their plans may well involve Scylla.
How do you quantify how effective your database system is in terms of throughput, latency and CPU usage? And what do you do when there is a risk to your SLA? These were the main questions explored in Lukasz Pachiarek and Szymon Szymanski of Allegro’s talk at Scylla Summit 2017.
At ScyllaDB, our development team is all about performance with improved latency and throughput. Our speakers at our recent Scylla Summit provided many tips and tricks to make Scylla’s superior latency and performance even better. ScyllaDB’s VP of R&D, Schlomi Livne, added to the growing repertoire of these tips with his talk Planning your queries for maximum performance. In it, he outlined some of the how and why of Scylla performance, and concluded with seven rules to optimize your queries.
Apache Cassandra may have served you well. But alas, nothing is ever perfect, so you’re looking to migrate. Typically sub-millisecond consistency, performance of various operations, compaction, as well as read/write latency (especially under heavy loads) can be less than optimal.
Apache®, Apache Cassandra®, are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. No endorsement by The Apache Software Foundation is implied by the use of these marks.