All,

I would like some guidance on LOCAL vs TRANSACTIONAL indexes and I
cannot quite get the details I need from the Phoenix site:
https://phoenix.apache.org/secondary_indexing.htm

Transactional Tables

<snip>
transactional tables with secondary indexes potentially lowers your
availability of being able to write to your data table, as both the data
table and its secondary index tables must be availalbe as otherwise the
write will fail
</snip>

1) What is the likelihood that an index is not available?

2) If rebuilding, is this on the order of minutes, hours?

3) Does Phoenix give an indication the write failed due to unavailable
table/index (bc if so client could handle this with other write options)?

Local Indexes

<snip>
all local index data in the separate shadow column families in the
same data table. At read time when the local index is used, every region
must be examined for the data as the exact region location of index data
cannot be predetermined. Thus some overhead occurs at read-time.
</snip>

4) Are there any requirements on table PK and index key regarding key
ordering?

5) How is something locally indexed if the keys are completely mismatched?
I get the sense that it doesn't matter given that "every region must be
examined".

Mutable Tables

<snip>
indexes on non transactional mutable tables are only ever a single
batch of edits behind the primary table
</snip>

6) If my use case updates a table and then reads from an index, it seems a
likely race condition that I can read-my-write.

7) Would you be willing to bet that most reads are consistent with the
table and only in rare scenarios is the table/index out of sync?

I appreciate your help and feedback on these questions.  Thanks,
--Matthew

Reply via email to