In this blog post, we’ll start by describing Kubernetes, a system for automating application deployment and monitoring, discuss how some Kubernetes concepts map to those of Scylla, and provide a complete example (hosted on GitHub) of Scylla on Kubernetes that should serve as a good starting point for your own deployment strategy.
Seastar provides a programming environment that abstracts away most of the problems of multi-threaded programming using a thread-per-core model. Locks, atomic variables, memory barriers, lock-free programming, and all of the scaling and complexity that come from them are gone. In their place, Seastar provides a single facility for inter-core communications. This is, of course, great for the developer, who can easily utilize many-core machines, but there is also another side: because Seastar takes care of all inter-core communications, it can apply advanced optimizations to these communications.
This article examines these optimizations and some of the complexity involved.
Learn how to build the monitoring part of the system by creating the keyspace in Scylla. This post teaches you about different compaction strategies available in Scylla and how to run basic CQL queries.
What’s the deal with prepared statements? A query itself is just a string of text. For example: INSERT INTO tb (key,val) VALUES (“key”, “value”) In this simple example, we inserted two strings in a two-column table. Before that can happen, the CQL statement string (INSERT INTO…) needs to be sent to Scylla, parsed, and assuming no errors in the query, executed. It’s the parsing part that we are concerned with here. Parsing a CQL query is a compute-intensive operation that consumes resources just like anything else you would have a computer do. What if we could do the parsing part […]
What is a User Defined Type? (UDT)? User Defined Types (UDTs) allow a definition of struct that includes multiple typed named fields (including other UDTs). Once a UDT is defined, it can be used as a column type in a table definition. In Scylla, you can define a Column as a frozen<UDT>.
— 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.
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.
What happens if a catastrophe occurs in or between your data centers? What if a node goes down or becomes unreachable for any reason? Scylla’s fault tolerance features significantly mitigate the potential for catastrophe. To get the best fault tolerance out of Scylla, you must understand how to select the right fault tolerance strategy, which includes setting a Replication Factor (the number of nodes that contain a copy of the data) for your keyspaces and choosing the right Consistency Level (the number of nodes that must respond to read or write operations). We recently added new documentation to our Scylla […]
To help you get the best out of your Scylla deployment, we’re producing a series of new documentation and blog posts featuring different Scylla concepts and Scylla architecture.