But if I'm not doing anything fancy w/ C* (i.e. don't use new features in
3.{2,4,6}) then I'll be fine, right ?-eric ho On Thu, Oct 13, 2016 at 5:09 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > I listed my reasons, please check my previous email. > > On Thu, Oct 13, 2016 at 4:55 PM Eric Ho <e...@analyticsmd.com> wrote: > >> Why 3.0.x ? Why not use 3.2.x or 3.4.x ? or 3.6.x ? >> Shouldn't 3.6.x be more stable than say 3.2.x ? >> >> >> -eric ho >> >> >> On Thu, Oct 13, 2016 at 3:48 PM, Jonathan Haddad <j...@jonhaddad.com> >> wrote: >> >> Here's your basic options: >> >> 1. Triggers (avoid like the plague) >> 2. CDC (really new, tricky to avoid RF operations as is, probably avoid) >> 3. Do it in your app >> 4. Put Kafka in front of your data, write as many consumers as you want >> to write the data in as many ways as you want >> >> Also, how long have you been using Cassandra? Unless you're comfortable >> rolling your own builds and merging in bugfixes from upstream, I really >> suggest using a 3.0.x release instead of a 3.7. >> >> 3.7 falls under the Tick Tock release cycle, which is almost completely >> untested in production by experienced operators. In the cases where it >> has >> been tested, there have been numerous bugs found which I (and I think most >> people on this list) consider to be show stoppers. Additionally, the Tick >> Tock release cycle puts the operator in the uncomfortable position of >> having to decide between upgrading to a new version with new features >> (probably new bugs) or back porting bug fixes from future versions >> themselves. There will never be a 3.7.1 release which fixes bugs in 3.7 >> without adding new features. >> >> https://github.com/apache/cassandra/blob/trunk/NEWS.txt >> >> For new projects I recommend starting with the recently released 3.0.9. >> >> Assuming the project changes it's policy on releases (all signs point to >> yes), then by the time 4.0 rolls out a lot of the features which have been >> released in the 3.x series will have matured a bit, so it's very possible >> 4.0 will stabilize faster than the usual 6 months it takes for a major >> release. >> >> All that said, there's nothing wrong with doing compatibility & smoke >> tests >> against the latest 3.x release as well as 3.0 and reporting bugs back to >> the Apache Cassandra JIRA, I'm sure it would be greatly appreciated. >> >> https://issues.apache.org/jira/secure/Dashboard.jspa >> >> Jon >> >> >> >> On Thu, Oct 13, 2016 at 3:15 PM Eric Ho <e...@analyticsmd.com> wrote: >> >> Some suggested Elassandra. But that is based on Cassandra 2.2. >> I would like to use Cassandra 3.7 and up... >> >> >> >> -eric ho >> >> >> On Thu, Oct 13, 2016 at 3:04 PM, vincent gromakowski < >> vincent.gromakow...@gmail.com> wrote: >> >> Elassandra >> https://github.com/vroyer/elassandra >> >> Le 14 oct. 2016 12:02 AM, "Eric Ho" <e...@analyticsmd.com> a écrit : >> >> I don't want to change my code to write into C* and then to ES. >> So, I'm looking for some sort of a sync tool that will sync my C* table >> into ES and it should be smart enough to avoid duplicates or gaps. >> Is there such a tool / plugin ? >> I'm using stock apache Cassandra 3.7. >> I know that some premium Cassandra has ES builtin or integrated but I >> can't afford premium right now... >> Thanks. >> >> -eric ho >> >> >> >>
