Hi William, Tephra is used in production for every CDAP customer[1], so it does have production usage. If your scenario is OLTP, then transactional tables in Phoenix is the way to go. I don't think having atomic increment and check and put add up to OLTP.
I also don't think transactions would put a larger performance overhead than check and put operations as both are doing a read before write. With transactions you'd typically do a SELECT before an UPSERT while check and put does a get before the put. Transactions have an extra RPC, but this is amortized through batching. I'd really encourage you to try this path. Thanks, James [1] http://cask.co/products/cdap/ On Wed, May 4, 2016 at 3:24 AM, William <[email protected]> wrote: > Hi James, > Thanks for your advice. I have thought of implementing it in standard > SQL, for example: > a) UPDATE tablename SET colA = colA + 10, colB = colB - 20 where pk = 1; > or > b) UPSERT INTO tableName (colA, colB) values (colA + 10, colB - 20) where > pk = 1; > > > At first, I chose a), because UpsertStatement is not a FilterableStatement > so doesn't have a WHERE clause. So introduce a new statement UPDATE is > easier. > But considering checkAndMutate, > UPDATE tablename SET colA= 20 where pk = 1 and colB = 20; > > > for Table#checkAndMutate(), we must provide a row key and a column as the > condition. So the WHERE clause must be point-look-up and has one other > column. > But we'll get a problem when doing this: > UPDATE tablename SET colA = colA + 10, colB = 5 where pk = 1 and colC = 30; > Unfortunately, hbase doesn't support checkAndIncrement() so we cannot use > increment and checkAndMutate in the same SQL. > It is difficult to explain to the user why we couldn't support this. > > > So i have to implement increment and checkAndMutate in separate statements. > It seems that the best solution is to implement all these things in a > coprocessor instead of calling Table#increment() or > Table#checkAndMutate().But it costs too much to do this. Do you have a > better idea, James? > > > For Tephra, it dose so many things to do a single transaction, and i > really don't think the impact to performance is small enough(though I > haven't tested yet). > My scenario is OLTP and i must guarantee that SQL works nearly as fast as > HBase native API. And most of my clients are users migrated from HBase, we > just provide a simple and easy way to make up the row key and rich data > types. > Moreover, I don't know whether Tephra is stable enough to be used in > production environment. > > > Above all, I cannot see other choices to do the job quickly and reliably. > > > At 2016-05-04 14:51:59, "James Taylor" <[email protected]> wrote: > >Hi William, > >I'd recommend looking at supporting these HBase features through the > >standard SQL merge statement where they compile down to these native calls > >when possible. Also, with our transaction support, you can already do an > >increment atomically and retry if a conflict occurs. > >Thanks, > >James > > > >On Tuesday, May 3, 2016, William <[email protected]> wrote: > > > >> Hi all, > >> I am trying to support hbase Increment and > checkAndPut/checkAndDelete > >> in phoenix and have done with Increment by introducing a new statement > >> INCREMENT. > >> Grammar: > >> INCREMENT tableName (column defs) VALUES(....) where expressions > >> > >> > >> Because all increment operations can be stored in a single Increment > >> object which can be committed by Table#batch(), it is not hard to do the > >> job. > >> But for checkAndPut/checkAndDelete, there isn't such a class that holds > >> the conditions and values at the same time. And for the existed write > >> path, all methods and data structures are > >> used to generate List<Mutation>, it is hard to add a new data type to > the > >> write path. So I have to create a new write path. > >> May someone give me some advice or solutions? > >> Thanks. > >> > >> > >> William >
