You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Kadir OZDEMIR (Jira)" <ji...@apache.org> on 2020/03/28 00:01:00 UTC

[jira] [Updated] (PHOENIX-5748) Simplify index update generation code for consistent global indexes

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

Kadir OZDEMIR updated PHOENIX-5748:
-----------------------------------
    Attachment: PHOENIX-5748-4.x.001.patch

> Simplify index update generation code for consistent global indexes	
> --------------------------------------------------------------------
>
>                 Key: PHOENIX-5748
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5748
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Kadir OZDEMIR
>            Assignee: Kadir OZDEMIR
>            Priority: Major
>             Fix For: 5.1.1, 4.14.4, 4.16.0
>
>         Attachments: PHOENIX-5748-4.x-HBase-1.5.001.patch, PHOENIX-5748-4.x.001.patch
>
>
> The implementation of the new global index design by PHOENIX-5156 essentially introduced two coprocessors, IndexRegionObserver and GlobalIndexChecker. IndexRegionObserver is the counterpart of the existing Indexer coprocessor that the previous global indexing feature uses. It implements the indexing write path. GlobalIndexChecker implements the read verification and read repair that happens on the read path. One of the main objectives of the design behind new global indexing was to leverage as much existing indexing code as possible. This objective has been achieved greatly as the entire index table update generation code implemented by various classes (including PhoenixIndexBuilder, CachedLocalTable, NonTxIndexBuilder, IndexUpdateManager,  LocalTableState, ScannerBuilder, IndexMemStore and PhoenixIndexCodec) is leveraged as it is mainly. This objective has served us well to deliver the new indexing feature quickly. The leveraged code is very complex, over engineered, and inefficient, and is not bug free. It is very hard to maintain. It is time to replace the complex set of classes with something drastically simpler and more efficient for the new design.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)