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.
Snapfish is an industry leader in photo retail with over 100 million members storing over 100PB of data. On a peak shopping day, Snapfish processes 100,000 reads and 7,000 writes per minute. Based on their workload, they need a database that accommodates their high volume but were increasingly finding that their database system was not meeting their performance and scaling needs. They began a search for alternatives and evaluated Scylla as a possible solution.
The Scylla team is pleased to announce the release of Scylla Enterprise 2017.1.2, a production-ready Scylla Enterprise minor release. Scylla Enterprise 2017.1.2 is a bug fix release for the 2017.1 branch, the latest stable branch of Scylla Enterprise. The 2017.1 branch is based on Scylla open source 1.6 and includes backports bug fixes from upstream releases (1.7, 2.0, 2.1) as well as enterprise-only bug fixes. Read more about Scylla Enterprise here. Related Links Get Scylla 2017.1.2 (customers only, or 30-day evaluation) Upgrade from 2017.1.x to 2017.1.2 Upgrade from Scylla 1.6 to Scylla 2017.1 Submit a ticket Scylla Enterprise customers are […]
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.
The Scylla team is pleased to announce the release of Scylla 2.0.1, a bugfix release of the Scylla 2.0 stable branch. Release 2.0.1, like all past and future 2.x.y releases, is backward compatible and supports rolling upgrades. If you are upgrading from 1.7.x, make sure to read the Scylla 2.0 release notes first. In particular, you can only upgrade to Scylla 2.0 from Scylla 1.7.4 or later, and support for older versions of drivers have been discontinued (driver support is detailed in the release notes).
— When data is written to Scylla, one or more replicas may become unresponsive or unreachable. The reasons for that may range from a heavy load on a particular replica node, network congestion, hardware issues, etc. As a result, the write to a replica will fail, usually with the timeout error. To restore the consistency of the data across all replicas, a user will have to run a repair, which is a very expensive—and usually long—procedure.
The Scylla Summit includes many technical sessions that aren’t about Scylla at all. Alex Gallego, a principal engineer in Akamai’s Platform Group, gave one such talk, SMF: The Fastest RPC in the West. First, a bit of background on Alex. He was the founder and CTO behind the Concord.io distributed stream processing engine. Much in the same way that Scylla addressed the Java-based performance issues in Cassandra, Concord.io chose to build in C++ to deliver a stream processor with better predictability, performance, isolation, multi-tenancy, supervision, and failure recovery. As Alex explains it, “During my time at Concord.io, we saw that […]
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.
In previous documentation installments, you’ve learned about Scylla’s ring architecture and you’ve dug into our fault tolerance documentation. Ready to get your hands dirty? Our consistency level console demo can help you get started immediately.
The data model in Scylla and Apache Cassandra partitions data between cluster nodes using a partition key, which is defined by the database schema. Using a partition key provides an efficient way to look up rows using the partition key because you can find the node that owns the row by hashing the partition key. Unfortunately, this also means that finding a row using a non-partition key requires a full table scan which is inefficient. Secondary Indexes are a mechanism in Apache Cassandra that allows efficient searches on non-partition keys by creating an index.
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.