Database Reference
In-Depth Information
Staged Event-Driven Architecture
Cassandra was built with staged event-driven architecture (SEDA) as one of the
core concurrency models. What this means is that instead of doing all work for a
particular operation within a single thread, work begins in one thread and is then
handed off to one or many other threads for the operation to complete. In other
words, work is divided up into stages, and then thread pools are created for each
stage. This enables Cassandra to manage its own resources internally and can then
be optimized for whichever performance characteristic is best for the situation (I/
O, CPU, memory, network, etc.).
As is typical of evented models, each stage is made up of an event handler, an
event queue, and an associated thread pool for handling those events. Cassandra
is extremely effective at using this model for concurrency as it can reallocate re-
sources as necessary to keep up with the load being thrown at it. The most com-
mon stages in this architecture are
Read
Mutation
Gossip
Response
Anti-entropy
Load balance
Migration
Streaming
While there are some more granular subdivisions within these stages, Cas-
sandra's workflow uses these at a high level. If any of these stages becomes over-
loaded with work, Cassandra can (and will) drop operations waiting in the event
queue of the stage to keep the node available. This architecture is one of the ways
that Cassandra keeps itself highly available.
Note
The original SEDA paper is available at www.eecs.harvard.edu/
~mdw/proj/seda .
Search WWH ::




Custom Search