[Hawkular-dev] Cassandra upgrade

[Thomas Segismont]

Just a note about our embedded C* use case.

Emmanuel (added him in CC) is working on a Wildfly10 upgrade of the 
wildfly-cassandra project.

https://github.com/ehsavoie/wildfly-cassandra/tree/wf-10

I we move to C*3, it may be worth considering using this instead of the 
Embedded C* EAR.


Le 13/01/2016 17:10, John Sanda a écrit :
>
>> On Jan 13, 2016, at 10:20 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>
>> On 11 Jan 2016, at 18:45, John Sanda wrote:
>>
>>> 3.x. From a development standpoint, I think it absolutely makes sense
>>> to upgrade. I would like to know what others think (Heiko in
>>> particular). There are other
>>
>> Can you list some of those? Do we expect improved
>> performance or reduced resource consumption?
>
> Some of the major changes include
>
> * materialized views
>      * Secondary indexes are typically discouraged in favor of manual, custom indexes. Materialized views can replace these.
> * aggregate functions
> * improvements to incremental repair
> * storage engine rewrite
>      * original engine written for Thrift and before CQL was implemented. New engined based around CQL.
>      * reduced memory usage on reads
>      * reduced storage on disk
>          * clustering columns no longer stored per cell
>          * column names are no longer repeated
>          * fixed-width cells are written without size
>
>>
>> I believe though that upgrading now is better than
>> later in the game. And if only with respect to not
>> needing any sstableupgrade runs.
>
> Running sstableupgrade or similar maintenance is something that we won’t be able to avoid whether it is not or at some later point in the future.
>
>>
>> It has the drawback of productization though as you write:
>>
>>> considerations like productization build changes and OpenShift
>>> integration. There would be a data migration involved with OpenShift
>>> since we already shipped Cassandra 2.x. When upgrading across major
>>> versions, you are supposed to run the sstableupgrade utility on each
>>> table. We would need to do this for OpenShift. Whether or not we
>>> choose to upgrade now, we will need to deal with this migration step
>>> in OpenShift at some point.
>>
>> Yes. What runtimes are expected here? If they are typically in
>> some minute ranges, then they could be more or less be done
>> during a normal openshift version upgrade I guess.
>
> We will need to do some testing, but I believe that this can be done as a rolling upgrade.
>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>