phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ohad Shacham (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-3623) Integrate Omid with Phoenix
Date Thu, 02 Feb 2017 08:49:51 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ohad Shacham updated PHOENIX-3623:
----------------------------------
    Description: 
The purpose of this Jira is to propose a work plan for connecting Omid to Phoenix.
Each task of the following will be handled in a seperate sub Jira. Subtasks 4.* are related
to augmenting Omid to support features required by Phoenix and therefore, their corresponding
Jiras will appear under Omid and not under Phoenix. 
Each task is completed by a commit.

Task 1: Adding transaction abstraction layer (TAL) - Currently Tephra calls are integrated
inside Phoenix code. Therefore, in order to support both Omid and Tephra, we need to add another
abstraction layer that later-on will be connected to both Tephra and Omid. The first tasks
is to define such an interface.

Task 2: Implement TAL functionality for Tephra. 

Task 3: Refactor Phoenix to use TAL instead of direct calls to Tephra.

Task 4: Implement Omid required features for Phoenix:

Task 4.1: Add checkpoints to Omid. A checkpoint is a point in a transaction where every write
occurs after the checkpoint is not visible by the transaction. Explanations for this feature
can be seen in [TEPHRA-96].

Task 4.2: Add an option to mark a key as non-conflicting. The motivation is to reduce the
size of the write set needed by the transaction manager upon commit as well as reduce the
conflict detection work.

Task 4.3: Add support for transactions that never abort. Such transactions will only make
other inflight transactions abort and will abort only in case of a transaction manager failure.

These transactions are needed for ‘create index’ and the scenario was discussed in [TEPHRA-157]
and [PHOENIX-2478]. Augmenting Omid with this kind of transactions was also discussed in [OMID-56].

Task 4.4: Add support for returning multiple versions in a scan. The use case is described
in [TEPHRA-134].

Task 5: Implement TAL functionality for Omid.

Task 6: Implement performance tests and tune Omid for Phoenix use. This task requires understanding
of common usage scenarios in Phoenix as well as defining the tradeoff between throughput and
latency. 


Could you please review the proposed work plan?
Also, could you please let me know whether I missed any augmentation needed for Omid in order
to support Phoenix operations?



  was:
The purpose of this Jira is to propose a work plan for connecting Omid to Phoenix.
Each task of the following will be handled in a seperate sub Jira. Subtasks 4.* are related
to augmenting Omid to support features required by Phoenix and therefore, their corresponding
Jiras will appear under Omid and not under Phoenix. 
Each task is completed by a commit.

Task 1: Adding transaction abstraction layer (TAL) - Currently Tephra calls are integrated
inside Phoenix code. Therefore, in order to support both Omid and Tephra, we need to add another
abstraction layer that later-on will be connected to both Tephra and Omid. The first tasks
is to define such an interface.

Task 2: Implement TAL functionality for Tephra. 

Task 3: Refactor Phoenix to use TAL instead of direct calls to Tephra.

Task 4: Implement Omid required features for Phoenix:

Task 4.1: Add checkpoints to Omid. A checkpoint is a point in a transaction where every write
occurs after the checkpoint is not visible by the transaction. Explanations for this feature
can be seen in [TEPHRA-96].

Task 4.2: Add an option to mark a key as non-conflicting. The motivation is to reduce the
size of the write set needed by the transaction manager upon commit as well as reduce the
conflict detection work.

Task 4.3: Add support for transactions that never abort. Such transactions will only make
other inflight transactions abort and will abort only in case of a transaction manager failure.

These transactions are needed for ‘create index’ and the scenario was discussed in [TEPHRA-157]
and [PHOENIX-2478]. Augmenting Omid with this kind of transactions was also discussed in [OMID-56].

Task 4.4: Add support for returning multiple versions in a scan. The use case is described
in [TEPHRA-134].

Task 5: Implement TAL functionality for Omid.

Could you please review the proposed work plan?
Also, could you please let me know whether I missed any augmentation needed for Omid in order
to support Phoenix operations?




> Integrate Omid with Phoenix
> ---------------------------
>
>                 Key: PHOENIX-3623
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3623
>             Project: Phoenix
>          Issue Type: New Feature
>            Reporter: Ohad Shacham
>
> The purpose of this Jira is to propose a work plan for connecting Omid to Phoenix.
> Each task of the following will be handled in a seperate sub Jira. Subtasks 4.* are related
to augmenting Omid to support features required by Phoenix and therefore, their corresponding
Jiras will appear under Omid and not under Phoenix. 
> Each task is completed by a commit.
> Task 1: Adding transaction abstraction layer (TAL) - Currently Tephra calls are integrated
inside Phoenix code. Therefore, in order to support both Omid and Tephra, we need to add another
abstraction layer that later-on will be connected to both Tephra and Omid. The first tasks
is to define such an interface.
> Task 2: Implement TAL functionality for Tephra. 
> Task 3: Refactor Phoenix to use TAL instead of direct calls to Tephra.
> Task 4: Implement Omid required features for Phoenix:
> Task 4.1: Add checkpoints to Omid. A checkpoint is a point in a transaction where every
write occurs after the checkpoint is not visible by the transaction. Explanations for this
feature can be seen in [TEPHRA-96].
> Task 4.2: Add an option to mark a key as non-conflicting. The motivation is to reduce
the size of the write set needed by the transaction manager upon commit as well as reduce
the conflict detection work.
> Task 4.3: Add support for transactions that never abort. Such transactions will only
make other inflight transactions abort and will abort only in case of a transaction manager
failure. 
> These transactions are needed for ‘create index’ and the scenario was discussed in
[TEPHRA-157] and [PHOENIX-2478]. Augmenting Omid with this kind of transactions was also discussed
in [OMID-56].
> Task 4.4: Add support for returning multiple versions in a scan. The use case is described
in [TEPHRA-134].
> Task 5: Implement TAL functionality for Omid.
> Task 6: Implement performance tests and tune Omid for Phoenix use. This task requires
understanding of common usage scenarios in Phoenix as well as defining the tradeoff between
throughput and latency. 
> Could you please review the proposed work plan?
> Also, could you please let me know whether I missed any augmentation needed for Omid
in order to support Phoenix operations?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message