Hi Ricardo, Yes no harm in executing upgradesstables multiple times.
Regarding the aggregate functions, you mentioned the data is pre-aggregated in buckets. Does that mean the records which are to be used in aggregate function are part of a single partition. In my opinion, query performance is dependant on selection of exact partitions. So, as long as your aggregation function is operating over data in a single partition for each query, the performance should be scalable. Otherwise, the queries could end up scanning tables. In that case, if number of records scanned are limited it should work with some performance degrade. However, the best way to know this is to load test it. An alternative to this is to perform the aggregate operations in the application querying mentioned data e.g. using spark. A good reason to use this approach is, if Cassandra queries are not optimal it could impact complete cluster performance. Hope this helps. Regards, Anup Shirolkar On Wed, 10 Oct 2018 at 20:11, Riccardo Ferrari <ferra...@gmail.com> wrote: > Thank you Anup, > > Yup, the upgradesstables is a step I generally take before (to make sure > I'm on the latest version) and after to make sure I'm updating to the > latest sstable version supported by the version. I know it's redundant and > not necessary but I read it does not hurt. > > I am looking into those aggregations to solve a simple use case where data > cardinality should be limited in volume. That is find min, max, avg for > some events over a limited time span in past. We are working on > pre-processed data pre-aggregated into buckets. The cardinality should be > below 6K records in the wors case. Any comments? Are there any better > approach that not involve moving data into another sotrage/index? > > Thanks > > > On Wed, Oct 10, 2018 at 1:30 AM Anup Shirolkar < > anup.shirol...@instaclustr.com> wrote: > >> Hi, >> >> Yes it makes sense to move to 3.11.3 >> The release has features and bug fixes which should be useful to your >> cluster. >> >> However, if you are planning to use GROUP_BY, UDFs etc. >> Please be cautious about the performance implications it may cause if not >> done with suitable queries. >> >> I am not aware of any specific doc to perform the upgrade. >> But, the steps you are following for upgrades looks fine. >> >> I think the `upgradesstables` step is not in correct place in upgrade >> sequence. >> I think upgrade sequence should be: >> >> - snapshot >> - drain and stop >> - backup configs >> - install new release >> - review config updates (patch existing config) >> - start Cassandra >> - *upgradesstables* >> >> *Not to forget*: Perform upgrade on one node at a time. >> >> Regards, >> >> Anup Shirolkar >> >> Instaclustr <https://www.instaclustr.com/> >> >> >> On Wed, 10 Oct 2018 at 00:30, Riccardo Ferrari <ferra...@gmail.com> >> wrote: >> >>> Hi list, >>> >>> We recently upgraded our small cluster to the latest 3.0.17. Everything >>> was nice and smooth, however I am wondering if ti make sense to keep moving >>> forward and upgarde to the latest 3.11.3? >>> >>> We really need something like the GROUP_BY and UFF/UDA seems limited wrt >>> our use-case. >>> >>> Does it make sense? >>> Any argument against? >>> Is there any doc to prepare such upgrade? >>> My current workflow was very easy: >>> - snapshot >>> - upgradesstables >>> - drain and stop >>> - backup configs >>> - install new release >>> - review config updates (patch existing config) >>> - start >>> >>> Thanks >>> >>
