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
