...
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
...
Scope
todo
Goals
- easy Easy way to enforce system-wide soft and hard limits to prevent anti-patterns of bad usage and in the long run make it not possible to severely degrade the performance of a node/cluster through user actions (too many MVs/secondary indexes per table, ...), thus increasing stability/availability.
- as As a C* developer it should be easy to add new Guardrails.
- Guardrails are disabled by default and there should be no overhead when Guardrails are disabled.
Non-Goals
- enforcing limits on a per-user-basis
- setting limits dynamically while nodes are running
...
Guardrail Classes and Configuration
- Guardrail: general class definition of a Guardrail Interface defining a guardrail that guards against a particuluar particular usage/condition.
- DefaultGuardrail: Abstract class implementing Guardrail. It implements the default behaviour when the guardrail is triggered consisting on throwing warnings or errors.
- GuardrailsFactory: Interface defining a factory for building instances of Guardrail.
- DefaultGuardrailsFactory: Class implementing GuardrailsFactory, it builds instances of DefaultGuardrail.
- CustomGuardrailsFactory: Abstract class instantiating a custom GuardrailsFactory, so users can provide their own implementations of guardrails through a system property named
cassandra.custom_guardrails_factory_class
.Guardrails: Entry point for Guardrails, storing all defined Guardrails and additional helper methods - GuardrailsConfig: Configuration settings for Guardrails, which are populated from
cassandra.yaml
. This contains a main settingenabled
, controlling if Guardrails are globally active or not, and individual settings to control each Guardrail. - cassandra.yaml: allows configuring individual Guardrails, disabled by default.
- Guardrails: Entry point for guardrails, storing all the defined guardrail instances and additional helper methods. These Guardrail instances are built at startup with the provided GuardrailsFactory and GuardrailsConfig.
Overview of proposed Guardrails
...
- unit and integration tests for every single guardail will be added (handling erroneous input, proper notification of warnings/failures, guardrail boundary settings, no warnings/failures when disabled, ...)
Performance Characteristics and Testing
- there should be no overhead when Guardrails are disabled and this should be tested in existing read/write benchmarks
- a certain amount of performance degradation is acceptable (to which degree has to be defined). This featureset prioritizes stability and predictability of performance over achieving the highest possible throughput or latency on a cluster, and as such we need to figure out acceptable performance tradeoffs for having these enabled.