4:43 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev