FWIW, in my company (AOL) we discovered a small elegant all client side transaction library on top of HBase, originally written by a Korea based team, called Haeinsa. It doesn't look active anymore so we had to fork it and have done a couple of minor enhancements and one bugfix, but has been working perfect for us. See the original repo at:
https://github.com/VCNC/haeinsa since never got any responses to issues we reported, we had to maintain our own fork, see AOL's fork at: https://github.com/aol/haeinsa It has listed on the front github page a great slideshare presentation that explains nicely how the whole thing works, through just adding an extra column family per table for the lock column. All that said, keep in mind that any such library of course has a performance hit. We like this library because: 1) we can use it with no extra HBase server side changes (other than extra column family) or other kind of server to install 2) we can be selective about which columns or column families to use transactionally and which to use "raw" for performance reasons Would be great if we could submit our contributions back to the original project but like I said we never heard back from them. Feel free to write back to let us know what you think. ---- Saad On Mon, Nov 28, 2016 at 6:01 PM, John Leach <jle...@splicemachine.com> wrote: > Mich, > > Splice Machine (Open Source) can do this on top of Hbase and we have an > example running a TPC-C benchmark. Might be worth a look. > > Regards, > John > > > On Nov 28, 2016, at 4:36 PM, Ted Yu <ted...@yahoo.com.INVALID> wrote: > > > > Not sure if Transactions (beta) | Apache Phoenix is up to date. > > Why not ask on Phoenix mailing list where you would get better answer(s) > ? > > Cheers > > > > | > > | | > > Transactions (beta) | Apache Phoenix > > | | > > > > | > > > > > > > > > > On Monday, November 28, 2016 2:02 PM, Mich Talebzadeh < > mich.talebza...@gmail.com> wrote: > > > > > > Thanks Ted. > > > > How does Phoenix provide transaction support? > > > > I have read some docs but sounds like problematic. I need to be sure > there > > is full commit and rollback if things go wrong! > > > > Also it appears that Phoenix transactional support is in beta phase. > > > > Cheers > > > > > > > > Dr Mich Talebzadeh > > > > > > > > LinkedIn * https://www.linkedin.com/profile/view?id= > AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw > > <https://www.linkedin.com/profile/view?id=AAEAAAAWh2gBxianrbJd6zP6AcPCCd > OABUrV8Pw>* > > > > > > > > http://talebzadehmich.wordpress.com > > > > > > *Disclaimer:* Use it at your own risk. Any and all responsibility for any > > loss, damage or destruction of data or any other property which may arise > > from relying on this email's technical content is explicitly disclaimed. > > The author will in no case be liable for any monetary damages arising > from > > such loss, damage or destruction. > > > > > > > > On 23 November 2016 at 18:15, Ted Yu <yuzhih...@gmail.com> wrote: > > > >> Mich: > >> Even though related rows are on the same region server, there is no > >> intrinsic transaction support. > >> > >> For #1 under design considerations, multi column family is one > >> possibility. You should consider how the queries from RDBMS access the > >> related data. > >> > >> You can also evaluate Phoenix / Trafodion which provides transaction > >> support. > >> > >> Cheers > >> > >>> On Nov 23, 2016, at 9:19 AM, Mich Talebzadeh < > mich.talebza...@gmail.com> > >> wrote: > >>> > >>> Thanks all. > >>> > >>> As I understand Hbase does not support ACIC compliant transactions over > >>> multiple rows or across tables? > >>> > >>> So this is not supported > >>> > >>> > >>> 1. Hbase can support multi-rows transactions if the rows are on the > >> same > >>> table and in the same RegionServer? > >>> 2. Hbase does not support multi-rows transactions if the rows are in > >>> different tables but happen to be in the same RegionServer? > >>> 3. If I migrated RDBMS transactional tables to the same Hbase table > >> (big > >>> if) with different column familities will that work? > >>> > >>> > >>> Design considerations > >>> > >>> > >>> 1. If I have 4 big tables in RDBMS, some having in excess of 200 > >> columns > >>> (I know this is a joke), can they all go one-to-one to Hbase tables. > >> Can > >>> some of these RDBMS tables put into one Hbase schema with different > >> column > >>> families. > >>> 2. then another question. If I use hive tables on these hbase tables > >>> with large number of family columns, will it work ok? > >>> > >>> thanks > >>> > >>> 1. > >>> > >>> > >>> Dr Mich Talebzadeh > >>> > >>> > >>> > >>> LinkedIn * https://www.linkedin.com/profile/view?id= > >> AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw > >>> <https://www.linkedin.com/profile/view?id= > AAEAAAAWh2gBxianrbJd6zP6AcPCCd > >> OABUrV8Pw>* > >>> > >>> > >>> > >>> http://talebzadehmich.wordpress.com > >>> > >>> > >>> *Disclaimer:* Use it at your own risk. Any and all responsibility for > any > >>> loss, damage or destruction of data or any other property which may > arise > >>> from relying on this email's technical content is explicitly > disclaimed. > >>> The author will in no case be liable for any monetary damages arising > >> from > >>> such loss, damage or destruction. > >>> > >>> > >>> > >>>> On 23 November 2016 at 16:43, Denise Rogers <datag...@aol.com> wrote: > >>>> > >>>> I would recommend MariaDB. HBase is not ACID compliant. MariaDB is. > >>>> > >>>> Regards, > >>>> Denise > >>>> > >>>> > >>>> Sent from mi iPad > >>>> > >>>>>> On Nov 23, 2016, at 11:27 AM, Mich Talebzadeh < > >> mich.talebza...@gmail.com> > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I need to explore if anyone has used Hbase as a transactional table > to > >> do > >>>>> the processing that historically one has done with RDBMSs. > >>>>> > >>>>> A simple question dealing with a transaction as a unit of work (all > or > >>>>> nothing). In that case if any part of statement in batch transaction > >>>> fails, > >>>>> that transaction will be rolled back in its entirety. > >>>>> > >>>>> Now how does Hbase can handle this? Specifically at the theoretical > >> level > >>>>> if a standard transactional processing was migrated from RDBMS to > Hbase > >>>>> tables, will that work. > >>>>> > >>>>> Has anyone built successful transaction processing in Hbase? > >>>>> > >>>>> Thanks > >>>>> > >>>>> > >>>>> Dr Mich Talebzadeh > >>>>> > >>>>> > >>>>> > >>>>> LinkedIn * https://www.linkedin.com/profile/view?id= > >>>> AAEAAAAWh2gBxianrbJd6zP6AcPCCdOABUrV8Pw > >>>>> <https://www.linkedin.com/profile/view?id= > >> AAEAAAAWh2gBxianrbJd6zP6AcPCCd > >>>> OABUrV8Pw>* > >>>>> > >>>>> > >>>>> > >>>>> http://talebzadehmich.wordpress.com > >>>>> > >>>>> > >>>>> *Disclaimer:* Use it at your own risk. Any and all responsibility for > >> any > >>>>> loss, damage or destruction of data or any other property which may > >> arise > >>>>> from relying on this email's technical content is explicitly > >> disclaimed. > >>>>> The author will in no case be liable for any monetary damages arising > >>>> from > >>>>> such loss, damage or destruction. > >>>> > >>>> > >> > > > > > >
