phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5090) Discuss: Allow transactional writes without buffering the entire transaction on the client.
Date Sun, 13 Jan 2019 02:59:00 GMT


Lars Hofhansl commented on PHOENIX-5090:

> Is it needed?

Nope. :) As long as we do not have a situation where one table does ROW conflicts and another
does CELL conflicts, and then we cannot transact over them.

I think the trade-off we have are the right trade-offs. The one exception might be the slow
read performance for in-flight transactions.

Is it fair to say that Omid is designed for very many, small transactions, and not for extremely
large transactions?

> As far as we saw HBase row delete operation deletes all the row's column with version
which is lower or equal to the transaction version and we cannot use this. 

I'd like to find out more about that. What would need to change in HBase so you can use those?

I also had a question about when *other* clients would lazily add the shadow columns. Is that
done on the server in the context of scan operations? (Asking because we had a lot of issues
with Phoenix doing write from read RPC, i.e. adding delete markers during a scan, or server

Perhaps good to take offline and have a quick chat?

> Discuss: Allow transactional writes without buffering the entire transaction on the client.
> -------------------------------------------------------------------------------------------
>                 Key: PHOENIX-5090
>                 URL:
>             Project: Phoenix
>          Issue Type: Wish
>            Reporter: Lars Hofhansl
>            Priority: Major
> Currently it is not possible execute transactions in Phoenix that are too large to be
buffered entirely on the client.
> Both Tephra and Omid support writing uncommitted data to HBase immediately and at full
speed. The client still needs to keep tracks of the rows changes for:
> # Conflict detection
> # (for Omid) writing the shadow cells
> I'd like to do some brainstorming here.
> * It should *always* be enough to only hold on to the changed rows (and columns?) only
for _conflict resolution_ and free the rest from the client as soon as the uncommitted data
is written to HBase.
> * For the shadows cells we need only keep the rows changed, right?
> * There are situations where we can avoid the client site buffering entirely (perhaps
only for Tephra) when we declare a table or upsert not to participate in conflict resolution.
> [~tdsilva], [~ohads], [~yonigo], [~jamestaylor], [~vincentpoon], more, better ideas?

This message was sent by Atlassian JIRA

View raw message