Bug 1065652

Summary:	Enable compression of storage node data
Product:	[JBoss] JBoss Operations Network	Reporter:	John Sanda <jsanda>
Component:	Core Server, Performance, Storage Node	Assignee:	John Sanda <jsanda>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Mike Foley <mfoley>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	JON 3.2	CC:	hrupp, myarboro
Target Milestone:	DR01
Target Release:	JON 3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1015628	Environment:
Last Closed:	2014-12-11 14:04:26 UTC	Type:	Enhancement
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1015628
Bug Blocks:	1011084

Comment 1 John Sanda 2014-02-15 12:30:48 UTC

Based on recent discussions determining whether or not this can go into 3.2.1 (or any 3.2.x release) may come down whether or not the change can be done through our patch process. Currently the patch process does not allow for database schema changes. This is because schema changes are done through the installer and the installer might not be run as part of the patch process. This means that any Cassandra schema changes would need to be applied at server start up which is easy enough to do. Where things might get a bit complicated is with an HA deployments where multiple servers start up at the same time and apply schema updates concurrently. I do not think this will be a problem because Cassandra has support for concurrent schema modifications. For reference see the following,

* https://issues.apache.org/jira/browse/CASSANDRA-1391
* http://www.datastax.com/dev/blog/the-schema-management-renaissance
* https://issues.apache.org/jira/browse/CASSANDRA-3794

Comment 3 John Sanda 2014-02-17 15:56:27 UTC

I want to clarify a couple things in comment 1. First, this applies only to Cassandra schema changes and not to the relational database schema. Secondly, with small changes this could meet the criteria for patches. This would be a big improvement for customers. The footprint on disk could be reduced by as much as 60%. This could also have a big impact on performance of not just the Storage Node but also the platform on which it is running.

People expressed concern about the footprint on disk prior to 3.2.0 going out. In fact, it is those concerns that led to the in-depth sizing analysis performed by Stefan Negrea and me. I am requesting that this be triaged for 3.2.1 (or even 3.2.2).

Comment 6 John Sanda 2014-08-29 12:43:10 UTC

Moving to ON_QA since these changes were in ER1. Based on what I have seen in 3.2.x environments, I think that compression needs to be configurable so users have a way to easily turn it off if. I will open a separate BZ for that.