Shame really. Tephra has some advantages over Omid. Omid has a per row/cell cost (maintaining shadows cells), whereas Tephra has a per transaction cost (maintaining rollback/abort set and send it to future transactions). If was good to have both. For many small transactions Omid is better, with few large transactions Tephra is (much) better.
But I agree... If nobody comes forward to maintain Tephra, we should drop support, the project should go the attic. Phoenix' strength is that it is low latency key value store, *and* is integrated into the BigData ecosystem via Trino, Spark, and traditional M/R, *and* supports transactions. To my knowledge there is nothing else out there that bridges the low latency and high volume world as well and as broadly as Phoenix does. There seem to be some limited use cases with Omid, but it continues to surprise me that there is not more uptake of transactions. -- Lars On 2022/01/13 14:35:53 Istvan Toth wrote: > Had an offline chat with Josh on the topic. > > I'm going to write an [ANNOUNCE]ment on dropping Tephra to the dev and user > lists, > describing the situation, and inviting any interested parties to take over > maintenance. > > After that, I'm > * going to backport PHOENIX-6064 to 4.x/4.16, > * then remove the profile and make it the default and only option on 4.x > and master. > > Fully ripping out Tephra code from all the tests is a bigger task, and is > going to take more time, > but we have time to finish that before the next minor releases are cut. > (volunteers are welcome) > > regards > Istvan > > On Mon, Jan 10, 2022 at 7:55 AM Istvan Toth <[email protected]> wrote: > > > Hi! > > > > Based on your replies, we do want to drop Tephra and Tephra support from > > Phoenix, as no-one has volunteered to > > fix the existing issues with it. > > > > The next question is: How do we go about it ? > > > > Code-wise, I think the following would work: > > > > > > 1. Decide if we want to remove Tephra from the 5.1 and 4.16 branches > > or leave the code in as unsupported. (perhaps port the exclude-profile to > > 4.x/4.16 from 5.x/5.16) > > 2. Remove the exclude-tephra profile and make its behaviour the > > default. This takes care of the problematic dependencies. > > 3. Remove references to the Tephra code from Phoenix. This is just a > > few files for the Phoenix runtime, but touches a LOT of tests. > > The test clean-up can be done in several steps, and is not > > super-urgent, we just don't want to carry around dead code. > > 4. Remove All Tephra dependencies from the Phoenix project POMs. > > > > > > Organizationally, it's much less clear to me: > > > > - Do we want a formal [VOTE] process, or is this [DISCUSS] thread > > enough ? > > - Do we notify the ASF project governance about this, or is this an > > internal Project issue ? > > - Public communication: [ANNOUNCE] the retirement on the dev and user > > lists ? > > - What happens to repo ? Move it to the Attic, or just leave it as is ? > > - What happens to the Tephra web site ? > > > > > > regards > > Istvan > > > > > > On Fri, Jan 7, 2022 at 6:56 AM Istvan Toth <[email protected]> wrote: > > > >> Please keep this thread focused on Tephra. > >> Lars gives an overview of the difference in the comments of > >> https://issues.apache.org/jira/browse/PHOENIX-6615 . > >> If you want to discuss Omid further, open a new thread for that. > >> > >> On Fri, Jan 7, 2022 at 3:49 AM luoc <[email protected]> wrote: > >> > >>> Hi there, please forgive my silliness, could you share the difference > >>> between Omid and Tephra? > >>> > >>> > >>> Just last year, I tried to use the OMID to across the Phoenix cluster, > >>> and found that the TSO component of Omid does not support the HA. > >>> > >>> > >>> > >>> > >>> ------------------ Original ------------------ > >>> From: "Istvan Toth";<[email protected]>; > >>> Send time: Wednesday, Jan 5, 2022 3:22 PM > >>> To: "dev"<[email protected]>; > >>> > >>> Subject: Re: [DISCUSS] The future of Tephra > >>> > >>> > >>> > >>> I was about 80% percent done with the rebase to the latest Twill version > >>> when its retirement was announced :) > >>> Took me about a week. > >>> > >>> On Tue, Jan 4, 2022 at 6:34 PM Andrew Purtell <[email protected] > >>> > > >>> wrote: > >>> > >>> > As someone who investigated an internal mitigation for pulling up > >>> Tephra > >>> > to a newer Guava version, and decided it was too much work after > >>> hitting > >>> > some Twill issues in the process, I feel your pain directly and > >>> > enthusiastically +1 removal. > >>> > > >>> > > On Jan 4, 2022, at 7:46 AM, Josh Elser <[email protected]> > >>> wrote: > >>> > > > >>> > > Agreed. As the person who did the work of pulling Tephra in > >>> from the > >>> > incubator, I think we were already then in the state of "does > >>> someone > >>> > actually care about Tephra?". > >>> > > > >>> > > Without digging into the archives, I think someone was > >>> interested, but > >>> > it seems like this never manifested. > >>> > > > >>> > > +1 to remove Tephra integration from Phoenix. > >>> > > > >>> > >> On 1/3/22 1:38 PM, Viraj Jasani wrote: > >>> > >> +1 (unless any volunteer comes forward to support Tephra > >>> going forward) > >>> > >>> On Mon, 3 Jan 2022 at 4:34 PM, Istvan Toth < > >>> [email protected]> wrote: > >>> > >>> Hi! > >>> > >>> > >>> > >>> As recently noticed by Lars, Tephra hasn't been > >>> working in Phoenix > >>> > since > >>> > >>> 5.1/4.16 due to a bug. > >>> > >>> > >>> > >>> The fact that this went unnoticed for a year, and the > >>> fact that > >>> > generally > >>> > >>> there seems to be minimal interest in Tephra suggests > >>> that we should > >>> > >>> re-visit the decision to maintain Tephra within the > >>> Phoenix project. > >>> > >>> > >>> > >>> The last two commits that were not aimed at fighting > >>> bit-rot, but were > >>> > real > >>> > >>> fixes were committed in Jun 2019 by Lars. In the last > >>> two and a half > >>> > years, > >>> > >>> all we did was try to keep ahead of bit-rot, so that > >>> Tephra keeps up > >>> > with > >>> > >>> new HBase and maven releases, and the changes in the > >>> CI infra. > >>> > >>> > >>> > >>> Tephra uses an old Guava version, and depends heavily > >>> on the retired > >>> > Apache > >>> > >>> Twill project. > >>> > >>> This is a major tech debt, and an adoption blocker > >>> (CVEs in direct > >>> > Tephra > >>> > >>> dependencies), which is also carried over into the > >>> Phoenix > >>> > dependencies and > >>> > >>> shaded artifacts that we should rectify. > >>> > >>> PHOENIX-6064 < > >>> https://issues.apache.org/jira/browse/PHOENIX-6064> , > >>> > which > >>> > >>> broke Tephra support, itself is a workaround so that > >>> we can avoid > >>> > shipping > >>> > >>> Tephra, and its problematic dependencies. > >>> > >>> > >>> > >>> Ripping out Twill, and updating Guava and other > >>> dependencies is a > >>> > >>> non-trivial amount of work (I estimate 1-4 weeks, > >>> depending on > >>> > familiarity > >>> > >>> with Tephra/Twill/Guava). > >>> > >>> > >>> > >>> At the moment, no-one seems to be interested enough in > >>> Tephra to bring > >>> > its > >>> > >>> tech debt to acceptable levels, and in fact no-one > >>> seems to be using it > >>> > >>> with any recent Phoenix release (as it doesn't work in > >>> them). > >>> > >>> > >>> > >>> I suggest that you also check out the discussion > >>> between Lars and me in > >>> > >>> https://issues.apache.org/jira/browse/PHOENIX-6615 > >>> for some more > >>> > details > >>> > >>> and background. > >>> > >>> > >>> > >>> Based on the above, I propose retiring Tephra, and > >>> removing Tephra > >>> > support > >>> > >>> from Phoenix 5.2 / 4.17, unless someone steps up to > >>> solve the above > >>> > issues > >>> > >>> and maintain Tephra. > >>> > >>> > >>> > >>> Note that this would not mean dropping transaction > >>> support from > >>> > Phoenix, as > >>> > >>> Omid support is in much better shape, and is actively > >>> used. > >>> > >>> > >>> > >>> Please share your thoughts on the issue, if you are > >>> using Tephra > >>> > and/or can > >>> > >>> commit to solving the issues above, or if you agree on > >>> its removal, or > >>> > any > >>> > >>> other suggestions or objections. > >>> > >>> > >>> > >>> regards > >>> > >>> Istvan > >>> > >>> > >>> > > >>> > >>> > >>> -- > >>> *István Tóth* | Staff Software Engineer > >>> [email protected] <https://www.cloudera.com> > >>> [image: Cloudera] <https://www.cloudera.com/> > >>> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > >>> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > >>> Cloudera > >>> on LinkedIn] <https://www.linkedin.com/company/cloudera> > >>> <https://www.cloudera.com/> > >>> ------------------------------ > >> > >> >
